Role
I was responsible for problem framing, conducting user research, and the design of the new code review experience. Our team’s focus was to increase user adoption so that we could deprecate the legacy code review experience.
Timeline
Jan 2020 to Sept 2020
What is code review?
Bitbucket has a collection of experiences built on top of its code hosting core. Code review is one of those experiences that supports developers through their end to end journey from picking up a piece of work to shipping it.
Code review is a collaborative framework that supports the back and forth feedback loop between teammates to effectively get code reviewed and merged into the main code base.
Code review journey
Who are the code review players?
Author
A developer who is proposing a change to the main code base by creating a pull request.
Reviewer
A developer who provides technical feedback on the change to improve code quality and later approves the changes.
Problem
Bitbucket recently shipped a new code review experience. To improve the experience for developers and help teams reduce maintenance and focus on new features, it was a big team goal to deprecate the legacy code review experience in favor of the new one. However, new code review adoption had stalled at 59%.
Research
We looked at surveys and feedback from the new experience and sorted the user problems into themes that we felt would help us prioritize what functionality to tackle next.
📊 Feedback frequency – How often is the feedback coming up? Is the feedback coming from a small but loud group?
💾 Functional parity – Does the functionality already exist on the old experience? Do teams rely on this functionality?
💎 Value add – Is the request functionality new but valuable to our ecosystem? Is this something we want to invest in for the future?
🤝 Value alignment – If the functionality exists on the old platform, do we think it’s valuable enough to rebuild? Do we envision it in the future of our product?
👥 Unblocks cohort – Teams may refuse to move over to the new experience because a critical part of their workflow will break if they switch to the new experience.
Changes
A powerful new sidebar
The sidebar was a huge part of the new experience. It provides developers with easy access to essential functionality. At the start, it wasn’t built in a way that scaled well. To mitigate these problems, We’ve introduced easy access tabs to help developers sort through and find what they need quickly and effectively.
Code review customizations
Developers all have their own set up that works for them. Although we had smart defaults, we learned that many developers are able to be efficient in different ways. We worked to enable functionality that allowed developers to review code more effectively.
A more granular workflow
In the old experience, it was hard for developers to communicate status effectively which made it difficult to understand how to move work forward. We introduced two new statuses to authors and reviewers.
As part of these changes, a request changes action was introduced as part of the code review status workflow.
Authors can now understand where the pull request stands with an expanded reviewer card in the sidebar.
Success metrics
✅ <5% opt out rate
✅ <1% page switch rate
✅ <5% support ticket volume
✅ Net positive feedback from feedback collector