Have you ever seen something in production that doesn’t look like what you designed? You open a ticket in the engineering team’s backlog and hope it’ll be prioritized in the next sprint. The next sprint arrives, but there are more-urgent tasks at hand, so your ticket gets moved to the next sprint. Your ticket keeps waiting in the backlog for the next sprint, and the next, and so on.

The problem

UI design is often regarded as a nice-to-have-but-not-influential part of a product’s success. Team members might prefer to focus on new features or code improvements. But the truth is that design has a great impact on how people perceive a product. Bad UI can appear unprofessional and have a negative effect on the product’s ease of use.

Designers put a lot of effort into making sure a design is pixel perfect. A design is usually assessed via user testing, and it can go through multiple rounds of reviews. It’s then handed over to a developer for implementation, but it can be difficult to develop the design exactly as specified. The developer might be seeing it for the first time, and they typically have many tasks to complete under tight deadlines. It’s not surprising, then, that small design details can get lost in the shuffle and that design bugs can result.

These design bugs add up, and getting the product to look and behave as intended can become tedious. Working remotely, we need to pay even better attention to the way we collaborate, to make sure things don’t get lost in translation.

Implementing a design review process

Our team started working on a new project to revamp the admin dashboard page, which consisted of many new graphs and visual elements. We needed a process that would ensure that whatever the design was would be what customers get. It was also important that this process be easy to put in place. Here’s the solution we implemented:

  1. Add a “Design review” column to the developer’s sprint board. Place the column somewhere between the “In progress” and “Done” columns.
Sprint board with a “Design review” column
Sprint board with a “Design review” column
  1. For any new ticket that includes UI elements, add a “Design_review_required” label. Then assign the ticket to a developer.
Engineering ticket with “Design_review_required” label
Engineering ticket with “Design_review_required” label
  1. When the design is ready for review, the developer moves the ticket to the “Design review” column.
  2. The designer reviews the ticket and adds comments. Then they move the ticket back to the “In progress” column.
  3. The developer makes the requested changes then returns the ticket to the “Design review” column.
  4. The designer again reviews the ticket. Once all changes have been approved, the designer adds a “Design_approved” label to the ticket (they can also include a comment that the design is approved) then moves it to the next column in the sprint board.
  5. The person in charge of QA checks that every ticket labeled “Design_review_required” has a “Design_approved” label. If that label is missing, the ticket is returned to the “Design review” column.

Things we learned along the way

We tweaked the process over time to better suit our needs. Here are some of the questions we faced:

When should the design review happen?

There is no clear-cut answer to when a design review should take place. UI changes tend to be more nuanced, so we decided to have the design review after the code review. An implemented design might change because a code review, so a design review would be necessary at that point.

How is the design review conducted?

Not all design reviews are equal. They can be done with screenshots, videos, Zoom, or even a staging environment that’s an identical replica of your product. The choice will depend on the scope and complexity of what’s being worked on.

How long should a design review take?

Design reviews shouldn’t take long at all—the goal is to be brief and effective. As a rule of thumb, tickets shouldn’t move to the “Design review” column more than twice. If a ticket is reviewed a third time, set up a short meeting to make any needed changes.

Final thoughts

By adding a “Design review” column to the planning board, we were able to reduce our backlog of design bugs. Design reviews are now an integral part of our work process, and they’re less likely to be forgotten or skipped.

The improved process has reduced the uncertainty and incompletion of design reviews. It also ensures that we maintain our brand’s and product’s high standards of quality. Most importantly, our customers are more likely now to have a great product experience that best meets their needs.

We still find design bugs sometimes. But having fewer of them in the backlog means they’re more likely to be addressed. 🙂

Latest in Process & Practice