Git blame optimization
Iterating and optimizing a popular git feature in a developer tool
I worked as the lead product designer to improve a popular git feature. This was a short but impactful project that showcases systematic design thinking and effective global collaboration.
My Role : Led design process end to end, driving two impactful rounds of design reviews
Team : Lead Product Designer (me), Product Manager, 2 Engineers
Feature Duration : 3 weeks . Feature shipped, further improvements pending prioritization
01/
Discovery
User feedback
Git blame is a feature in Sourcegraph that allows users to view who last touched a line of code(s)— e.g. blame for that line of code. Our product manager had documented consistent user feedback passed along from our customer teams. These were the underlying usability problems that we identified from the feedback:
The blame made it difficult to read the code, as it was a heavy block of text in-line to the code.
It was hard to distinguish between different categories of information.
Our multi line blame (when a user has affected more than on line of code at once) was confusing and misleading.
Why was this prioritized?
Git blame is our most highly used plugin by our enterprise customers (>50% recurring usage) , and our business objective at the time was to increase ARR within our largest enterprise customers.
Git blame gives us a competitor advantage over OpenGrok, a legacy but free Sourcegraph alternative that comes up often in prospect calls.
Our prior research had uncovered that git blame supports an important known use case for our users — code ownership; With no better code ownership solution, many of our users used blame.
We had clear, validated customer feedback. After prioritization, we quickly moved into problem definition and design.
02/
Definition
The Challenge
While this feature seems straightforward on the surface-level, there were a few important considerations that made this feature more complex than expected:
Systematic design
After reading through the user feedback, my mind immediately jumped to placing the blame in a new column separate from the code to address the user pain points of the code being hard to distinguish from the blame.
However aside from navigation and the sidebar, content was only displayed in-line to code in Sourcegraph. Introducing code adjacent to the code block was a new paradigm and a new interaction pattern altogether. Therefore, it needed careful technical and design consideration.
Scalability
There were a number of other add-on features that also showed content and links in-line to code. If I zoned in only on fixing the underlying usability problems specific to git blame, it could result in a design solution that wouldn’t scale to other features.
“If I zoned in on fixing the problems specific to git blame, it could result in a design solution that wouldn’t scale”
Usability
We needed to ensure that whatever the end solution, code was easy to read and navigate through. It is one of our core design principles to treat code as content — developers spend more time reading code than writing; we needed to ensure that we respect the readability of both blame and code.
03/
Process
This was a design that went through two time-boxed phases of design review.
UX design review
The goal of the first phase was for the design team to review and provide input into the new UX paradigm of adding content adjacent to code. This was especially important because I wanted to surface important scalability concerns that designers more knowledgeable in our other product areas might have, before moving on and refining a design.
I think that much too often, design is shared too late — the more a proposed design challenges or introduces a new pattern, the earlier designs should be shared so that the underlying UX can be reviewed before moving onto visual design.
Visual design review
The second phase of the design review was visual design review. While the design seems straightforward, there were many nuanced design choices that could potentially impact the readability of the content, such as row separators, hover states, and row margins.
All design reviews at Sourcegraph are open to anyone by default. I shared a Loom walking through the thought process of the new designs, a Figma link, and clickable prototype within a 3 day time boxed period for anyone to provide feedback and iterate on the visual design.
It can easily get overwhelming when a large number of people are commenting and providing input in Figma. To help with this, I made sure to keep my file clearly organized such that the current versions being reviewed were clearly marked, as well as past versions for reference.
A birds eye view of how I organized my Figma files. (There were other supporting annotations and documentation)
I also maintained a Changelog, which many people called out as being especially helpful. This design changelog documented all the design tweaks and changes I made as we iterated on the designs as well as the reasoning behind the changes.
This was especially helpful in a global async setting where everyone has different levels of context when coming into a Figma file — it’s super easy to just ask them to reference the changelog beforehand if they want to know why a certain design decision was made.
A short version of the changelog used for this feature
04/
Design
Going back to the beginning to the user problems that I set out to solve, here are some of the key design moments that solved the known user pain points.
It’s difficult to read code due to the in-line blame
I won’t go into this into too much detail as it is covered in the other sections, but this was solved by creating a new column for blame to live in, outside of the code blob.
This was a design decision that the design team agreed would be scalable and impactful, as well as a technical decision that the engineers agreed was worth the extra effort.
It’s hard to distinguish the categories of metadata
One way we addressed this solution was to introduce a user profile icon instead of showing the entire name. In the original design, the timestamp, date, and commit name were all spelled out and only separated by a circle icon — a user profile icon performed two functions:
It saved us horizontal space so that we could see more of the metadata without having to scroll
It acted as a natural visual separator between the metadata elements and promoted much better readability
Our multi-line blame is confusing
In the original git blame, if one user affected multiple consecutive lines of code, the blame data was shown on the first line then all the other lines were just blank. This was extremely misleading because it wasn’t clear that the blank rows below were intended to symbolize multi-line blame — many of our users believed it to be a bug.
We solved this two different ways. The first is very subtle zebra striping. The zebra striping allowed us to better convey sections outside of the row element. Now instead of just a blank space, an enclosed color section communicated that one user affected multiple lines. Not to mention, zebra striping improved scannability immensly.
The second method was the recency gradient, a new feature released by GitHub that we decided to incorporate into our product. The recency gradient left-anchored to the blame performed the same function as the zebra striping — it is yet another visual indicator of sections of blame.