Navigation Design Sprint Planning

closed

reopened

added UX in GitLab.com / www-gitlab-com label

@gitlab-com/gitlab-ux - Please review and volunteer!

changed the description

assigned to @timnoah and unassigned @clenneville

changed the description

I'm really looking forward to working with you all through this Design Sprint. This is a great opportunity to come together and propose some solutions in how we could deprioritize unneeded global nav items for specific roles. I've updated the Issue Summary with a plan of action including desired outcomes of the 5-day sprint.

Ideally, it would be great to kick off the sprint from the 25th March and end it on the 29th. Please let me know your thoughts and if anyone is OOO between 25th - 29th March so we can re-arrange accordingly. Design Sprints work best if they allow us to garner momentum from day to day, so a week we are all available is ideal.

cc/ @clenneville @victorwu @cperessini @jeremy @kmann @tipyn

@timnoah thanks for putting this together! The plan looks really good.

Is there an expectation of how much time we would be dedicating to this effort? Design sprints usually require the participants to work exclusively on the sprint, so I don't think I would be able to accommodate that into my %11.10 workload. Additionally, I will be off on the 29th of March. I would propose we do the sprint during the first week of %11.11, from April 8th to April 12th, which would also give us more time to recruit users for testing on the fifth day.

Is there an expectation of how much time we would be dedicating to this effort? Design sprints usually require the participants to work exclusively on the sprint

Very good point @cperessini Thanks for raising it. I didn't want to be too prescriptive on the time everyone spends due to the fact we all have other deliverables during the sprint. My idea was that we are not required to work exclusively on the sprint but leave enough time for the calls, sprint partner syncing and to get ideas mocked up to present to the group. Would be great to get your thoughts also @clenneville.

Thanks for also letting me know you are away on the 29th. I'm happy to start the sprint at the beginning of the next milestone (April 8th). Would that work for you @victorwu @jeremy @kmann @tipyn?

That timeline is good with me. Thanks all.

Totally agree, @timnoah and @cperessini. Please don't feel like this needs to be your exclusive focus during the week -- let's keep it lightweight and lo-fi.

I will actually be OOO on the 28th and 29th and the 1st as it's my birthday weekend. Rather than slow this down would it make sense to have another PM step in instead of me?

I actually didn't realise I'd volunteered myself for this, I thought this was just a meeting that I could listen in on and learn from. Happy to participate of course! I just don't want to be the one holding this endeavour up! :)

Starting on the next milestone (April 8th) works for me!

@timnoah Will you require any researcher support during the sprint? @katokpara is on vacation until 15th April. I can be available on 11th April and the afternoon of 12th April if you'd like some help sourcing users/writing a test script.

I can be available on 11th April and the afternoon of 12th April if you'd like some help sourcing users/writing a test script.

Thank you @sarahod! That would be incredibly useful. Having your help on the 11th and part of the 12th (if possible) would really help as we begin to close the sprint.

No problem - added to my calendar!

@timnoah although I don't have the capacity to collaborate on this, I'm comfortable knowing that @cperessini is involved, since me and him worked extensively on the latest navigation redesign. In any case, feel free to loop me in if necessary.

I'm super excited about this design sprint! I wish everyone has a great time working together — remember that it's also important to have fun.

remember that it's also important to have fun.

Thanks, @pedroms Wise words. My plan is to keep this as relaxed as possible. Everyone's contribution is valid and it will always be a group effort

changed the description

@timnoah - Thank you so much; this looks great!

@kencjohnston and @ebrinkman for awareness

@clenneville why is this issue in the GitLab company website issue tracker? I believe it should be moved to the gitlab-org/gitlab-ce issue tracker.

Sure, @pedroms. Is there an easy way to move it?

Scroll down in the right-hand menu, there's a move issue button :)

Oddly, I don't have gitlab-ce as an option under Move. @pedroms - Can you move it?

@clenneville usually there are a lot of projects named GitLab Community Edition in that move dropdown because of shared projects. It's just a matter of finding the one that is located in the GitLab.org group

@victorwu thanks for moving it.

Hey folks, I hate to be a pain in the neck here, but I don't think I'll really have the capacity to help with this. I thought it was just a meeting I'd listen in on. My apologies :(

Unfortunately, I'm in the same position as Luca; I also didn't realize the level of commitment here. I also thought it was a single meeting based on the Slack thread. I can't commit to 5 hours of meetings in a single week.

