Want Better Design Work? Get Quality Assurance on the Task

Designers design, and testers test, but when they work together, great things can happen. We explore how integrating quality assurance into the design process can be beneficial to both sides and the project itself. 

Whenever I’m working on a design and ask somebody from the quality assurance team for their help and opinion, I regularly get the following disclaimer: I’m not a designer, so I’m not sure if my feedback will be useful. 

Contrary to popular belief, it usually is. 

If I am working on a new feature, I prefer getting feedback from people who are experienced in the domain, regardless of their profession. 

Including software testers in the design process can be extremely useful. In this article, we’ll take a look at five activities where collaboration with software testers can produce excellent results.

Having a tester present during design refinements makes the meetings significantly more efficient. They are experienced in the domain, really good at finding flaws, and know the app quite well, both from a technical and user experience perspective. Their feedback makes making design decisions much easier.

Here are a couple of reasons why the quality assurance team can be a great asset in this step:

Testers are a great fit for usability testing because they have a better perception of the product’s “big picture,” they are experienced in evaluating products, and they always do a great job documenting issues. 

In most usability testing sessions I was leading, project managers would be the ones taking notes because their skills are quite versatile. However, testers can be just as useful here. After all, usability testing is the process of evaluating a product or service by testing it with representative users. Since the goal is to identify any usability problems, collect qualitative and quantitative data, and determine the participants’ satisfaction with the product – testers are a great fit.

The preparation and planning phase consists of the following:

When testers are involved in this phase, they get to see an early preview of their work. The planning part of a testing session provides some context for the testers, which will help them test the implementation later on. Selecting the participants gives them a better understanding of the target audience, and the test scenarios users go through are very similar to test cases QA specialists will be dealing with when it’s their turn to test the implementation.

Conducting usability testing includes the following:

Testers can notice nuances in user behavior and interaction with the product, uncovering potential usability issues that may have gone unnoticed otherwise. Being included in this part of the process helps them, too – by being aware of the main issues encountered, they can know what to pay special attention to during their round of testing. 

There are three main aspects in the analysis and reporting phase:

Testers excel at documenting observations accurately and comprehensively. Their eye for detail allows them to catch both minor issues and overarching patterns, which is a big help in the analysis phase. By being included in all these activities, they can help with creating a report as well.

When the developers release a new app build, testers and designers tackle it separately. The QA team ensures all parts of the app are working as expected and incorporate the design. The design team only does the latter, paying special attention to details in the UI.

The testers’ work is usually planned to align with the development process release cycle. That’s why they know exactly when each build will be created. On the other hand, designers’ work is planned around design priorities, and it may be difficult for them to check the UI of any new builds in a timely manner. 

This is one area that can be substantially improved by designers and testers working together.

Here’s what this can look like in practice. My tester colleague and I periodically organized a short session to review the differences between the design in Figma, the implementation, and the open tickets. Since testers are experienced in reporting bugs and opening tickets, they can teach designers about the best practices. This approach worked amazingly for us.

We assess the accessibility of a digital product by observing its various features in the light of different accessibility criteria. These criteria range from very UI-specific ones, such as text size and color contrast, to the product’s compatibility with assistive tools. 

While designers are well-positioned to assess UI-related criteria, testers play a crucial role in evaluating the app’s compatibility with assistive tools. They can utilize tools such as screen readers or keyboard-only navigation to see where the product may not meet accessibility standards. BTW, if you would like to learn more about testing features with accessibility in mind, this article is a good place to start. 

Let’s make it clear that not every tester is expected to have experience working with assistive technologies, but being aware of accessibility criteria is very beneficial to understanding accessibility.

To create a truly accessible product, accessibility standards need to be taken into account at every step of the development process. That’s why I would like to emphasize that the collaboration between designers and testers would not be enough to ensure the full accessibility of a product.

Testers prepare test cases based on feature requirements before they even see the implemented feature itself. To understand the feature in context, they can take a look at the design specification. They may come across states that are missing in design, and that way, improve the features and their documentation. 

Developers pay the most attention to Figma when they are implementing a specific feature. Once it’s implemented, they rarely need the design unless they want to revisit something. However, during testing, especially regression testing, the QA team tests the complete app and compares everything with the design files. That’s why it’s crucial to have a detailed design documentation of the app, even for features that were developed a long time ago. When this is the case, testers can point out parts of design documentation that are outdated or not specified well enough.

The goal of this initiative is not to overwhelm testers with a ton of overhead. Of course, not every tester is interested in design, and I’m sure there are areas of quality assurance as a discipline that can evolve without integrating with design. 

The goal is to explore the potential of this collaboration and how it can improve the entire development process. When everyone is aware of the possibilities, they can implement the recommendations where it makes sense. We want to spark interest in the benefits of collaboration, not lay down a bunch of new rules. 

The idea is to use each team’s strengths to make better products and keep an open mind to new ideas that arise from working together. Let’s take those opportunities when we see a fit and see how we can all benefit from QA and design’s teamwork.