The goal of this usability test was to:
Enabling people to install the browser extension and easily use it with their private code is a high-impact change since the extension usage directly influences the MAU, and with that, the company's bottom line.
In addition, the current flow is discouraging for users and does not allow for benefiting fully from the product.
The Impact-effort matrix used to prioritise Design Debt issues.
I've analysed the path from learning about the browser extension, through understanding its value, up to installation and using for private code. I defined numerous touch points that we can improve or introduce to provide a cohesive experience since this was a high-level problem with the current solution.
One of the biggest issues so far has been that users are not aware that Sourcegraph has a browser extension and what are the benefits from using it.
Browser extension is a key part of the flow between Sourcegraph and the code host - it moves Sourcegraph's code intelligence (going to definition and finding references) directly to the code host's interface. Improving the awareness and usage will directly impact the MAU and the company's bottom line.
Flow: banner to user menu
Popup: install the browser extension
Browser extension post-installation page
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.
Extension popover: communication about private repositories
We've created a v.1 of implementation to test browser extension in the conditions as close to real-life experience as possible. We wouldn't be able to achieve the same effect with Figma prototype. I've invited 7 people for the test: 3 external users and 4 teammates from different departments who have just joined the company.