What Do You Test, and When Do You Test It?: Why the Hardest Part Is Starting Early Enough
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Wait until next week.
We’ll have a better sketch on a bigger napkin. - —WHAT MY CLIENTS ALWAYS SAY WHEN
I TELL THEM I WANT TO SEE THE DESIGN
THEY’VE SKETCHED ON A NAPKIN
It’s not hard to understand: If you’re going to watch people try using what you’re building, you have to have something for them to use. This means you have to decide what you’re going to be testing each month.
People tend to think that you can’t start testing until you have something that actually works—if not the finished product, then at least a functioning prototype.
But if there’s one thing that usability professionals agree on, it’s that you want to start testing as early as possible.
)
They know from experience that it’s possible to detect serious usability problems very early in the development process, even if you have very little to show.
And they also know that it’s usually far easier and less costly in the long run if you can fix usability problems early, before you’ve started building out the site with the problems embedded in it. Sometimes major problems that are detected too late can’t be corrected at all. The worst practice is the most common one: waiting to test until the site is done and ready to launch.
Unfortunately, professionals also know that people resist the idea of testing early. Some common reasons:
-
“We don’t have enough done yet.” After all, if it doesn’t work, how can people try using it? In fact, it’s never too early to start showing your design ideas to users, beginning with your first rough sketches.
-
“It’s too rough.” Designers are often reluctant to show things that look unfinished. But users may actually feel freer to comment candidly on something that looks rough, since they know it’s still subject to change.
-
“Why waste people’s time looking at something we know we’re going to change?” During the design process, you always have a better version in your head than you’ve committed to code or paper. Yes, users will come across problems that you already know about, but there will also be surprises. In fact, you’re mostly in it for the surprises: the things you didn’t think of, because you’re too close to it or because you don’t understand your users as well as you think you do.
Here’s the best advice I can give you about when to test:
)
Your natural instinct will be to wait, which is the worst thing you can do. There’s an inherent paradox: the worse shape it’s in, the less you want to show it—and the more you can benefit if you do.
Throughout any project your team is going to be producing design artifacts: rough sketches, wireframes, page comps, working prototypes, and more. You can learn from testing all of these things, as well as testing your existing site and other people’s sites.
In the rest of this chapter, I’m going to describe the different kinds of things you can test, how to test them, and what you get out of it.
Testing your existing site
If you already have a site and you’re about to begin redesigning it, the obvious place to start is by testing your existing site.
HOW YOU TEST IT:
Follow the process spelled out in Chapters 5 through 9.
WHAT YOU GET OUT OF IT:
You’ll learn a lot about what you’re currently doing wrong so you’ll know what to avoid as you redesign. You may even want to go ahead and fix some of the worst problems you discover. Your redesign is going to take time, so why make your users suffer until it’s done?
You’ll also learn things you didn’t know about how people actually use your site.