GitLab: Sticky Headers

As a Senior Product Designer at GitLab (end to end DevOps solution application), part of my responsibilities include both identifying and driving new design opportunities and solutions for both the business and the user. In some cases, ideas are brought to me via my PM, other team members such as designers, engineers or leadership, and of course our customers. In other cases, I have the autonomy to identify and drive product improvements and do so when I see a valuable opportunity. My particular area of focus from the product and business standpoint is the Plan stage which works with use cases, users and flows related to Project Management.

After completing the Category Maturity Scorecard work, one of the areas that surfaced as being low hanging fruit which would provide a clear and measurable improvement to the user experience was surrounding reducing context switching when interacting with issues. Issues are what GitLab provides for users to document, track and collaborate on ideas and work.

Parker is a busy, multi-tasking Product Manager who spends countless hours each week reviewing and responding to issues within GitLab. This requires switching context often between topics within issues which often have lengthy descriptions and conversations. Parker has to review each and attempt to gain enough context quickly to be able to respond to questions or add questions of their own, but doing this several times a day results in extensive time reading.

We’ve had several users request having the title fixed at the top of the page within GitLab to reduce the amount of scrolling and context switching required to simply be able to understand how to reply.

Because of the open source nature of our product, we have the ability to directly chat with users. Several had upvoted an idea of fixing the title at the top of the issue pages in order to not to have to scroll up and down, causing one to lose their place. I thought it was a great idea, but also know sometimes solutions can be addressing a symptom of a problem, not the actual problem. So I wanted to evaluate the context of the problem as well as explore some additional potential solutions.

I started by considering the ways in which people consumed content within issues. Did they start at the top and read down? Did they skim or skip any aspect of the information? If so, why? If not, why not?

Started with questions

I began with a series of questions and theories, which I shared with someone in our research team as well as my PM and other designers. In order to properly determine if a fixed element was the right approach, I felt I needed to consider when and why it was useful as well as how much information (and what information) should be presented in that area.

Created research plan

I created an issue outlining the research which included evaluating how users consumed the content and in 3 different contexts:

I then outlined the various meta data at the top of the issue that would be lost when the user was scrolled and planned to have users rank that based on value within each of the 3 contexts.

My tasks in the sessions with participants included having them view an issue (I sent them a link) with a lot of dialogue that I expected to be new to them, then having them review it from top to bottom quickly and share what they thought it was about. I observed how they interacted with it and asked probing questions to dig deeper into comments.

I also had them do the same but in the context of being tagged in an issue. In this case, I sent them a link to a direct comment in the issue which automatically drops them halfway down the page, then did the same observations and again asked questions.

Finally, I had them revisit the first issue again and talk through the info again.

Description

Description