The case for Design QA
It’s a great way to advocate for the user, champion experiential goals, and ensure that our intended design comes to life
I’ve always enjoyed the last phase of a design delivery program, the end-game, that final push through Design QA. I love seeing our designs in action, and I welcome the thrill of the triage room (especially when I successfully convince the Dev and Test leads that a design bug must be fixed). I find deep satisfaction in confirming that our design strategy has come to life.
Too often, I’ve seen Design QA left out of program planning and execution, sometimes with the disappointing result of an implementation that looks, feels and functions almost nothing like what our designers designed. It’s disheartening to work for weeks and months on a product with little to show for it IRL. Luckily, this can — and should — be avoided.
Plan what you’ll do (and how you’ll do it)
Start by introducing Design QA to clients and stakeholders as early as the pitch and account for it in determining scope, budget and talent mix for the proposed program. Design PMs must create schedules that account for both the time needed to conduct Design QA and time to make fixes resulting from the process. This often means adjusting capacity for creating brand-new designs in the latter part of a program.
Identify who, exactly, will be responsible for conducting the Design QA pass. Ideally, Design QA testers are people with expertise in the intended designs who also have access to the dev output on devices that match (or simulate) what end users will have. Some programs choose to reduce costs by using offshore design teams for some parts of Design QA, and that’s OK, as long as they’re well versed in the original designs.
From a documentation perspective, design bugs should be tracked and communicated in the same way functionality bugs are, be it through JIRA tickets, issues spreadsheets, or Slack channels. Working with cross-discipline leads, establish Design examples for bugs’ classifications, priority and severity definitions, and resolution paths. Investing in these norms, vocabulary, and tools helps establish the Design team’s seriousness about quality assurance and sets expectations across the broader team about Design QA as a whole.
But be ready for pushback
Some stakeholders or teammates might discount the need for Design QA because Design Validation has been accounted for or a UAT effort has been planned. Be ready to explain how Design QA is different from both.
Design QA confirms that the design intent was met with the development implementation. Design validation tests help boost designers’ confidence in the usability, desirability and feasibility of their designs and are key to finalizing design decisions. Design QA takes place after development, while Design validation occurs before.
Similarly, Design QA focuses on the design (including but not limited to: experience, flow, content, motion, layout, media, colors, and fonts), whereas UAT focuses on functionality (does it work, can a user complete the task at hand, does it satisfy the user story?). In my 20 years of experience, I’ve seen features pass a UAT test but fail elements of Design QA, but I’ve rarely seen the opposite.
Then, do what you planned
Practically speaking, Design QA starts the moment designs are handed off to Dev. The best way designers can ‘fix’ a design bug is to stop one from happening by communicating exactly what they want developers to build. Design deliverables need to be thorough, explicit and detailed. Designers should deliver a range of error-free artifacts like user flow diagrams, content matrices, data sheets and style guidelines. Furthermore, in addition to happy path screens/pages, designs must include edge cases, empty states and error states.
From a development lifecycle point of view, Design QA can tactically begin whenever there is enough live code to review. This timing is often aligned to User Acceptance Testing or associated with signing off on a specific program phase (e.g. a sprint). The timing on Design QA shouldn’t come as a surprise to anyone if you’ve already baked Design QA in to your program plan.
When recording and communicating Design bugs, pictures are worth more than words. Text descriptions of broken functionality, code snippets, and lengthy discussions about the value of fixing a Design bug can (unfortunately) spark nothing more than debate and delay. Showing rather than telling is key to making decisions quickly and effectively, so include images of what you expected vs. what was implemented.
Similarly, when advocating for Design Bugs in a Triage room or War room, have images on hand to help explain why the issue needs to be fixed. It’s especially powerful if you also have pictures, videos or direct quotes from user testing or field research. I can’t tell you how many stubborn Dev Leads I’ve toppled by having a great (real!) and visual story to tell in Triage.
Finally, be prepared to flex and bend on how (or whether!) to fix a Design bug. Factors like difficulty of the fix, how imminent the program’s release date is, cross-function dependencies and more will all be considered when triaging bugs and planning bug fixes.
A golden opportunity
Planned for properly, contrasted with UAT and Design Validation successfully, and executed thoughtfully, Design QA lets teams validate the user experience, check the accuracy of the visual design, and confirm that data and content is presented the way you intended. It’s another golden opportunity to advocate for the user and champion experiential goals. And I think that’s something designers should get excited about!
