A Bane and a Boon
At Postman, we're fortunate to have an enthusiastic community. We embrace open source and maintain an open dialogue with our community. This provides us with plenty of feedback. Consequently, instead of the typical challenge of "How to get feedback", Postman faces a "How to manage feedback" problem.
In Postman, we had 2 primary funnels for feedback:
- External - Github, discourse, Zendesk, Twitter, etc
- internal - a dedicated channel for any team member to openly share if they find a UX issue (called UX-fails)
We fed all feedback as issues into Jira, selecting a few for the current sprint to solve. Our selection criteria was rudimentary: if a major issue was found in the previous sprint, we'd prioritise it; otherwise, we'd pick the earliest issues. This kept the rate of incoming and solved issues balanced.
In the first few months of using this system, I realised I was solving each issue in isolation rather than recognising patterns and solving for deeper underlying issues. I also happened to depend on senior team members to understand why a particular solution was chosen in earlier UX-Fails, so there was definitely a need for maintaining a decision log.
Establishing a System
First up, I needed a better way to pick up issues. Which meant using a proper method to assign Priority to any task. We had the Priority tag on our tickets but it was either left on the default (Low) or arbitrarily set to a priority. I worked with my then PM to come up with this criteria to assigning Priority to any design task
We also needed a way to group issues to let patterns emerge, we used the following system to tag issues:
- Workflows affected: flows where users are going to run into this issue
- Feature: the internal micro-service that controls the affected area
- Type of issue: including UX copy, interface inconsistencies, design system compliance etc
Analysing the Feedback
After manually adding priority and tagging the 100+ issues we had in our squad, we saw a few things emerge out.
- A legacy workflow was causing an unusually high number of issues. I worked with the PM to do an entire revamp of this, which addresses the recorded issues and more.
- Most issues had <7 priority score. So it might be faster to pick up a type of issue like interface inconsistencies each sprint and run through them together.
This significantly improved our speed. For example, I selected all spacing issues and paired with a developer to fix them in under a week. This is much more efficient than fixing individual spacing issue in different weeks.
Creating a Thinking Tool
For issues with Priority >7, the solutions weren't always obvious. I needed a way to record the solutions to these so that team members could access context quickly without me becoming a blocker. I always admired how our design specification template, which we used while designing new features, doubled up as a tool that helped me systematically think through a problem. I wanted to create something similar for solving UX issues. I knew that engineering teams use the RCA method (Root Cause Analysis) to document Bugs, so I decided to read more about it.
After gaining an understanding of this method, I created a template to help me efficiently tackle UX issues. I published the template and shared it with the rest of the design team, and it quickly became the go-to approach for documenting solutions to UX issues
We increased our speed as well as improved the quality of solutions by combining these three elements. Between August 2020 and March 2021, we solved over 70 issues, increasing our resolution rate from 1-4 to 7-8 issues per month.