Usability is nothing new to IT, software, or design. It is one of the fundamental building blocks of the UX practice, and is the grandfather of evaluative UX methods which help us to judge the effectiveness of the solution we are constructing. Despite its history, recent usage has given it a layer of tarnish, making it a hard to sell and hard to include where it could do some good.
In previous installments I have re-introduced you to usability as a part of the user experience process and practice, dusted off the value and offered it to you both plated in gold and on the cheap. Also I have explored how poor use and understanding blackened its name, and told you what lies in wait if you leave it out. Last time I told you not only how you can use it but also when. Finally, in part four, I’ll show you how it could change what we presently think of as QA.
When you want to get everything right
I’ve said previously that usability sometimes coincides with and is then presumed to be a QA function. I have also said that this perception is primarily the result of the timing with which it is frequently applied, and the time and budget available to fix things. Based on what I’ve said in previous posts, you might expect me to repeat what I’ve said about leaving usability until too late in the project. To those I say; Don’t leave your usability until too late in the project. If you want to know why, you may want to revisit parts two and three of this series. If you find yourself taking offense that any UX method could possibly be seen as a QA measure out of a sense of injured professional pride, stop. Before you warm up even one more indignant neuron, let me turn that on its head.
Hey! You got your QA in my UX
Much of what we do in UX is, when you boil it down far enough, is a QA measure. Which is to say that its purpose is to improve the quality of the product and the experience of the user interacting with it. We do research with users to ensure that the we design the right thing to solve the right problem. Then we test with users to determine how successful we have been in our designs.
Usability, and evaluative UX methods in particular, are the only way that we can objectively evaluate design by engaging with real users to evaluate our work. This is not a test of “did it work as it was intended to”, but instead a test of “is this intended to do the right thing.” It is in this regard, as a tool for ensuring design quality in particular, that usability stands shoulder to shoulder with established QA practices when they test the designed functionality of developed code. So yes, UX is QA.
Nuh-Uh! You got your UX all over my QA
QA, as a practice, has it’s own problems. The greatest of which is the fact that they are consulted at the eleventh hour, when their expertise and findings are more difficult to act upon. Does this sound familiar? I think QA should engage early and often, in much the same way I think evaluative UX measures should be taken early and often. Now, with that idea tickling your synapses, it should seem only natural that QA professionals should become UX professionals. From the ranks of testers, technicians and troubleshooters, we can grow usability analysts. We can build partnerships that surround a project – testing and improving it from early discovery to post-launch management, not just from ideation to launch.
We can arm QA departments with valuable UX tools and methods that they can apply either on their own and in partnership. They can continue to actively support the success of the project by doing what they do best – poking holes and breaking things. They can also engage with the project at more points in its lifecycle. Finally, they can do formally what they’ve always done quietly; evaluate with UX in mind. And in this, QA is UX.
The Efficiencies of Partnership
Not every organization will have the ability to have UX and QA work closely and cooperatively. Not every organization has both departments in-house. However, if those of us in UX, and our colleagues in QA both start viewing our roles as complementary, and start working from the same basic play books, the opportunity to collaborate improves regardless of whether it’s within or across companies.
By linking UX and QA, UX maintains project visibility for more of the lifecycle, beyond the inception of the development phase, and in return QA gains formative input and can raise concerns when they arise throughout the project. We also double our resources when it comes to staffing our evaluative efforts. Methodologies, insights and resources can be shared to ensure that projects get the care and attention they need throughout their lifecycle.
I hinted a bit at what QA staff can do as UX Analysts, but let me be more concrete. There are many tasks and services that can be accomplished in partnership with QA, or offered whole and complete by a QA department.
Heuristic Review (Investigation, done in a Discovery phase)
Usability/Task Analysis (Evaluation, done in all phases)
Accessibility Audits (Evaluation, done in all phases)
This allows QA departments to be more proactive, more engaged with the project’s health and success. Also it opens new revenue streams and engagement models that allow QA to show it’s value either in standalone engagements or as part of a larger project. In working with UX, we multiply the reach of both practices to positively affect project outcomes and finished products.
To sum up
UX has similar aims as QA. QA has the same overall goals as UX. There is a lot to be gained by building a common vocabulary, toolset and partnership between the two. Each can further enable the other, and together the combined resources and expertise can transform our expectations of project success. So, UX and QA professionals…get on that.
A final thought on usability
If you come away from here with one thought I would prefer it be this: The thought that you should be doing more usability. That you should want your designs to be vetted as thoroughly as your functioning code. That you should care about quality enough to apportion the time and budget to get it right, rather than eat the time and cost of fixing it when its wrong.
It doesn’t have to be expensive. It doesn’t have to be elaborate. But it should be in your project process. You should have space to size and plan and implement evaluations at the right times and in effective ways. You should include evaluative tasks in your projects. You should test your stuff.