How involve design team in testing for better user experience

Written by Elena Khaitsina, Lead QA Engineer at Noda.

Usually, the common practice in Agile teams is that every department has well-known roles and responsibilities.

For example, for the development team to work on creating code and unit tests. The business analysis team focuses on defining features that users will love, and simultaneously the design team explores the best ways to bring ideas to life through prototypes or design templates. The QA team plays a crucial role in validating the product.

However, not everything goes smoothly in the Agile process.

From my experience, the primary bottleneck often arises when conceptual ideas confront the reality of implementation. For instance, designing a feature in a tool like Figma may differ significantly from how it's eventually implemented.

Sometimes the differences were significant.

Besides checking the correct operation of created applications the guys from the QA department also verify the app views by checking the general appearance and the correctness of styles and content.

You’re almost ready to launch, but then you discover that you’ve focused on all the wrong things from the beginning: on the design phase.

In light of these challenges, a compelling idea emerges: "How can we avoid this situation?"

To address this, a potential solution is introduced – the use of Acceptance Testing by the Design team. This approach suggests involving the design team in acceptance testing to ensure that the final product not only meets functional requirements but also aligns seamlessly with the envisioned design.

Why is it so important?

We know you’re probably wondering “Why bother?”

The first and main reason is to find deficiencies between the design and implementation.

This includes not only functional discrepancies but also ensuring that the visual aspects align with the initial design.

Besides this, it helps a lot at the stage when the design doesn’t contain all the elements described in the requirements, e.g., missing buttons.

Just for notice!

"design testing is NOT the same as testing responsive design."

While responsive design testing focuses on adaptability, design testing involves a more comprehensive evaluation of the visual and interactive elements.

The second reason is to review if all design solutions work in real life. It's not just about functionality but about how users interact with the design elements in practical scenarios. This step ensures that the design not only looks good on paper but also functions seamlessly in the hands of the end-users.

Of course, the prototype can help with this in the early phase but it’s not always time or needs to draw prototypes for small features or changes.

The third reason is to get to know the application inside and out. It helps to be up to date with the functionality of the product. Also, the future design and implementation will be designed within the current features, ensuring a seamless and consistent user experience across updates and iterations. This comprehensive understanding aids not only in current testing but also in making informed decisions for future design enhancements and feature implementations.

Design testing in practice

The process of product development has remained almost unchanged.

The only additional step has been added and now the process becomes like this: when the testing phase is completed on test environments, a separate Acceptance Testing (AT) task is created. This task is assigned to the person responsible for the design of functionality.

There’s one very important thing to remember!

Design activities are an integral part of the User Story and are included in the Definition of Ready. This means that the story/features can’t be moved further along the flow. Therefore, if a design has bugs, then such a User Story cannot enter the development stage.

Next, the ball goes to the design team's side.

The design team conducts a thorough review and provides feedback to the entire team.

If needed, some changes in the current implementation are done.

After all corrections, one more round of AT is initiated.

If everything is OK – the AT is closed.

Finally, the product is ready for the real user!

Notice!

If the designs require corrections, you should do it as soon as possible and “freeze” the final version. Then, update the documentation/requirements. This will ensure development is conducted on the set-in-stone version.

Benefit from design testing

The benefits of design acceptance testing are vast. It’s not very time-consuming and it certainly adds value to the software development quality process.

There are some points:

1. Generate new ideas you may not have thought of before while making prototypes and/or design templates.
2. Feel confident in your product design decisions.
3. Detect errors in the test environment before the customers will see them, which means much lower costs of improving them.
4. Pay more attention to UX design. By clicking through the app you can check how easy it will be for real users to orientate not only to small new features but to the whole product.
5. Check the differences/consistencies in the general design decisions relating to content, fonts, and colors.
6. Testing provides necessary evidence of intuition and helps designers to alter products and services where required.

Conclusion

Everybody knows that the quality of a product is the responsibility of the whole team – not only the Quality Assurance Department. This rule also works in the Noda team

Moreover, Acceptance Testing (AT) by the Design team is not a replacement for User Acceptance (UA) testing by the QA team. Both play crucial roles in ensuring a robust and user-friendly final product.

Both are crucial in ensuring a robust and user-friendly final product.