Article — Process & Practice

Say goodbye for good to your design backlog

Written by Gal Laor — Artwork by Sydney Goldstein, Calvin Rocchio, and Lexi Visco

Paper floating in water
Previous
Next

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. 🙂

Gal Laor enjoys working on all stages of the design process including strategy, research, visual designs, prototypes, and data analysis.

Sydney Goldstein is a graphic designer who just likes to make stuff. She is apart of the Brand Studio Team at Dropbox.

Calvin Rocchio is an interdisciplinary designer who uses images, publications, plants, language, and community organization to provide space for softer sensitivities to one's environment.

Lexi Visco works with what she identifies as a birdhouse model of design. With people, community, and place, she inhabits modes of research, collaboration, deconstruction, and rebuilding.

Rita Troyer is a designer who works at the intersection of art and technology. Her primary practice areas are web design and image making. She feels most alive by the sea.

Gabrielle Matte creates collections of images. These assortments reveal a respect for diversity, thoughtful processes, and good relationships. She is part of Dropbox Brand Team.

Latest in Process & Practice