Something I’ve noticed frequently overlooked is the partnership of UX & QA. This relationship seems easily missed yet holds so much potential to seal gaps in understanding for the QA team as well as provide early feedback as well as notice of incomplete features. When paired, UX can gain advantage in the process to adapt to challenges as they arise.
I’m fortunate enough to work with a QA team at it’s finest, who accumulate to be some of our strongest domain experts. They test in the pattern of use cases, flushing out the most important features, and prioritizing bugs by how dramatically they affect these key flows. They built their process with assistance from UX, developers, and POs. The creation of this process started with taking the user personas and key user flows that UX and POs had created for themselves. This crafted system allows them to confidently focus on vital features and easily tag a low priority bug from a showstopper.
Another benefit yielded is that they are now testing in specific personas. They understand their role whether it be a merchant or end user, and they test knowing what this person would care about. When they test in this manner they are assuming an empathetic role in the same way a UX designer would. From this mentality, I have been able to get accurate critique on friction in my flows or get a heads up on pain points that I had missed.
A simple example of this lied in the Review page of our Checkout flow I had designed. I had felt confident in it because I know checkout flows confidently, I knew the important information was there, that I had crafted some finer details to make the absorption of this information smooth and fast. Yet, when our mobile native QA ran through the checkout process, she told me that she kept thinking she had made the purchase at that point already and that she had been worried that it wasn’t even her first time doing so. I had team members run through who confirmed this, and even later when I had run user testing sessions, I ended up with the same feedback again. The issue itself could potentially cause a significant decrease in conversion rates but was so easily fixed by adding another “Place order” button to the top of the screen for clarity. A fix which we had out sooner in due thanks to our attentive QA team.
Our QA do reference mocks, however, they don’t waste time on pixel perfect match ups. Most of the time, they review the journey, their test plans, and then take a look through the mocks for reference. Then they test almost agnostic of the mocks after this, focusing entirely on the flow and function. To me, this is ideal. They aren’t bogged down with the concerns of minor UI despite being vigilant to anything that looks abnormal to the overall experience. If they don’t notice an outlier it’s a confident bet that a true user wouldn’t either, allowing us even more ability to hone our attention to where it’s needed most while losing the least amount of speed possible.
The relationship between UX and QA does go both ways. Where QA has learned behavior and skills of UX in order to help prioritize and assist, UX should do the same. Our sprints run in 2 week cycles, meaning that in our speed we sometimes are taken further out of the design for overall experience and end up fixating on particular pieces - as most designers know this can easily lead to breaks in paradigms and ignorance of the established design system. When we as UX become engaged in doing QA, we are able to step back and have that larger look at our design. We regain the familiarity we might have lost in a chaotic sprint. UX isn’t intended to take a large load off of the QA team’s plate, but we do bolster our own skills and allow that bond between our roles to strengthen.
When UX and QA have their processes merge, both sides benefit. The teams are engaged and learning. The users are always at the helm of our concerns but without costing us any business requirements or restrictions.