What web developers can do about “stupid users”
My article on “stupid users” seems to have stirred quite a bit of debate, with quite a few people seemingly convinced that the users are, in fact, stupid, and there’s nothing that can be done about it. That’s just not the case.
There’s quite a bit that can be done to help “stupid users.”
I’m not going to pretend to offer a comprehensive guide to human-centered design. Much smarter people than I have written books on the subject. I would encourage developers to read them.
What I can do is offer a few tips that often seem to be overlooked.
And crib heavily from some great comments others made (including some who disagreed with what they thought I was saying).
So who are your users, anyway?
The first step to building better web apps — and worth repeating — is to stop thinking in terms of “stupid users”. Build some respect, build some empathy, and try to start seeing things through their eyes. They’re people. Some are stupid, some are smart, most are somewhere in between.
At one end of the curve, the simplest of web sites will confuse some users. This is the portion of your audience that really is, for lack of a better term, “stupid”. At the very least, they’re terminally clueless on the technological front, and there’s only so much you can do to help them.
“At some point you just have to decide you can’t help those who can’t (or won’t) help themselves… Designing for this customer tends to ruin the experience for the others. You just have to take a deep breath, be polite and gently guide them along through e-mails & support calls.” — sstringer
In the middle lie the huddled masses. Skills vary widely, but so long as your site isn’t too complex they’ll probably be OK. Here’s where you can make a lot of gains, and move your application from “usable” to much more. Ninety-percent or more of your audience probably falls in this group.
And at the very high end, the brainiacs. They can figure anything out. If you web app is to complex for them, it’s just too complex.
Listen and learn.
Because of the wildly varying skill and attention levels of your audience, there’s really no substitute for good usability testing. Nothing will humble you, hone you and help you as much or as quickly as having a normal person in front of you attempting to work their way through your site. Lack of time, money or other factors preclude any formalized user testing, but even in those cases find somebody to take a look at it. Keep your mouth (and ego) in check, if you want to really learn anything.
What you’ll probably discover is that most of what you assumed is wrong. You can’t really assume much about your audience. You have to develop based on what they want to do, not what you think they’ll do. As Todd Warfel put it:
“If applications were designed based on the customers’ current behaviors, users wouldn’t be stupid, developers would be smarter and companies would save a great deal of money on training and support.”
Assuming “common sense” is one of the most common errors. Just because something makes perfect sense to your doesn’t mean it will to me. Our brains work differently. That doesn’t mean either one of us is stupid.
“The big thing that I have seen developers (web/application/system) tend to fail to do is research their target audience and how that target audience will interact with the finished product. This is as much a product of their formal training (read-lack of training on audience research) , looming deadlines, and tool mindset as any introversion.” — Dan Charles
Some general rules that may or may not be apply
Now that I’ve warned you off making assumptions, here’s a few you can probably make:
Users, generally speaking, hate reading. The more comprehensive, lengthy and in-your-face you make your help/FAQ/support, the less it’s likely to be read.
Users are lazy, at least as far as your web app goes. They want instant gratification. They’ve got a limited amount of time and attention they’re willing to give you, and they’re going to take what appears to be the path of least resistance.
“I would assume my users were lazy before I’d assume they were stupid. That’s why I build a step by step system for, let’s say, configuring a web backend. I’m not assuming my “users” are stupid, but I do assume they don’t want to spend hours learning what very technical terms or phrases mean, or configuring the software by hand - and if they’re purchasing my product, they shouldn’t have to.” — etscrivner
Encourage this path of least resistance. If you want visitors to search your support forum, then make searching the forums an obvious choice. Obvious to them, not to you. Simple, straightforward, and there before the visitor even realizes they might want it. By default, most bulletin board search functions are anything but simple and straightforward.
There’s a lot you can do as a designer to guide people toward certain paths and away from others. At the same time, remember: your audience won’t always do what you want them to. Which is where perceived affordance comes in.
Do not write merely to be understood. Write so you cannot possibly be misunderstood. — Robert Louis Stevenson
Although Stevenson could have no concept of modern information design, he was hip to one of it’s most important concepts, Affordance. Affordance, particularly perceived affordance, is simply looking at a design (an object) and trying to determing “What is it about this object that makes people want to use it this way?”
Everything you create has a perceived affordance. If you want your visitor to do something, that perceived affordance must be clear.
Your visitors are trying to get something done.
If you’re lucky, they’re just there to read your sparkly prose and bow to your eternal greatness. That makes life pretty easy. But if you suspect your visitors aren’t coming around just to elevate you to God-like status, it’s likely they’re coming around for some other reason. What are they trying to get done? How well does it match what I wanted them to do? How can I help? How can I remove any obstacles? Once again, real usability testing is invaluable when you’re attempting to answer these questions.
“The difference between a good website and a bad website/program/interface is the number of times you need to click on “help.” If I did my job well everything should be intuitive, obvious, and clear at a glance. If I didn’t then you’ll have to read the documentation, check the FAQ, and work out how everything functions.” — Killfile
Online forms offer a great way to guide the users who need it and stay out of the way of users who don’t.
“You need to make sure the end user knows what fields are required, validate that the required fields are present when the form is posted, and return a user friendly error message when those rules are violated… It would be lazy of me to assume that the end user is savvy enough to know what to submit and how to interpret a 500 error if something goes wrong.” — Spacegoat
The wrong way to handle errors on an online form would be to just serve a 500 error, as Spacegoat pointed out. Only slightly better would be taking them to a separate page detailing their error, or popping up a modal alert box. Either way, your visitor can’t see their error as they try to fix it. The better way, as usual, is to build the site in a way that will help them as they need it and stay out of the way when they don’t.
Users aren’t dumb. Designs are.
One of the most basic tenets of usability says that if the user can’t use a design or product, most times the design or product is stupid, not the user. That doesn’t necessarily mean the developer is stupid. In all likelihood, the developer is very smart. But they failed to bridge the gap between themselves and the user.
Poor planning and testing, bad project management, stubborn clients or any number of other reasons can all create this disconnect, but we as developers are ultimately the ones responsible for bridging it. Writing off the “stupid users” doesn’t help anyone, nor does dumbing down the design.
Find the disconnect and create a new connection. Your audience will thank you. Even the stupid ones.
Further Reading:
This article is by no means a comprehensive look at improving usability and creating human-centered designs, and the links below only brush the surface. But it’s a start.
- The Cranky User: User Interfaces — IBM takes a look at Norman’s Design of Everyday Things.
- Defensive Design for the Web — a good primer on thinking about better ways to get (and keep) your visitors on track.
- Apple interface guidelines — Long before the web, Jef Raskin and Apple were thinking about human-centered design.