It makes sense to hold off usability testing until you have “something worth testing”, doesn’t it?
After all, you’re up against tight deadlines and tiny budgets. Your scrappy prototype has blatant usability problems – why not fix them first and squeeze in some usability testing later?
It’s a trap!
Here’s how that goes:
As designs come together, you find your team in debates.
- Will users better understand the navigation if you structure it this way or that way?
- Will they notice this interaction or does it need clearer affordances?
- Will they understand this information the way you intended?
You realise you could answer all these questions with some usability testing. But by now it’s too late to recruit people because you have to decide now.
You carry on, though you start to feel the foundation’s a bit wobbly.
“It’s OK,” you tell yourself. “We can still fit in a round of testing later.”
But before you know it, launch day is upon you.
You hate to cut usability testing, but even if you tested now, you don’t have time or budget left to change anything.
So you launch blind.
Deep down, you don’t feel confident. You suspect there are big usability problems you haven’t spotted. And you realise the problems are going to be 100 times harder and more expensive to fix now than if you’d caught them at the beginning.
This is the story of too many projects.
Use Parkinson’s Law to help your UX research
Waiting until you have something “worth testing” is the second biggest UX research mistake. (The biggest is not doing any UX research. The third biggest is thinking that usability testing is all there is to UX research. But these are matters for another time.)
The mistake of waiting gets made even by well-meaning people who understand the value of UX. I know because I’ve made it.
It happens because of Parkinson’s Law: “Work expands so as to fill the time available for its completion”.
It happens when you forget that you can always keep honing design, copy and functionality forever (with diminishing returns and increasing amounts of polish on your turds.)
So, when I started at Zopa, I decided to take advantage of Parkinson’s Law by simply reducing the time available for the work.
I pre-booked usability testing sessions: once a fortnight for three months.
I invited my team to commit to attending sessions using a Doodle poll. This was inspired by Jared Spool’s article about the one silver bullet that gets teams making better products: customer exposure hours.
At this point, I didn’t know what we’d be testing in each session, or even what projects we’d be working on. I didn’t even have a room booked or any equipment.
But now I was Odysseus tied to the mast of my ship. The sessions were booked and I had to deliver.
What happened when I committed to regular testing?
Committing was scary. It would take up one workday out of ten to run the testing, and at least a couple more days to do the admin and reports from the testing. Would I have time to do all my other work?
Well I found that I actually got more work done in between sessions than I ever had before.
Now I couldn’t dither about what might work. I had to micro-ship: deliver something small but real and then watch humans trying to use it. And if it didn’t work, I knew exactly how to fix it.
This is rapid iterative design. Every fortnight, our designs evolved.
For instance, we decided to make a guide to help customers who were still in the early stages of researching getting a loan. It’s a minefield out there in the loans marketplace, and there are some hidden catches that nobody really tells you about.
We quickly found out nobody tells you: it takes absolutely ages to do the research. So long, in fact, that when the testing session rolled around we didn’t have anything ready to test. So I printed out the rough draft from Word and an ugly comparison table from Excel and thrust those into the users’ paws.
Of course I was tempted to hold off until we had something “worth testing.” But that would have been a mistake. Instead, we immediately learned that our users were more excited about a different angle than we’d anticipated. We were able to quickly pivot the guide into something even more useful.
We’ve tested that guide three more times. Each time it was honed and improved. Each time, it got a better reaction from the users. Now, when we release it, we’ll be confident that it’s the best thing we could have made.
And that’s all down to regular micro-shipping: getting whatever we had in front of a few real humans.
What did I learn about the regular testing? Five Top Tips…
1) Test with whatever you’ve got.
I’ve usability tested with everything from fully-fledged prototypes to handwritten drawings on the backs of envelopes.
I’ve never failed to learn something important and unexpected.
2) If you’ve got nothing to test, test your existing site
Every time I do this, I fear I’ve already seen all the problems and understood all the mental models. But I’m always glad I tested it and I always learn something new. For instance, have you tested your site on desktop, tablet and mobile separately?
3) If you’ve got no existing site, test your competitors’ sites
They have usability problems too. And they’re probably doing some clever things you didn’t spot. Now you can
steal be inspired by them.
4) Do everything you can to persuade your team to be in the room
Reading reports on usability testing delivers a tiny fraction of the value of testing. When your team are in the room, they really feel the users’ pain.
I couldn’t have been happier than when one developer noticed two users struggling with the same form field and took it upon himself to improve it. I didn’t have to drive the project or fight to make the change: I just let him experience the user’s pain for himself.
5) Make it pleasant
Even though not everybody shows up to sessions, I don’t try to enforce attendance because then it could become an unpleasant chore. (However, I do publish a register of how many hours people have racked up!)
I don’t make observers write notes or do any sort of work in the sessions. They just sit and watch. Then we have a quick debrief right after the participant leaves, where they usually get excited about what they noticed and the ideas it sparked.
Here’s your challenge: commit to micro-shipping
This is the most important thing. Make it a habit.
I want you to book people to come in two weeks from today and every fortnight after that for three whole months. Once the usability sessions are booked you’ll have to put something out just in time for each one.
Think of it as an experiment, just to see how it works for your team.
I predict that at first, you’ll find it uncomfortable, time consuming and sometimes irritating. For me, each cycle of testing took three or four days of faff at first, but it’s under two now we’re in the groove.
Then you’ll find that you actually like being forced to micro-ship regularly.
And you’ll start to feel a new, deep sense of confidence in the things you ship to the world.