When making a product more usable, it all comes down to three basic tenets of Human-Centered Design: actively involve users, iterate design solutions, and use an interdisciplinary team.
MAYA teaches a human-centered design workshop and our entire syllabus is designed to insure competence in these three tenets; we believe great design hinges on it. If you’ve been using any well-designed product lately, whether it’s an online auction site or an espresso machine, you can bet that these principles have been used. On the flip side, if you’ve used something that’s so infuriatingly hard to use — like a parking lot pay station — that it makes you swear, it’s likely that someone ignored the users, didn’t iterate or prototype, and asked one person to burp up the whole design.
While human-centered design is an established practice, a laudable goal and a reasonable benchmark, actually practicing these principles on a daily basis has considerable challenges. Certainly, the first layer of human-centered design is straightforward: we care about our customers, design will help us build products that users need, and building “the right thing” will increase revenue. Really doing human-centered design in a deeper way, however, is rife with problems. Working with users is awkward, difficult and confusing; you have to find the right users, make sure you’re getting accurate feedback and figure out what to do with it. Human-centered design uses a different process, a different team and certainly different timing: interdisciplinary teams need to “gel” to be effective, they must be available for the full design process, their iterative approach often conflicts with more traditional development models (“waterfalls” and their parallels).
But I’m not writing this to bellyache about these real problems. I’m writing to bellyache about the ludicrous excuses I’ve heard for not including users in the design process. The naysayers, in each case, agree in principle to the benefit of working with users, but refuse to actually do it. These refusals, dismissals and dissentions take several common forms, all of which are fear & bull.
1. “We can’t! It’s not ready yet!”
It’s impossible to use human-centered design too early in a product lifecycle. Still, we see plenty of clients who want to “put the finishing touches” on the product before working with users to review and revise it. But those supposed “finishing touches” can cost days, weeks, months upfront, on work that may or may not have lasting value.
Human-centered design is useful across the design lifecycle, and there are methods for any-and-all points in between. Have a rough product concept, but nothing to show users? Or, reached an impasse now that half the system is in place? We have ways to work with these “imperfect” situations and still provide accurate user feedback, viable design ideas and an attainable path forward.
We must use human centered design from the outset, when the product is malleable, the revisions are cheap, and the timeline is less constrained. With any project though, now is better than later, to avoid spending development dollars polishing a turd.
2. “Absolutely not! This version is so much better than what we’re selling now, it’ll ruin us!”
Oh, please. If this excuse were true, automakers would never make concept cars. If this were true, people would watch sequels to movies but not the original. If this were true, nobody would buy anything, ever; they’d be perpetually waiting for the next version. Certainly, awareness of future features is a factor in purchasing decisions, but it’s not the only factor. People may purchase a product because they see evidence that a company is continuing to innovate and improve the product. Or, because they would like to buy from a company that values their customers and solicits their input (imagine that!).
In addition, the number of people who are exposed to a product during a user research or usability testing phase are small compared to the true size of the market. I am completely certain that the benefits of collecting feedback as part of the user-centered design process outweigh any risks of exposing features ahead of time.
3. “No way! Our users are too busy, we don’t want to waste their time!”
Another common complaint about involving users in the design process is that they are busy people, that they have better things to do than evaluate half-baked product ideas. Of course their time is valuable! That’s precisely why we’re trying to spend a small amount of time with them (early) to make sure the designs work before they’re saddled with them on a daily basis (later). Imagine that an hour of usability testing saved someone 5 minutes of annoying effort every day once the product has been released. The usability test is worth their time, after only first two weeks of use. If those improvements are multiplied by the size of the user community, it’s clearly worth the effort. Even if my estimation is off by an order of magnitude, it’s still a rapid payback. If you value your users and their time constraints, usability becomes all the more important. It’s completely backwards to say you value someone’s time, then not talk to them or observe them using your product.
4. “Why bother? We have plenty of people in house who know way more about the product!”
This one appears in many forms, where developers, marketing staff or even CEOs claim to be “subject matter expert” or “users of the product,” or viable “stand-in” for the user. Certainly, if they’re doing their jobs, all these people know quite a bit about the product, the user community and their needs. And, working from your existing knowledge base is a great place to start. The best this “research” will give you is a decent first pass – to be followed up with real user research. That user research should be followed up with real, hands-on experience and feedback from the true day-to-day users of your product.
Yes, it’s possible to role-play. Yes, there’s value in eating your own dog food. Just don’t let it get to the point of arrogance, laziness or groupthink. Users will say things you never expected, do things you never anticipated and make you think about your product in new ways. You just have to be willing to get them in the door and let them blow your socks off.
5. “Unless we can prove the new design is better, it’s not worth doing!”
In an ideal world, we’d have perfect information at all times as a source for our design. Yet it’s cost-prohibitive for 99% of projects to collect information with that kind of pedigree: it requires too many users, takes up too much calendar time, and scopes the problem too narrowly. Formal summative assessment has a time and place, but it should be reserved for a time after other, more cost-effective means have been exhausted.
This excuse masks another more insidious issue, that human-centered design methodology is “fluffy” (at worst) and “imprecise” (at best), or that information that isn’t statistically significant can’t inform design. Certainly, much of our practice relies on approximation and interpretation. But that doesn’t mean these formative evaluations should be thrown out the window as irrelevant. They provide quick, cost-effective ways to inform design, mold a product while it is still malleable, and provide a basis for later (more formal) iterations. They’re an indispensable part of the iterative design process.
So if you are actively involving users, early and often in the design process, fantastic! If not, go back and read this rant again, maybe?