Make products look good before releasing them to customers with Visual Quality Assurance (VQA)

Learn about VQA in this comprehensive guide.

What is VQA?

During VQA, designers and developers work together to ensure that hi-fidelity designs and builds are aligned perfectly, checking for interface bugs and inaccuracies. It’s a crucial time for both parties to collaborate effectively.

Why conduct VQA?

Failing to conduct VQA may lead to the release of solutions that do not meet expectations, which can harm a brand and the user experience.

When to conduct VQA?

VQAs are typically addressed after DEVQA, e.g., stress testing. If using the SCRUM methodology, designers typically conduct 2–5 VQAs at the end of a two-week sprint. If using the KANBAN methodology, designers embark on VQAs as and when builds are ready for review. A tip is to assign the VQAs to the designer who made the designs for faster processing. To inform designers when builds are ready for review, developers should follow these steps:

1. Move the story into a VQA column via Agile boards
2. Contact the designer directly and or notify them during daily standups
3. Assign the designer to the VQA subtask on the ticket (optional)

Fig 1.1 — app team KANBAN board showing DEVQA and VQA swimlanes

When designers are assigned a VQA and receive build links, it’s crucial to prioritise it over other tasks in the development backlog and start working on it immediately so stories can be closed before the end of the sprint.

How to conduct VQA

Before undertaking VQA, designers become familiar with the ticket details, including the scope, requirements, acceptance criteria, and hi-fidelity designs — especially important if you were not involved in the solution development. Designers must coordinate with the developer who created the build to:

1. Schedule a demonstration and address any discrepancies that do not meet your expectations.
2. Receive links to test environments to inspect builds for all ‘what-if’ scenarios.
3. Obtain screen recordings for all ‘what-if’ scenarios with the inspector feature enabled.

Designers should capture change requests in collaborative platforms like FigJam or Miro with digital Post-it notes. On each note:

1. Specify which devices and breakpoints the change will affect (providing there’s more than one).
2. Specify the scenarios to which the change applies.
3. Specify the kind of change with one of the following actions: edit, add and remove.

Fig 2.1 — designer screenshot showing FigJam canvas with completed change requests (green Post-it notes)

For minor changes, send them directly to developers through communication channels, e.g., Teams or Slack. Developers can benefit from referencing a straightforward diagram or conceptual model to facilitate modifications.

Fig 1.2 — designer submitting a change request to adjust the recently viewed card touch target area via Microsoft Teams

Designers must also: Ensure proper development and sign-off by providing developers adequate time to make changes and schedule demos. Show completed changes in a different colour digital Post-it note, e.g., green. Capture any further modifications using the previously described methods.

VQA checklist

Here are some things to keep in mind when performing VQA.

Web and app

1. Is the design and build visually in sync?
2. Are there any significant issues or bugs that we need to address?
3. Have all the acceptance criteria been met, and has the end-to-end journey been tested to ensure it functions as intended?
4. Are global styles used, e.g., spacing, typography styles, colours, buttons, drop shadows, and border radiuses, rather than inline styles?
5. Is everything aligned to the grid, specifically the page container?
6. Is the build tested on multiple viewport sizes? E.g., portrait, landscape, mobile, tablet and desktop, at various widths.
7. Are elements scalable with an increased page zoom of up to 200%?
8. Are elements scalable when the character count of the text is increased? (see image below).

Fig 3.1 — developer screenshot showing an increase in the character count of the text

Web

1. Is the build tested with increased font size or weighting?
2. Is the build tested on various browsers and operating systems, including Chrome, Firefox, Safari, iOS, and Android?
3. Are all accessibility requirements delivered, such as touch targets, screen reader flow, tab order, heading hierarchy (markup), alt text and aria labels?

App

1. Are all accessibility requirements delivered, such as touch targets, voiceover (content labelling) and tab order?

Fig 3.2 — developer screenshot of the latest build, including the designers’ requested changes to the touch target area in VQA

Summary

Designers must communicate their expectations with developers before a build commences to make the VQA process more efficient and establish a better rapport, eliminating assumptions and limiting the number of VQA rounds to a maximum of two. When the designer closes VQA, the product owner approves the solution for release. After launching a solution, it’s also integral for teams to monitor its performance to ensure users are operating it as intended.