How Introducing a Design QA Step Helped Us Reduce Our Backlog
Oct 5, 2024
As a product designer, how often have you seen something in production that just doesn’t match what you designed?
It’s all too common to see subtle (or not-so-subtle) differences between the final product and the original design, which usually results in a growing pile of design bug tickets. But here’s the good news: a simple solution worked for us—adding a dedicated Design QA step to our team’s process.
In this post, I’ll walk you through how we introduced this step into our workflow and how it helped us reduce the number of bugs in our team’s backlog.
The Problem
We’ve all been there. You spend countless hours perfecting a design, hand it off to engineering, and when it comes back, something’s not quite right. Maybe the spacing is off, the colours are slightly different, or an interactive element doesn’t behave as it should. These might seem like minor issues at first, but they add up, leaving you with a product that feels inconsistent and unpolished.
Each of these inconsistencies typically results in a design bug ticket. You add it to the backlog, hoping it will get picked up in the next sprint. But then, more urgent tasks come along, and your ticket gets pushed back. This cycle continues, and before you know it, these tickets start piling up.
The Solution: Introducing a Design QA Step
Introducing a design QA step to our workflow was a game-changer for our team. Here’s how it helped us:
Catching Discrepancies Early: We built a formal step into our process where designers review what’s built against the original designs before anything goes live. This dedicated review lets us catch inconsistencies early, preventing them from reaching production.
Improving the Feedback Loop: We realised many design bugs came from miscommunications between designers and developers. By formalising the design QA process, we’ve closed that loop, catching and fixing issues during development rather than after. This has led to fewer bugs and smoother collaboration.
Keeping the Backlog Manageable: Thanks to this step, we’ve cut down the number of design-related tickets we need to file. This has kept our backlog lean and reduced the need for post-launch fixes.
Implementing Design QA in Your Workflow
Adding a Design QA step to your workflow doesn’t have to be complicated. Here’s how we did it:
Making Design QA Part of Our Process: We made design QA reviews a standard part of our team’s workflow. We have a review step between the “in-development” and “done” columns on our JIRA board, where this happens after the code review. Nothing goes live until it’s passed this check.
Scheduling Regular Reviews: Instead of waiting until the end of the development process, we do design QA reviews throughout the build. This way, we catch and fix issues as they come up, instead of scrambling to fix them all at the end.
Providing Actionable Feedback: During our reviews, we compare the design and build side-by-side, making it easier to spot and communicate discrepancies. We usually share feedback with engineering asynchronously on Slack—using screenshots or screen recordings—or on a video call. When necessary, we also create a ticket to keep the feedback organised and trackable.
Creating Clear Design Specifications: We use Figma to create clear, easily accessible design specs that developers can refer to during implementation. The clearer the documentation, the easier it is to catch inconsistencies during QA.
Gaining Access to the Staging Environment: A key part of our design QA process is accessing the demo or staging environment. Our developers set this up for us early in the process so we can interact with the latest build. This helps us catch any visual or functional inconsistencies before the product goes live.
Managing design tickets in the backlog
Of course, some design bugs and other UX/UI-related tickets will inevitably find their way into the backlog. These might be issues the team decided weren’t critical to fix before going live during the QA step, or they could come from elsewhere. But having fewer of them overall means they’re more likely to get picked up.
In my team, we have a ‘UX/UI improvements’ epic where these tickets live. The designer is responsible for prioritising them before sprint planning to ensure they don’t get forgotten about in the backlog. As a team, we aim to tackle one or two per sprint. This approach has helped us keep the number of design tickets in check and make steady progress—addressing over 100 of these tickets in the past year.
Conclusion: Fewer Bugs, Smoother Process
Adding a design QA step to our process was a simple but effective way to cut down on design bugs and ensure the final product matches the original design. While it might seem like an extra step, catching issues early and improving communication between designers and developers has helped us deliver a higher-quality product, enjoy a happier team, and keep the design tickets in our backlog under control.