UX designers and QA engineers — crossing our T-shapes for better collaboration

Complex digital products are like symphonies — they need an orchestra full of different musicians — a multidisciplinary team. We find ourselves continually writing about collaborations between different specialists and their roles within digital project teams. This time around we’re focusing on the synergy required between UX Designers and QA Engineers.

As a UX designer, I have, in the past, participated in projects where I had no direct collaboration with the QA engineers or testers. They were the people who started working on projects after all designers were done and had moved onto new projects. However, subsequently, I’ve learned how similar test documentation is to some UX deliverables — specifications and scenarios. Having said that, my deliverable was still (unintentionally) different because I didn’t know how testers worked. As it turned out we were doing almost the same work twice and even more frequently some intentions were lost in translation!

I was very happy when I encountered a strong Quality Assurance culture throughout each project at WeAreBrain and made a commitment to help strengthen it. I realised better collaboration between UX designers and QA engineers and better utilization of our combined knowledge and skills would only profit all our projects. So in the name of collaboration our QA Lead Vasfie, and I wrote this article together.

We believe that quality assurance is a process from inception and through the whole lifetime of a product or service, not a one-time role or just one person.

Project initiation — start together

During project initiation, it is all about communicating the quality expectations. These expectations from the business owner, will, among other factors, influence high-level planning and the core team. Representatives from UX design and QA engineering teams must be present during the kick-off workshop. If possible, include the individuals who will be involved throughout the project.

Discovery — QA playing BA

The Discovery phase is about understanding the proposition, the users, business, context, and technologies. It is also a phase for forming the backlog and interactive high-level design of the UX and the system architecture. We do it through research, analysis, and iterative high-level design. While at WeAreBrain, the UX designers were core participants of this phase already, we’ve started involving the QA engineers more and more.

The UX designer and the QA engineer on the project share the responsibilities in tactical business analysis. At WeAreBrain, our QA engineers are responsible for eliciting and challenging the non-functional requirements. Some testers with a more technical background also support the technical analysis. They guard the conditions that are needed to begin ensuring the quality: completeness of requirements.

Experienced QA engineers also provide advice around the skill level of the team, the delivery process and the timeline needed to ensure the expected quality level.

QA together with the product owner, the UX designers and the architects start the documentation (the use cases, Definition Of Done) that will help evaluate the test documentation through the project. This should not be seen as double work, but rather as an iterative transformation from the same source.

Definition Of Done (DoD) and Definition Of Ready are agreed to before the start of implementation i.e. the start of development sprints. The product owner, QA, and designers work together on DoR and DoD to ensure transparency and quality fit for the purpose of the product.

Implementation — continuous refinement

Even in a Waterfall project (and small projects with strict deadlines should be done in a well-managed Waterfall), it’s not possible to predict all the details that will influence implementation beforehand and foresee all test cases. In an Agile project process, details are refined just a few steps ahead, so designers need to stay involved in the project, even if it’s just part-time. All QA engineers should expect and demand not only development-friendly but also tester-friendly documentation from UX and UI designers as well as from the copywriters. If the implementation within a particular sprint is a piece of desired design, the designers and copywriters need to create a Story-scope design document, that they describe in a particular ticket in Jira. The Jira Story/Task will then be tested not only against the overall documentation but also against the partial scope in the ticket.

Testing — designers as the first-line testers

People who decided on the solution — the product managers and designers — are potentially the best people to test an implemented solution. However, it’s important to note that testing the software goes beyond the user interface, there are also the complexities of effective and efficient continuous testing on multiple devices and situations that can be best done by test professionals, ie QA engineers.

At WeAreBrain, we are experimenting with designers doing the first round of testing of elements that will be experienced by the user. They check the user experience only in one browser, on main screen resolutions and devices. As we design a lot of conversational user interfaces in which the dialogues and the words are the UX, design testing is not only about the graphical user interfaces. After the issues found by the designers are fixed or the deviating implementation is accepted, the feature is ready to be tested fully by our QA engineers. In the case of accepted implementation that is not in accordance with the latest available documentation, the designer is responsible for altering the documentation so the testers actually know what to test against.

We find ourselves experimenting in the designer-friendly format of recording the found bugs or just unexpected results that do not fit the quality standards (we cannot predict everything in design). Screen captures and recordings, Responsive Web Design Tester Chrome extension, very simple plain language in a single Jira ticket attached to a Story are all our mix of solutions at the moment. Designers rarely use special pixel-perfect testing tools like PerfectPixel because they can visually judge if the result in the real browser with the real content appears according to their expectations for this particular product. Originally, our UX designers communicate the solution in Confluence and in interactive prototypes and our UI designers in Zeplin. However, collaboration with implementation engineers is a topic for quite a different article.

Advice for project managers, scrum masters, and resource managers

• Include your UX designer and QA engineer in the project kick-off.
• Ensure your UX and QA know each other and agree on methods for collaboration, documentation, and hand-off from the beginning of the project.
• Consider involving a QA Engineer in the role of the analyst in the Discovery phase.
• Plan your UX and visual designers for the first round of testing of the elements of the system they’ve designed.

Looking into the future of UX designers & QA Engineers collaboration

Expert usability evaluation: the perfect duo

While direct evaluation with real users is always preferable, it could be effective to start with a round of expert evaluation. Heuristic evaluation should never be performed by just one, even a very experienced expert, as the bias would be too strong. Designers and testers tend to analyze a product from different angles and as a result, are more likely to identify a wider set of areas for improvement. An experienced UX researcher or designer together with the QA engineer form the minimal-viable-team for Expert usability evaluation.

Testing with the users — new terrain for our QA engineers

While all UX designers love to test their prototypes with real-life users, direct testing with the user is not in a QA engineer’s typical toolbox. We believe in compact teams with feasible T-shapes and believe that QA engineers could assist greatly during user testing by learning some usability testing tactics. With their patience, attention to detail and unbiased attitude towards the solution (they haven’t designed it :)), QA engineers make great note takers and provide the additional brainpower that is required during the analysis of quantitative results.

After go-live monitoring — the next level for a true QA

The real proof is in the pudding: the product used by real users in real life. We are looking into ways to grow processes and habits to monitor the quality in the eyes of the real beholders, the users.

Our intentions are to really interrogate the voice of the customer by using various analytics results as sources of learning for product improvements as well as validation of our own assumptions on what quality aspects really matter to the users in the wild.

In conclusion, I believe, that to assure the client of the quality of the product, designers and QA Engineers need to collaborate closely from the initiation through the real-life product performance. To do so, we both need to extend our common skills.

Interested in more QA content? Check our other article for an SEO QA checklist.

Anastasia Gritsenko

Previous story

How Gen Z is using social media

Next story

The new era of influencer marketing