If we can scope the Product commitment here down, I'd be happy to contribute. But at this time, I'll have to withdraw from the design sprint.

cc @kmann

moved from gitlab-com/www-gitlab-com#3957 (moved)

@timnoah can you please update your proposed schedule of activities with specific times that you think are required, and we can work together to figure out perhaps how to shrink those times and/or be flexible.

For example, many of the activities such as explaining the concept, explaining the problem, voting, can be done async with text and video. So I think we can reduce the five hours of synced activity to something smaller.

Also, is putting everything in one week necessary? If we could spread it out a bit more, that might be easier for folks.

can you please update your proposed schedule of activities with specific times that you think are required, and we can work together to figure out perhaps how to shrink those times and/or be flexible.

I didn't want to be too prescriptive on the time everyone spends due to the fact we all have other deliverables during the sprint. It will always be an added effort during a milestone but I'll sync with @clenneville to create a plan around timeboxing tasks to help everyone involved better manage the Sprint with other commitments.

For example, many of the activities such as explaining the concept, explaining the problem, voting, can be done async with text and video. So I think we can reduce the five hours of synced activity to something smaller.

I see your point here. The 1 hour a day for the first 4 days was a general guide, with the idea that we'd break off and work async after the meeting. The work between Sprint Partners could be picked up async or synced (whatever works best) but momentum is a central theme of any Design Sprint. Which is why I still think synced activity, is an important part of the process. I do concede though, that in order to make this work for all of us we could look at trying to reduce the 4 hours allotted meeting time.

Also, is putting everything in one week necessary? If we could spread it out a bit more, that might be easier for folks.

From my experience, the condensed nature of a Sprint through one week works well because it's easier to garner momentum from day to day. There is reduced pressure to formulate a polished solution and that releases freedom for all Sprint Members to perhaps propose ideas they wouldn't have otherwise. I take your point here on board though and will discuss with @clenneville.

Thanks for the update @timnoah. Certainly I don’t want to dilute your process by cutting anything that shouldn’t be cut or changing any of the pacing. I think if we don’t do it correctly, there might not be much value of doing it at all.

The only thing I’d offer is that “synced activity” at GitLab does not necessarily correlate to good momentum. GitLabbers are really good at async and lots of great collaboration can happen from async. And in fact, sometimes if collaboration gains steam during several async interactions, folks will naturally lean toward creating synced meetings soon after because they get so excited about the work and want to focus in and move even more quickly. So setting clear goals and expectations of deliverables (and not communication format) I think help inform GitLabbers from that respect. Also if you have one or two links to explain the design sprint concept I think folks would be interested too and can understand why this process overall is a good one and we should try it.

Seems like you have a sense of what people can commit to here. So please do iterate on the plan as the UX team discusses further. Thanks for putting this together in the first place!

So setting clear goals and expectations of deliverables (and not communication format) I think help inform GitLabbers from that respect.

Great food for thought, Thank you for this.

For a general overview of the Design Sprint concepts, Google Ventures has a great article and accompanying book:- https://www.gv.com/sprint/

Other useful articles:-
Make Meaningful Progress Via Remote Design Sprints
Running a Remote Design Sprint

@timnoah there are two more four-day sprint versions worth checking out, which involve the whole group only in half of the days, that could prove more viable in this context. Haven't tried any of these!

