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. This week I shall tell 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.
Judging the size of usability
While we can plan to always test something, that doesn’t mean everything needs the same amount of testing. Its true that not every project will need the same level of evaluation. However the gradient to judge these things is fairly simple.
The more common your design, IA and interactions are (a WordPress brochure-ware site with a modest ecommerce implementation) the less you’ll need to test.
The more novel or unique your design, IA and interactions are (some crazy new set of widgets that will change everything) the more you will need to test – and the more novel your testing methods will need to be.
There are no gotchas here – just an intention to do it right that can then be scaled appropriately to the needs of the project. Also, don’t make the mistake that a common interaction is by nature free of any testing burden. Just because a pattern or widget is well understood, it does not mean that the interaction is appropriate, properly labeled and implemented in way that supports the user. You still test. You just test appropriately. So the next thing you need to work out is when to implement the testing you know you need to do.
Timing your usability for best results
The best approach is to expose any designed solution to user feedback early and often. It is safe to assume that presumptions and gaps in understanding will cause some degree of failure in any project. However, if we plan to fail early during ideation and design when it’s cheap and easy to adapt and change, we can then watch the points of failure decrease – and then disappear – as the project progresses. Usability testing provides the mechanisms by which design can be evaluated and that value and effectiveness can be judged. Ongoing checks can then provide a level of confidence that the designed solution meets any known or discovered need.
Okay, so when exactly do we test for usability?
It occurs to me that “when” can still seem vague, so let me be clear. I do not mean “on a Wednesday before noon.” Although how any specific timeline works and the length of the project may vary, there are five points in the project lifecycle where usability can improve your work. All you ever need at any of these points is a thing to evaluate, and users to evaluate it.
Testing present state
This brings users into contact with an existing tool, app, or other artifact as part of discovery. It can be applied to a current version to inform a redesign, or be applied to competitors to discover design gaps and opportunities.
Imagine a competitive analysis that isn’t a list of what the competition has, but is instead is a breakdown of what they have that is valuable to users, and why it’s valuable or why it’s not. Imagine not having to guess at where your users are feeling frustrated as you choose what changes to make, because you’ve been able to watch them use your tools and seen their pains firsthand.
Testing the concept
At this stage you may be testing a storyboard, flow diagram or other very high-level concept. Just enough to get your idea across to see if it seems to be of value to the user, and worthy of continued development.
Here is where you can make some of the big decisions, test the big assumptions and ask the big questions. Why are we doing this? Will doing this yield real benefits, and to whom? Are we solving the right problem in the right way? Testing the concept with users is a method for moving away from holding your ground and into sprinting ahead.
Testing an articulated prototype
At this stage you have a more concrete and robust representation of what you’re making. It could be an interactive prototype, clickable PDF, paper mockup or any well-articulated version of what you are working on to test with users. Interactions may be limited to a representative sample, but you should have enough to be able to gather feedback to see if your layout, interactions, labeling and flows have any major flaws.
If you had to choose just one place to test, this is it. It’s early enough that sweeping change won’t kill the budget or timeline, and late enough to have a more concrete representation of what you’re building to test against. If you also tested the concept, you get to see if your fixes were effective. Methods and fidelity will vary, but the important thing is that at this point in the project things are still malleable.
Testing a developed prototype
This is what most people already think of as a “prototype.” It may be a whole or partial/representative solution. It will likely at this point be built in front-end code and have a layer of styling applied. The back end may still be decoupled, and data may be static, but “real-looking.” This is where we test in hi-fidelity.
When the visual design is incorporated and real interactivity is introduced, it helps to revisit things with users. You can recheck that problems found earlier have been resolved and that more complex interactions work as the users expect them to. Furthermore, you can ensure that things like color, typography and final placement and behavior are not introducing new barriers to users’ use and understanding.
Testing the deployed solution
This effort occurs when all the development work is complete. It may be during an alpha or beta release or even after full launch. Its purpose can vary based on the timing. If executed post-launch it either informs the next phase of work, or becomes part of the user-feedback cycle of a planned product-management regimen. If executed in an alpha or beta release, it allows for fine tuning of the interfaces and interactions.
It’s impossible to be too positive about testing to make good things even better. A late test like this allows real user feedback and analytic data to be combined with qualitative user tests to add the layer of shine one expects from a best-in-class solution. This perhaps points to something that should have been clear throughout: that when you test with users, things get better – and the more you test the better they get. This should not be your only test. It’s too late to make big changes, but it’s the perfect time to refine.
You should also plan to iterate if possible at every point you can. Whichever point you test at, stagger your testing to allow time for adjustments and refinements between passes to weed out more and more noise to get more signal.
So when you say “Prototype”…
The narrower definition of prototypes as “alpha release code” discourages their use for design experimentation and iterative improvement by focusing on a point too late in the project-development process for that level of freedom.
The variety of prototyping methods and media mean that prototyping can be both rapid and inexpensive. That there are no excuses. Make lots of prototypes. Make them early. Test them often.
To sum up
We’ve talked about how much you should test and when. It’s not difficult to understand how much testing you should feel on-the-hook for. Let complexity and novelty be your guide, but don’t let commonality and comfort make you relax your rigor.
Also I’ve given you five points in the project lifecycle to test at. To test iteratively at. Used all together. they will yield a well-honed and well-focused end product, but if you have to choose just one step, test at point three, the Articulated Prototype.
Finally, I’ve told you that a prototype is more things than you may have thought. They vary in form, complexity and labor required. Also, they’re not expensive. So go make some.
Imagine a world where we test design the way we test execution. In the final installment of this four-part series, I’ll talk about UX, QA, and where they can support each other to create a more robust quality process for the creation of anything at all.