Design QA: a powerful but neglected step in Agile Development

“We’ve successfully made the first release of our product and our users are going to love it!” announced the product owner of one of the agile teams I was working with. Since I heard everyone speak so highly of the released work, I decided to see what the developed product looked like. I couldn’t believe my eyes at what I saw. It was misaligned, chaotic, and definitely not user friendly. The interesting thing is that this wasn’t the first time in my work experience where a developed product looked so different from the design.

In the software world, “Agile” has become the magic term and a preferred solution to product development due to its iterative nature. As a designer, the reason why I like Agile methodology is that it can seamlessly blend the ‘Design Thinking’ framework into product development.

https://www.researchgate.net/figure/Applied-design-thinking-and-agile-development-methodology_fig4_328861078

When we think about the integration of design thinking with agile, oftentimes it gets portrayed as if there’s no real overlap between the two, and hence, designers on the agile team are considered as more of supporting resources. Except, there is one major overlap that gets overlooked - the Quality Assurance or QA. Most agile teams will have a dedicated QA resource that is responsible for reviewing the overall quality of the product. However, what gets missed in that review is the quality of coded UI. This is where the designers come in as a part of the mainstream agile process to conduct a design QA.

What is design QA?

Design QA is a review of the developed UI against design to assess the visual quality of a product by making sure that the design and developed UI match.

Why should designers care about QA?

1. To capture usability issues before the release — The quality of a product shouldn’t just be measured in terms of its technical soundness, because a technically sound product may still have usability issues. If those issues get caught before the release, their repair can be planned efficiently.
2. To catch accessibility issues — Often times designers use high-quality machines such as the Macbook for designing. Macs are known for having an excellent screen resolution. In reality, our users may not use that quality of the screen. Hence, it is important to conduct design QA on a targeted device so that we can catch accessibility issues such as low contrast.
3. To maintain a consistent visual language — Every successful product has a visual language associated with it. This consists of basic design elements like colors, fonts, iconography, etc. When a product is shipped to its users, the users subconsciously start associating these visual elements with the product. Hence, it is important to catch inconsistencies in visual language through design QA.

What should designers review for QA?

• Placement of visual elements such as images, text, buttons, icons on a page and general alignment of those elements to each other
• Fonts — Size, weight, and color of fonts used on a page as well as the line-height of the body copy to ensure readability
• Colors — Making sure that the colors in the coded version use the same hex value as the design in order to ensure accessibility
• Interactions — This includes micro-interaction animations as well as CTA interactions such as hover, active, error, disabled states
• Contrast — Making sure that there is enough contrast between foreground and background and making sure that the contrast passes accessibility standards
• Overall consistency between the design and the coded version

General best practices for conducting design QA

Unfortunately, there isn’t a universally used method for design QA. But the following has proven helpful to me in the past —

• Documenting your feedback from the QA review in a way that can be easily handed off to the developers. e.g. using tools such as JIRA, Confluence, Asana
• The feedback from the QA review should use development terms instead of design terms. e.g. using terms such as ‘margins’ and ‘padding’ to indicate spacing.
• Creating a side-by-side comparison of the designed and developed version in Sketch, InDesign, or Word and jotting down the inconsistencies.
• If a product team uses tools such as JIRA, a subtask for ‘Design QA’ can be created for UI epics to ensure that it goes through the designer’s review prior to release.

References

1. BRENDAN MAHONY. (Jan 22, 2019). Make design QA official
   https://uxdesign.cc/make-design-qa-official-5aea540ae907
2. ANGELA DELISE. (May 4, 2019). The QA Process in UX Design
   https://blog.prototypr.io/the-qa-process-in-ux-design-7cd3ffa771ad
3. JAMIE O’LEARY. (Dec 5, 2018). Systemizing Visual Design QA
   https://rangle.io/blog/systemizing-visual-design-qa/