I have no issues with adapting the process as needed. I agree with @timnoah about the momentum generated by a one-week sprint, but have no strong feelings about asynch communication or timing (if next week doesn't work).

@timnoah : Thanks for the resources. I went through the articles and even watched a bit of the webinar. I think step one (or step 0, i.e. homework) of this very design sprint is to have folks read the articles, and that's certainly do-able async!

The design sprint concept and structure is much more clear to me now and I think many of the stages can be async-ified to a large degree. But I'll let you Tim provide us with a first pass update on more specific expectations, and hopefully the revised sync-ed time requirements will be a bit less and we can still get Jeremy and Luca to participate. If that's really not possible, I think it'll be great if you could welcome other product folks in next Tuesday's product meeting. If even that fails, we can simply grab other people, like product marketing folks or engineers to participate. There should be no shortage of people who may be interested. Once we do a few of these, I'm optimistic we will be able to customize to GitLab's process and run them more regularly, and I am excited because I'm keen to have Design at GitLab to have an even stronger role in our product development.

@gtsiolis Thanks for sharing the two examples on 4-day sprints. I was apprehensive at first but now very open to the idea. @victorwu Currently tweaking the proposed plan and will work out how a 4-day model could work for us.

@victorwu, do you know why we chose this particular problem to do the design sprint around? I remember you bringing this point up in the product meeting, and it's an interesting one. I can't recall if there was additional context here.

@jeremy : I believe that's the specific reason. @clenneville was in the meeting and commented she was interested in pursuing it further. I think the UX team had already wanted do a design sprint, so I guess this topic became the candidate. I'll let Christie comment if there were any other reasons for choosing this one.

I suggested this approach, because of three things:

The cross-product nature of the problem
The passion I heard from multiple product managers when discussing the topic
It's nav, so users can be sensitive to changes (feedback is helpful)

"I think the UX team had already wanted do a design sprint": Not necessarily. It's just a good fit for the challenges presented.

changed the description

@tipyn @jeremy I'm sure you would have both been amazing on this design sprint and I was selfishly excited to be working you . I totally understand though, I also could have done a better job reaching out and articulating the plan ahead of time.

Keep a look out on how we progress and formulate things. If you'd like to jump back on board you are more than welcome.

Here's where I think we are with things.

@victorwu You're interested in and excited by the problem. You've got three designers who are interested in tackling it, so if you'd like to be the single PM giving visionary guidance, that still works.

@tipyn - I just learned that nav falls under Fulfillment, so if you'd like to still be involved, I believe that would be very valuable. We can work around your schedule, as needed, to find the right timing.

@timnoah can update the description to adapt the methodology as needed (that's up to the participants and how they think they'll work best together).

Thanks @clenneville

@clenneville : Sorry I didn't answer your question regarding "visionary guidance". Per the product categories page, navigation belongs to Manage. (See https://about.gitlab.com/handbook/product/categories/#framework-group-1). @jeremy : Is that correct per your understanding? We can certainly change the categories page if you don't think that should be the case.

For the purpose of this particular design sprint, I'm happy to lend support as the PM proxying for the rest of the Product team and can work closely with Tim on logistics. Depending on Jeremy's response, we can re-visit now or later after the sprint on how navigation should be handled from a vision perspective.

Hi all, just FYI ~Manage is responsible for Nav. @jeremy now that the synchronous meeting time has been reduced 2 hours and starting the week of April 8th, I'd like for you to consider if you could make time for the design sprint and partner with @victorwu.

@dimitrieh I believe you've run a design sprint at GitLab before. Would you mind summarizing how you managed to balance synchronous and asynchronous communication? Are there any valuable lessons you learned that you would like to share?

@cperessini mmh I had setup a tooling environment similar to murally etc within figma. This would assist us in multiple sync video sessions to make it more similar to an on-site design sprint. You can see the template for that here https://www.figma.com/file/cqAUauE4j1cdVxTQBQpBRq3z/Remote-Design-Sprint-Boilerplate-Public

The eventual session however never came to be. I think the more we try the better we'll be able to work out what works and what doesn't. Feel free to use the figma template if deemed useful ;)

Thanks, @dimitrieh! This sprint was put on hold but I'll definitely keep that in mind for when we get around to it.

changed the description

I have just made some updates to the Plan for this sprint (Please see Summary ). The number of synced meetings has been reduced from 4 to 2, with the total amount of days down to 4 (thanks @gtsiolis ). Would still love to kick this off on the 8th April so please let me know if there are any availability concerns. I'll also be changing the name of this issue to "Navigation Design Sprint Planning" and will create a new issue for the upcoming sprint, to help keep the conversation streamlined.

cc @victorwu @cperessini @kmann @clenneville

LGTM! Thanks for your efforts on this, @timnoah

Looks great to me @timnoah !

changed title from Navigation Design Sprint to Navigation Design Sprint Planning

As interested as I am in where this design sprint goes, I'm going to push back a bit on the specific problem we're focusing on here. The description states the problem as:

How to deprioritize unneeded global nav items for specific roles

While I do think this is an interesting problem, navigation is in ~Manage's camp and I'd urge us to consider prioritizing other opportunities for improvement here. Namely:

