By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Action Items Bar

Paying off Design Debt to provide a more flexible solution for Sourcegraph extensions.


My role
Product Designer
Product Manager, 2 Developers


Code Intelligence Platform that lets developers search and explore all of their organization's code, perform large-scale changes and gain unique insights about the codebase.
Sourcegraph extensions add features like git blame, code coverage, trace/log information, link previews, and third-party tool integrations to the web experience.



Current solution for extensions

Extensions are represented by icons or icons with labels in the top bar. Users can interact with them by clicking to add information to the file view, clicking to go to the external documentation or read labels to learn about the file.


Current implementation was created as a minimal solution with a limited number of extensions in mind.

Over time, more extensions of different nature were added to the system. It created a need for design refactoring to ensure that debt is paid off and that the solution scales according to the current and future needs.


The list of extensions is continuously growing, and with it increases the average number of extensions that one person is using. Space dedicated to extensions needs to accommodate a large number of items.
Extensions have various action item formats that serve different purposes: icons, labels, text only, etc. We need to ensure that differences are understood by the users and mirrored in the UI.
We need to adapt the solution for users working with many extensions, long file paths and/or using smaller browser windows (using ⅓ of the window is very popular amongst our users).
Extensions management
The user must go to the extensions registry to add or remove the extensions. It is currently accessible in the top nav bar. We need to build a connection between the action items area and the extensions registry.

In addition, we need to indicate that some extensions are inactive for a particular file. Currently, extensions disappear from the bar in such cases.


The usability of the Action Items Bar has a high impact on users since the currently implemented version does not scale well when working with many items. It also has a high impact on the company's goal of getting more people to use and build the extensions.

This issue also is high-urgency since we're adding more extensions to the registry, and we foresee people enabling more of them. If we don't refactor the existing solution now, we're facing the possibility of producing more Design Debt when adding on top of the existing solution.

impact effort matrix

The Impact-effort matrix used to prioritise Design Debt issues.


Objective 1
Increase the usage of the extensions
KR 1
Help users see the value of extensions in their exising workflow.
KR 2
Make extensions discoverable and intuitive to reduce the friction.
Objective 2
Increase the number of extensions built by other people and companies

Our users

Extensions are used day-to-day mainly by people fitting into a Developer persona.
  • Focused on efficiency and reducing friction while working
  • Used to patterns from IDEs and other developer tools
  • Interested in integrating Sourcegraph into their existing workflow

Solution SPACE


  • Provide information about the file
    Example: this extension provides information about the number of code owners and their name (on hover)
    Code owners
  • Turn on the layer of additional data displayed inline
    Example: users can turn on inline Git Blame annotations to see who edited a given line last and when.
    Git BlameGitblame inline annotation
  • Outside link to documentation
    Example: this extension provides a link to the documentation of Go Programming Language.
  • Static information & layer of data
    Example: users can turn on inline Codecov annotations to see test coverage line-by-line; as well as see the overall file coverage.


I've differentiated three functional spaces that we could use for extensions: top horizontal, bottom horizontal and vertical. Each of those spaces has its pros and cons in relation to the needs of the extension action items.

Horizontal and vertical zones
✅ the top bar is one of the main areas of focus - action items would be certainly noticed by the users
✅ can accommodate both icons and labels
👎 limited space - it would be hard to incorporate many extensions, especially with text labels
✅ can accommodate a lot of extensions, even with text labels
👎 in the browser, bottom horizontal space is an area of low importance - danger of low discoverability
✅ can accommodate a lot of extensions
✅ takes up very little horizontal space, does not interfere with file content
👎 hard to display extension data in the form of text labels


Combine vertical & horizontal spaces
so that...
  • vertical space is used for action items (icons) that add overlay to the file or open an external link/application.
  • horizontal space is used for text labels that represent data about the file that are coming from extensions (ex. test coverage)
This way we're using the maximum potential of extensions in the correct places.
Sketch of horizontal and vertical zones for extensions

Low-fidelity mockup of horizontal & vertical spaces dedicated for extensions.

Iteration I

Action items v.1
  • Active extension action items are displayed in the vertical space and static information about the file is displayed in the horizontal panel
  • The vertical panel is collapsable (by clicking on the puzzle icon)
  • The horizontal panel appears only if there is data to display
  • Inactive action items are hidden under the menu
  • User can add extensions using plus icon that links to extensions registry. They can also access the list of all the active extensions from the contextual menu.
The first hallway test 🧪

I've decided to perform the first usability testing as a hallway test. I invited 6 engineers working at Sourcegraph to got through the prototype with me. I asked them to use extensions of different types, manage active extensions and get specific information about the file.


No problems using two spaces (vertical & horizontal). Testers described the distinction between action items and static data as intuitive and aligned with the patterns from their IDEs

👎 Puzzle icon is not intuitive for collapsing the panel

👎 Testers were confused about the horizontal bar disappearing when there is no data to display

👎 Testers signalised that they would like to see all the action items, even if they are inactive. Displaying them in the contextual menu causes unnecessary friction.

👎 2/6 testers didn't notice the horizontal bar

To improve

Disappearing horizontal bar
When the horizontal bar disappears, it leaves the user without any information about what happened. They are confused: is there a bug, is there no information to display?
Inactive action items
Users prefer to always see all the action items, even if they are disabled. It helps building muscle memory and reduce confusion.
Icon for collapsing the panel
Vertical bar is visible by default so users didn't have an opportunity to build the connection between the puzzle icon and opening the bar.
Horizontal panel is not noticable
Bottom part of the screen in the browser is a low-usage, low-attention space. Some users struggle to notice the bar in this area.

Iteration II

Action items v.2
  • Always present horizontal bar (with empty state message and a tooltip, if there is no information to display)
  • Inactive extensions are always visible, we've added the disabled state
  • No contextual menu (there is no need for it any more)
  • Text in the horizontal bar is slightly bolder and the bar is taller to improve the noticeability
The second usability test 🧪

The second round of usability testing included the same tasks as the first iteration and was divided into two phases:


No problems using two spaces (vertical & horizontal). Testers described the distinction between action items and static data as intuitive and aligned with the patterns from their IDEs

✅ All the participants knew how to collapse and open the vertical bar

✅ No problems with understanding which action items are inactive

🤔 10/11 testers noticed the horizontal bar and recognised its function


1/3 of a browser

From our usage data we know that many of our users prefer to keep Sourcegraph at 1/3 width of their browser.

Action items 1/3 browser

Scrollable bars (a lot of extensions)

Both vertical and horizontal can handle overflowing content. Users can use scroll the action items or text labels using arrows.

Action items scroll


I needed to adjust the solution for the diff view. I've decided to place file-specific horizontal bar below the path so that all the information about the file are in one place. Action items are a global element - they influence all the files in the diff.

Action items diff


Sourcegraph provides integration for the most popular code hosts - GitHub and GitLab. Extensions need to be adopted to interfaces of those applications without disrupting the flow and users' habits. They also need to be adjusted when it comes to style and behaviour.

I've decided to place them in the header, together with the file information. This place is the most predicable for the users. During the usability testing, I've incorporated a task of switching from the vertical action items bar to horizontal placement in the header. This flow caused no confusion for the users when moving between the products.

Sourcegraph extensions on GitHub

Sourcegraph extensions in GitHub's interface

Sourcegraph extensions at GitLab

Sourcegraph extensions in GitLab's interface


KPIs & metrics

Impact on company goals

Improving the usability of extensions action items and static data connected with them supports the company objective of popularising the extensions and showing their value to the users. New placement also supports the plans for more customers to develop their custom extensions.

Go to the next project
Back to top