Make Products Look Good Before Releasing Them to Customers With Visual Quality Assurance (VQA)
Learn About VQA With This Comprehensive Guide
What Is VQA?
During VQA, designers and developers collaborate to ensure that hi-fidelity designs and builds align perfectly. This process involves identifying and resolving interface bugs and inaccuracies, fostering effective teamwork during a critical stage of development. VQA is a crucial step in the product development process, as it ensures that the final product meets the design specifications and provides a high-quality user experience.
Why Conduct VQA?
Failure to conduct VQA can result in solutions that fall short of expectations, potentially tarnishing the brand and user experience.
When to Conduct VQA?
VQAs typically follow DEVQA (e.g., stress testing). The timing depends on the methodology:
- SCRUM: Designers usually conduct 2–5 VQAs at the end of a two-week sprint.
- KANBAN: Perform VQAs as builds are ready for review.
Assign VQAs to the designer responsible for the design to streamline the process. Developers should notify designers when builds are ready by:
- Moving the story to a VQA column on Agile boards.
- Directly contact the designer or notify them during standups.
- Optionally assigning the designer to the VQA subtask on the ticket.
Once assigned, designers should prioritise VQAs to complete stories before the sprint ends.
How to Conduct VQA?
Preparation
Designers should familiarise themselves with the ticket details, including scope, requirements, acceptance criteria, and high-fidelity designs, especially if they were not involved in developing the solution.
Collaboration
Coordinate with the developer to:
- Schedule Demonstration: Address any discrepancies that do not meet expectations.
- TestBuilds: Inspect test environments for all potential scenarios.
- Record Scenarios: Obtain screen recordings with inspector features enabled for documentation.
Change Requests
Designers should document change requests using collaborative platforms like FigJam or Miro. For each request:
- Specify affected devices and breakpoints (if applicable).
- Identify scenarios to which the change applies.
- Define the type of change: edit, add, or remove.
Minor changes can be communicated directly to developers via Teams or Slack: Provide clear diagrams or conceptual models can be provided for reference to assist developers
Follow-Up
Designers must ensure proper development and sign-off by:
- Allowing developers adequate time to implement changes.
- Scheduling demos to review completed changes.
- Using colour-coded Post-it notes (e.g., green for completed changes) to track progress.
VQA Checklist
Web & App
- Is the design and build visually aligned?
- Are there significant issues or bugs to address?
- Have all acceptance criteria been met?
- Has the end-to-end journey been tested?
- Are global styles (e.g., spacing, typography, colours, buttons, shadows) used consistently?
- Is everything aligned to the grid, including the page container?
- Has the build been tested across various viewport sizes and orientations?
- Are elements scalable at 200% page zoom?
- Can text accommodate increased character counts?
Web-Specific
- Has the build been tested across browsers (Chrome, Firefox, Safari)?
- Are accessibility standards (e.g., touch targets, screen reader flow, tab order, alt text) met?
App-Specific
- Has the build been tested across operating systems (iOS and Android)
- Are all accessibility requirements delivered, such as touch targets, voiceover (content labelling) and tab order?
- Has the build been tested with increased font sizes or weights?
Summary
Effective communication between designers and developers is not just important; it’s crucial to streamlining the VQA process. The team can ensure a smooth and efficient process by limiting the number of VQA rounds and minimising assumptions. Once VQA is complete, the product owner will approve the release of the solution. Post-launch, monitoring performance is essential to ensure users interact with the solution as intended.
