Why you don't need Design QA

I read with interest Jess Eddy’s piece in UX Collective: The importance of Design QA in digital product design. I think Jess raises an interesting problem, but I disagree with her solution. This is my alternative take. Comments, questions and counter-arguments welcome. 


When I first saw the term ‘Design QA’, I interpreted it as ‘quality-assuring the design’. But as I read on, I realised that’s not what Jess is talking about. Design QA is about the designer quality-assuring the developer’s work:

Since I’m a product designer, there’s a particular part of the process that I’m obsessed with, and that’s making sure that designs get implemented as intended. What does this mean? It means ensuring that design work is coded to closely if not perfectly match the actual designs.

Jess Eddy, The importance of Design QA in digital product design

What problem are we trying to solve with Design QA?

It’s not uncommon to hear designers moaning about how everything would be perfect if only developers would do as they were told. But the problem Jess raises - and her solution - isn’t just about making sure the developer sticks to the spec. This is about Design Debt: over time, a product develops inconsistencies that degrade the experience and confuse the user. 

Jess proposes a new checkpoint between development and testing, to allow the designer to check the developer’s work and confirm that the design was built as intended.

Of course, this assumes that the only source of inconsistency is the developer. If the designer is always right, then inconsistency MUST come from the developer not following the spec.

How can we catch development mistakes?

Quality assuring the finished product is one way to find problems. But how about if we created a development process that ‘designed out’ as many mistakes as possible?

First up, we’d need to have an agreed standard for how the product looks and behaves. Without this ticking this first box, we can’t really have a conversation about consistency. There’s nothing to be consistent with. 

So, we could start with a design system that captures an agreed set of visual styles and behavioural patterns. 

Given the whole team knows there’s design system, the developers could extend that into a pattern library and classes that support every element in the system. Adding a new feature becomes a matter of choosing the right lego bricks, not making up new ones. Once this set up is in place, the developer would have to try pretty hard to introduce inconsistency. 

Of course, from time to time you're going to need new elements. That’s a conversation you should have as a team. Developers generally have lots to contribute on the smartest, cheapest or most reliable ways to solve a design problem. Everyone can consider the implications and make sure the new element carries through from style guide and design libraries to classes and code. 

If you’re working with a design system, why on earth would a developer waste energy on introducing an inconsistency with inline styling or random new classes? These things happen, but they are a lot less likely if everyone is aware that there are standards. 


Smokey, this is not ‘Nam. This is bowling. There are rules.

The Big Lebowski


How to catch design mistakes

Inconsistencies aren’t always the developer’s fault. Designers sometimes throw in a random colour or pick the wrong font. They can also be guilty of unnecessary embroidery. Just because it was the designer that added the new (inconsistent) element, doesn’t make it right. 

A pattern library limits the impact of design mistakes. The developer, working with the existing pattern library, will catch the error. Of course, a wise developer will raise the issue with the designer rather than just ignore the spec. But then a wise designer would have realised they were creating off-piste elements and highlighted that in the spec, wouldn’t they? 

And like the developer has their CSS, the designer could use a style sheet such as you get in tools like Sketch. That makes it clear when you’re adding new elements. 

You can even get design linting tools now, to check for off-palette colours and incorrect fonts. Developers have been ‘linting’ their code for years, to check for stylistic errors and help keep the codebase tidy. It’s a good habit for designers to follow. 

Design the things that change, not the things that should be consistent

The other advantage of a design system is that you don't need to spend so much time on detailed mockups of every new or modified screen. Sketches with notes on the intended UI element might be all that’s necessary. 

That would give you, more time to focus on the stuff that isn’t captured in design systems: scenarios that the design needs to support and behaviours to be implemented. The stuff that BDD worries about. 

This kind of information is invaluable for developers, particularly if they practise TDD. But even if they don’t, they should still show some interest in the intended behaviour of your design. If they don’t know what It’s supposed to do, how can they code it? And how can anyone test it?

We already have design QA - it’s called testing

Inconsistencies are as much process failures as people failures. The way to correct the problem is to fix the existing process, not add MORE process - like an extra Design QA step.

But of course no process is perfect, and that’s why we do testing. It’s our final chance to eliminate errors before the product ships. Testing, done properly, will QA the work of everyone up to that point: the developer, the designer, and the person who wrote the user story in the first place. 

 The V-model maps testing stages to development stages.

Unit testing is for developers to checks their own work, ensuring that each module of code works as specified. Integration testing extends this to make sure that what the developer just checked in hasn’t broken any other module. 

System testing checks that the whole system works as specified in the design. It’s not so common these days for teams to create extensive design documentation so testers may be working from their knowledge of the design system as well as the designer’s specification for each new feature. 

Jess’s suggested approach to design QA seems to indicate that only the designer is able to sign off on the consistency of the new feature. But if the design is insufficiently precise for an independent tester to carry out the QA, it was probably unclear to the developer too - so fix the specification process.

User acceptance testing traditionally involved user representatives checking the system met their requirements. This is the real QA of the design - and these days it might look more like a beta release, or user testing of a prototype, or (if you’re feeling brave) feedback on a new feature in production. 

And what’s interesting about modern user testing is that it's an unbiased test of your design. Users never got to see your specification. They test against their requirements as they are today. Not what you wrote down in that research session 6 months ago. And unlike my employee users in the 90s, they can very often shop elsewhere if they don’t like what they see. 

But I wonder to what extent user unhappiness on a commercially important scale is actually driven by inconsistencies or minor deviations from the spec? I agree that consistency matters, and I do all I can to avoid or eliminate ‘design debt’ on projects I’m involved with. But I do try to bear in mind that, as a designer, I probably care a lot more about the issue than my users do.


Thumbnail photo by Carson Arias on Unsplash