We explored introducing the DevOps stages into our navigation, an idea that Sid promoted. I'd choose to sprint around further exploration here and what the user experience might look and feel like if we moved toward this direction.
The UX research team conducted a fair bit of user research on navigation, most of the insights haven't been explored further or implemented (cc @katokpara). Can we springboard off our existing research to solve some of the problems we unearthed there?
The data we have in Snowplow points to our top navbar needing some iteration and improvement. Can we learn something from our data and existing research? Doing a quick pull, we can see that:
- Users frequently click the GitLab logo to return home, "Your projects", Settings, and the issues/MR/todo icons in the top right.
- Almost nobody is using any of the Explore options, Search, or Help.

Prioritization aside, I also think that the above issues may indicate that moving to answer the question "how can we deprioritize unneeded nav items" is premature optimization before we've solved more fundamental problems with our nav.

@cperessini @matejlatin, what do you think?

@jeremy are there some past/current issues you could point to that would offer additional historical context about the "fundamental" problems the team has been focused on?

@kmann, thanks for asking. The most biggest steps forward on navigation improvements in GitLab can be summarized in a blog post from 2017. You can also see the UX research we've conducted on this.

Navigation falls into ~Manage, but we haven't actively been prioritizing navigation improvements. Don't get me wrong - I'm not saying that navigation is broken or in a bad place when I use the word "fundamental", but I do wonder if there are opportunities to improve the foundation before we begin considering what we can hide/visually deprioritize for certain personas.

@tauriedavis will know far more about the history of navigation at GitLab than I would

I'm not caught up on all the recent research on navigation but I would be happy to join some sort of kickoff call to provide any historical point of reference if that would be helpful here :)

To @jeremy's point, it seems as if it would be worth exploring what problems we have with our current navigation prior to determining the solution is to remove/deprioritize certain paths. It sounds like that is part of Day 1 but I would recommend rewriting this problem statement:

## The Problem

How to deprioritize *unneeded* global nav items for specific roles:

* Business Analyst
* Business Team Manager
* Business Team Director
* Product Manager

This is actually written as a solution (deprioritizing nav items) with the open question of how to do so. What problem are we trying to solve within this sprint? What does deprioritizing help solve? How and why do we know this is a problem?

+1 @clenneville comment below. @jeremy @victorwu - Let's make sure we are appropriately scoping the problem space before starting.

This is actually written as a solution (deprioritizing nav items) with the open question of how to do so. What problem are we trying to solve within this sprint? What does deprioritizing help solve? How and why do we know this is a problem?

I agree with what @tauriedavis said and what @jeremy is trying to warn about. We have existing research and documented past improvements to the navigation. Let's try to use that to get the navigation to a really good place and then start to think how we can better design for different personas. I'm not up to date on this but where did the idea for adapting navigation based on persona come from and what does it hopes to solve?

@Matej I believe it was based on this issue by Victor https://gitlab.com/gitlab-org/gitlab-ce/issues/58093

added Manage [DEPRECATED] global nav navigation product discovery [DEPRECATED] labels

removed global nav label

added devopsmanage label

mentioned in issue #59566 (moved)

changed the description

marked this issue as related to #58093 (moved)

@jeremy - All of your points are valid. I think this comes down to a discussion between you and @victorwu about how you want to define the navigation problem to be tackled. The Designers can then align the sprint to that problem space (if a sprint is still the right approach).

@jeremy @victorwu Thanks for all of the thoughts and ideas around this issue.

@jeremy as the owner of nav, would you please comment on this issue with the prioritization decision for which problem to approach first during this design sprint?

I'm personally very excited about product and UX getting better aligned and think this design sprint is incredibly valuable for our organization, but also for our UX. Please prioritize involvement and participation in the process.

changed the description

I'd like to explore how we might be able to improve the discoverability of features in our navigation.

Why is this important?

GitLab is a pretty cool application that spans a wide breadth of capabilities. A major area of improvement for the product (and a specific goal for teams like Growth) is improving the number of users who are using multiple areas of the application, as defined by our DevOps stages.

Generating cross-stage activity gets us delivering more value to our users (adopting more of DevOps in a single application gets you shipping faster) while being super valuable to GitLab's business (more feature adoption across stages makes it harder for an organization to separate from GitLab).

This is the common theme that's connecting seemingly disparate issues like the one Victor brought up (by concealing features, we present more relevant ones to a user) and the sidebar nav by DevOps stage issue.

