There is a fundamental relationship between user experience designers and quality assurance engineers, and I think it’s time to take that relationship to the next level. User Experience (UX) Designers and Quality Assurance (QA) Engineers are both deeply concerned about the user, and everyone wins when they talk to each other early and often.
My QA counterparts and I both want the websites we deliver to be usable. We want choices to be relevant. We want things to work. We want apps to make sense. We don’t want modal windows to prevent completion of integral tasks. In short, UX and QA both want to deliver a product that won’t leave the user cursing the heavens, having to force herself into a Zen-like contemplation of kittens in Christmas sweaters in order to quell the slow-burning rage that threatens to destroy her as she tries to perform simple tasks like transferring money to a savings account, buying tickets to a ballgame, or monitoring a sick parent’s medication schedule. UX designers are the experience architects and QA engineers are the building inspectors of the development lifecycle. UX figures out who we’re building for and why, analyzes user and business requirements, and incorporates it all with stakeholder vision and known constraints. We then strive to design an experience that does no more and no less than what it needs to be. QA ensures that I, as a UX Designer, don’t make stupid blunders that will undermine my stakeholders’ goals and interfere with my users’ experience when all is said and done. Do developers help with this, too? Of course. And perhaps unsurprisingly, I also advocate for early and regular consultation between UX and development. But the type of value that QA can bring to a project when consulted early on goes beyond the type of specialized guidance and knowledge that even developers bring to the table.
To illustrate — if I’m designing a deck for my next-door neighbor who just moved his aging parents in, a QA engineer is the inspector that can inform me (before I’ve poured my footings) that even though I wouldn’t know by looking at it, the soil in my area is actually classified as a mixture of clay and sand, which means that diameter of my footings needs to be wider than it would in normal soil. This inspector might also point out that if my neighbor’s aging parents currently use power wheelchairs, or if they might need them in the future, it would be in my best interests to increase the diameter of the footings even further to accommodate the extra weight. And the inspector might lastly point out that with wheelchairs on the deck, I’ll need a ramp, and that the ramp ought to have a slope no greater than 9.5 degrees.
The most obvious software development analogue to that example is accessibility. Call it ADA compliance, 508 compliance or what have you; the point is that there are standards that you’re almost certainly not aware of for making sure that your application or website is usable for those with disabilities. But a good QA team has engineers that are steeped in those standards, and they know how those standards relate to every device you’ve targeted. Making changes to accommodate accessibility late in the game – or after your site is done – can be very costly, so why not have the conversation early on? Ditto that argument for data and application security. And ditto that argument for just plain old usability. Bring QA in for a quick consultation on your wireframes, and chances are you’re likely to save yourself some revisions.
As a designer, is it my job to think through use cases? Yes. Am I good at it? Yes. Am I able to consider every contingency of every scenario my project entails and implies? No. This is why a strong relationship between UX and QA is indispensable. UX Designers and QA Engineers have a similar mandate, but they fulfill it with different toolkits and from different perspectives. As one of my friends in QA puts it, “UX creates and QA destroys.” But we both do it for the same reason — we respect and love the user. QA engineers bring their extensive experience with devices, platforms, browsers, protocols and standards to bear on every project they touch. They are the brilliant generalists that throw our researched, prototyped, revised, and user-tested designs into the fiery furnace of the real world to see what burns and what doesn’t. Loop them in earlier, and you can avoid putting out fires later. So what does this collaboration look like? Here at The Nerdery we offer Embedded QA, in which QA is along for the entire ride on a project. We’ve seen tremendous success with this approach, but it carries some additional cost. The type of collaboration I’m talking about can be much leaner. It can be a conversation, or maybe two hours with an accessibility expert before you get into visual design to make sure your navigation scheme and color palette won’t set off red flags down the road. Build strong relationships up front with the folks that are responsible for signing off on your project down the road, and you’re guaranteed to save yourself time and headaches.