Why Design QA should not be an afterthought

What does Design QA mean?

Design Quality Assurance is the process of reviewing the design of a feature after it’s been developed. 

• A designer compares the original designed feature to the developed version and captures design, interaction and user experience errors. 
• The team then works together to prioritise the Design QA feedback and update the developed feature before it’s deployed to production.

The goal of Design QA is to ensure the quality and expected design output is acceptable when the feature is released at the end of each sprint. 

So, how does Design QA fit into the bigger picture?

When a feature moves from requirements through to release, testing is undertaken within the development cycle. 

Design QA is often not included within the development cycle and left to the very end. The feature then needs to be coded again in the next sprint to fix the user interface and interaction issues. 

Within a good product design process, Design QA sits neatly alongside QA Testing. If the Design QA is included in the testing process, the feature is then completely signed off and tested within the same task. 

What does a designer look for when conducting QA?

When a Quality Assurance engineer conducts tests on the interface, they make sure the acceptance criteria are met. 

For example, if they’re testing a contact form, they’re testing:

• Does the error message display when a mandatory field has not been completed?
• When the user clicks on the ‘submit’ button, does it direct to a thank you page and is the enquiry sent to the correct email address? 
• If yes, then the functionality passes and the task is marked as complete.

But when a designer tests the contact form, they’re analysing how the form appears. 

They’re testing:

• Does the form appear consistent across devices? 
• Does the form have missing elements, such as a form field, button or hyperlink?
• Are the sizes of elements too small or large?
• Is the form using the correct spacing in between form labels and fields?
• Is the form using the correct font and heading styles?  
• Is the layout of the form correct?
• Does the ‘submit’ button have a hover state?
• Does the thank you page animate in after submitting the form?
• Is the form using the correct HEX colours from the style guide? 

Why is Design QA important?

Consistency is one of the most important principles of good product design. Over time, as the product grows, it opens up big inconsistencies across the user interface.

This turns into 'Design Debt'. Design debt is very similar to the term ‘Technical Debt’. While Technical Debt affects the integrity of the codebase, Design Debt affects the integrity of the user experience. Design debt is a combination of small, lost, design details that gather over time.

Some examples include:

• Incorrect spacing within buttons 
• Using the incorrect HEX value for colours
• Implementing the wrong font sizes
• Inconsistent spacing on multiple features.

All of this adds up to ultimately compete for the user’s attention and lead users down the wrong path.

For example, this event card below in example A has been QA’d compared to the example B, which has not.

The event card may not seem to have much of an impact but if you repeat it on an events page, the effects are far more drastic. 

It might seem that designers are being really pedantic, but small features may be repeated dozens of times and have an effect on the overall user experience.

Why is Design QA often missed?  

There are many reasons why Design QA is commonly missed, but the two main ones are:

Speed outweighing quality – Teams often prioritise speed over quality when building features. The design quality is first to be deprioritised. This is due to the lack of understanding of how design and user experience impact the end-user.

A user does not interact with a jpeg mockup – Teams can sometimes forget that users don’t interact with the designed jpeg mockups at the end. They interact with the fully developed user interface within the browser.

The perks of Design QA

There are so many fantastic benefits of conducting Design QA:

Collaboration – It keeps an open and honest communication line between all team members, which is a key aspect of a team’s success. 

Saves time – Including Design QA within the process saves time in the long run. Instead of developing in one sprint and going back and updating in another sprint, each item is tested and released in one go. 

Education – If a designer is constantly testing features, there will be a greater understanding of technical limitations as they appear. It prevents the designer from including these issues in future designed features.

Reduces brand degradation – And for the Product Owner, it helps to reduce brand degradation across all platforms. 

Tips for Design QA success

There are some very quick and easy tips to follow to make Design QA as quick and easy as possible.

Have a Design System – Number 1 tip for Design QA success is having a Design System. A design system reduces the amount of Design QA feedback. It outlines global heading and body font styles, grid, spacing scale, form styles, and button styles. It’s also very important to make sure the team follows it from design through to development.

Focus on small features – Focus on one small, deliverable feature at a time, rather than building an entire page. Small feature = tiny list of Design QA tweaks; a page with many features = large list of Design QA tasks.

Include design in the Acceptance Criteria – Include ‘Design QA and QA testing complete’ in your Acceptance Criteria within the task. This will ensure it’s always done.

Design to development handover – Be sure to organise a scheduled handover to the developer each sprint. Keeping open communication between the team and asking questions early on removes misinterpretation of the original designer’s intent.

Document everything – As soon as the feature has been designed (and handover is complete), document all of the interactions. This allows a central space for all team members to refer back to when building out the feature.

The wrap-up

Design QA has long stood in the shadow of its technical counterpart, but relegating it to a secondary consideration will almost certainly come back to bite you down the track. Allowing Design Debt to accumulate will not only ultimately become a headache for the product team, but it also has the potential to impact the user experience. So remember to always incorporate Design QA into the overall QA process, and watch out for Design Debt - it’s a real thing!