How do we know this is a problem?

We have some relevant user research. Thanks to @katokpara for this.
- "When completing tasks, most hesitancy stemmed from a lack of awareness of the feature or not being sure of where they could find a feature like that." ... "Some users are aware of the concept of a feature but do not know the exact name of it. They may be more oriented towards looking for it under a “section” (such as CI/CD or Issues) even if they can't pinpoint it. Other users remember feature names very well (e.g. heard about it in a blog post, video, release update, etc) but have a shakier foundation of where to actually find that feature. Further improving categorization can help with this point." ... "(A user) spends a lot of time browsing and hovering over items."
- "Many users have multiple groups set up across their instance to manage projects, clients, applications, and more. Due to this, some users lost context for certain features because they were only enabled in a certain project. They’d have to navigate to the right project before finding the feature available."
We no longer track SMAU (we'll rebuild this dashboard in Periscope, but there was lots of room for cross-stage MAU growth when this dashboard existed.

@timnoah, does any of that resonate or seem of interest? Happy to provide some more background, context, and details.

Do you think we can consider structuring a design sprint around that theme?

changed milestone to %12.0

An update here: @timnoah and I discussed the goals of this design sprint, and we've decided to deprioritize this for now. I think we both agree that improving feature discoverability and the overall usability of our navigation is a priority, but we're not sure that Tim has capacity for this in this release as he also ramps up on Fulfillment.

I'll tentatively schedule this one for %12.0 and asked Tim to follow up with @clenneville if another UXer might be able to charge forward with this one as part of our UI beautification efforts.

added groupoptimize label

@jeremy - 12.0 sounds good.

Google Ventures has offered to facilitate the sprint for us. That will take some of the effort off of Tim and allow him to fully participate without extra overhead. It will also be a great learning experience for all of us.

On that note, can we commit to a specific week in 12.0?

@clenneville, that's great news. What does "facilitate" mean here?

I'd love to the sprint on the week starting May 13th.

A discussion topic for consideration:

How should we approach adding new items to the left sidebar?
When is it appropriate to create a new top-level category at the group sidebar level?
- Should we limit the items included under Overview?

This is related to the discussion in https://gitlab.com/gitlab-org/gitlab-ee/issues/7934#note_154868559 but also generally good to explore.

After further thought and discussion, we are going to put this Design Sprint on hold to focus on how a sprint might work for Cycle Analytics, instead.

mentioned in issue #57373 (closed)

unassigned @timnoah

added [deprecated] Accepting merge requests label

mentioned in epic &1342 (closed)

mentioned in issue #64290 (closed)

changed milestone to %12.3

added missed:12.0 label

This issue was mistakenly put to %12.3, but intended for %12.1, now we're using a one-off script to correct it. Sorry for the inconvenience.

changed milestone to %12.1

Hi, @clenneville - should we close this issue as we decide to go for VSM and have sent(?) the request to GV?

closed

@clenneville @valexieva It would be great to know what was decided so we can still follow the progress you made with GV

Yes, we can close this. Scott and I are meeting with GV next week to review the application we submitted.

mentioned in issue gitlab-design#1103 (closed)

	Tasks
`Kick-Off`	Meeting - Introductions. - Expectations for the following week.
`Day 1`	Understand - Meeting: We map out the problem, going into further details and pick apart the wider issues at hand. - Async: Discuss further and talk about other potential lines of enquiry not covered on the call in the issue. Designers begin sketching ideas.
`Day 2`	Ideate / Decide - Async: Designers continue sketching ideas. - Meeting: Each designer presents their work and we then vote (anonymously) for the idea(s) we believe work best.
`Day 3`	Prototype - Async: Facilitator leads the effort in prototyping the design. We discuss user testing and begin preparations for this on Day 4.
`Day 4`	User Testing - Connect Async on the issue as User testing begins. The facilitator will detail the main findings.

Navigation Design Sprint Planning

The Design Sprint

The Problem

Tools

The Plan

Desired Outcomes

Useful Links

Designs

Child items ...

Activity

Why is this important?

How do we know this is a problem?

Navigation Design Sprint Planning

The Design Sprint

The Problem

Tools

The Plan

Desired Outcomes

Useful Links

Relates to

Activity

Why is this important?

How do we know this is a problem?