 4:05:29 PM Feature Article: Know Thy User
David S. Platt
In this issue, I want to depart a little from my practice of writing hard-code programming articles and do a little ranting about eh absolutely TERRIBLE user interfaces I've been seeing lately. Is it only me, or have they gotten worse, by an order of magnitude? With .NET, programmers have all kinds of tools with which to write user interfaces, on the Web or with rich clients on the desktop. And most of them SCREW IT UP ROYALLY!! The UIs are cumbersome. They're cryptic. They require a user to think like a computer, not the other way around. They're just plain stupid.
How do they get this way? Programmers have to have a certain level of intelligence in order to program, and most of them are at least somewhat smart when dealing with code. How can they be such lobotomized morons when designing a user interface? One simple reason: they don't know their users. And it never occurs to them that they don't know their users. Every programmer thinks he knows exactly what users want. After all, he uses a computer all day, he OUGHT to know. He says to himself, "If I design a user interface that I like, the users will love it,"
WRONG, TURKEY! You don't know what the users want, because you're not one of them. Your user is not you. Write that down. Engrave it on your heart, along with F = MA (any physics majors in the audience?) and "always cut the cards". Your user is not you. Your user is not you. Unless you are writing programs for the use of burned-out computer geeks, your user is not you. Here is Platt's first, last, and only law of user interface design. Get it right, and you can't screw up too badly. Get it wrong, and your product is guaranteed to bomb:
Know Thy User
For He Is Not Thee
Here's an example. Every time I teach a class at a company (How about yours? Call me at 978-356-6377.), I ask the class how many of the students drive cars with a manual, stick-shift transmission (as I do). I usually get about half the hands. I then ask how many more WOULD drive stick shifts if their wives would let them, or if they came on the minivans (like my next car, probably) that they need to drive because they're turning into old farts, curmudgeons like me. I usually get about half the remaining hands. (Try this test around your company and tell me what results you get.) "Now would you not agree," I ask, "that driving a stick shift takes more work than an automatic to learn and to use, but gives somewhat better performance, flexibility, and efficiency ?" They know they're being led somewhere they don't want to go, but they can't usually wriggle out at this point, so they agree suspiciously. "Now, what percentage of cars do you think are sold with stick shifts in the US?" They wriggle uncomfortably and say something like, "I bet it's low. Thirty percent?" You wish. Sales estimates vary, but automotive correspondent Tom Whitehurst, says roughly 10% at this link here, and Edmunds comes in with 13.5 percent at this link here. Let's call it 12.5 percent, or 1 out of 8, for the purpose of comparison.
This means that 6 out of 8 programmer geeks value a slight increase in performance and flexibility so highly that when they spend $25,000 or more on Motor City iron, they're willing to do more work (they'll say not much more) continuously over the life of the product to get it. But only 1 out of 8 of the general population makes the same decision when confronted with the same choice. And it's actually even lower than that, because all 6 of those geeks are in that 1 out of 8. The percentage of normal people willing to tolerate the extra effort is probably half that, maybe one out of 15. You value power and performance and configurability. Your user values ease of use, by a factor of 10 to 1 or more. Your user is not you.
For another example, I keep putting these pictures of my daughter into this newsletter (see her with a baby puffin in Iceland at the bottom of this page). Why am I laboring under the misconception that you actually enjoy looking at them? Because I enjoy looking at them, so I know what you would enjoy them as well (What the hell do you mean, you don't? You'll have to agree that she's far better looking than me. And will probably be smarter, too [don't touch that line]. Let me tell you about the cool stuff she just did ...) And because it's my newsletter, so if you don't like it, tough. That attitude doesn't usually translate into sales of commercial products, though. If this newsletter didn't carry content of such scintillating brilliance, you wouldn't put up with that nonsense. And the fact that it's free doesn't hurt either.
So who is your user? That's the first question in any work of communication. And the second and the third. And arguably the fourth, fifth, and sixth. I've met enough of you and taught enough of you that I think I have a handle on who you are, in the aggregate, anyway. But again, it's not enough to actually THINK you know who your users are. You have to KNOW, and that's much harder to do than you think it is. Finding real users is harder than you think. Letting a marketing guy represent them, as often happens, is like playing Russian Roulette with an automatic: quick suicide. Find some real ones. A client of mine, a Canadian company who will probably recognize themselves, is designing a major Web application without talking to any real users. I told them that they are committing malpractice. I haven't heard anything about changes.
Once you've found real users, interviewing them isn't enough. Sure, ask them what they want, ask them about their background, ask them where they're coming from and where they're trying to get to. But this gets you only so far. They often don't know exactly what they want. Or they'll politely tell you what they think you want to hear (this problem is particularly bad in Canada), guided by clues in your questions. You'll say, "Wouldn't it be cool if [some UI feature you like]?", and what can they say? Especially because if they do say, "No, that would suck, and you're an idiot" the interviewer often starts arguing: "but haven't you always wanted to ..." The act of observation changes the result. A physicist would call it "getting Heisenberged", after the author of the famous Uncertainty Principal.
And once you're finished with your user design, you need to test it on real users. You'd never ship a product without testing its internal algorithms (OK, you SHOULDN'T), so why would you think that you can get away without testing a user interface? A computer that your users can't figure out how to use is a very expensive paperweight. You could give them the application to try and ask them afterwards how they liked it. But they often won't be able to remember what they did, or won't want to tell you about problems because they feel stupid that they couldn't figure it out, or won't want to insult you by telling you what a complete pile of crap the product of your last two years of professional life has turned out to be (this is a problem that I do not have.) So you can get some idea by talking to them, but you really have to observe what they do in the act of dealing with your user interface. And you have to do that in a manner that doesn't affect their behavior. This means that you have to put them in front of the application in an isolated room, having access to only whatever support materials (e.g. online documentation) they will have in real life. You have to watch them through one-way glass, videotaping their reactions, and have logging software so you can see exactly which keystrokes and mouse clicks they used to try to deal with your application.
When you do this, the light bulb goes on. As Alan Cooper wrote in his classic book About Face: The Essentials of User Interface Design (IDG Books, 1995): "Programmers fight desperately against the insistence that their creations can't be valid until they are tested by users, and usability professionals seem to have retreated to the empirical as their only way to convince the logical, rational, engineering mind that there is another, better approach to designing the user interface. They drag programmers into dark rooms, where they watch through one-way mirrors as hapless users struggle with their software. At first, the programmers suspect that the test subject has brain damage. Finally, after much painful observation, the programmers are forced to bow to empirical evidence. They admit that their user interface design needs work, and they vow to fix it."
Here's an example of doing it right. I once taught Windows at an insurance company that was writing a Windows terminal emulator application to replace some expensive IBM terminals. Unusually for an insurance company's internal applications, they actually did the usability testing that I just told you about. And they did it well, too, with video tape and one-way glass, programmers watching, the whole thing. They found that the users basically liked the application and found it usable. But the users had the habit of pressing the "Enter" key to move from one input control to the next, as their terminals did, rather than the Tab key as Windows applications do, and had to keep going back to redo things when it didn't work. Couldn't the developers change that, they asked? After hashing it over, the developers decided that, while it was quite easy technically , it wouldn't be a good idea from a user standpoint. Sure, they could make this application work the old way. But all the new Windows applications that the users were going to have to use wouldn't work like that, and the users would soon go schizoid switching back and forth many times per day. So they developers convinced the users to bite the bullet and make the change. And after a period of squawking, the users calmed down, helped by the abysmal job market in that area at that time. My point is not that you should cram down users throats the features you think would be good for them. You usually can't get away with that; this was a special case. I'm relating the story to show you how a client of mine did a good job of usability testing. They did the testing they needed to do. They found what there was to find. And then they made the right decision based on what they found. I wish more companies would do that.
So remember: Your user is not you. They care about ease of use first, and everything else fifth or worse. Observe them as I've told you, and you'll quickly see that. Now go write your programs for your users and not for yourself.
I hope you enjoyed my UI rant. Give me a call if I can help you out. Until next time, as Red Green would say, "Keep your stick on the ice."
Thunderclap, the Newsletter of Rolling Thunder Computing - Volume 5, Number 1 Fall 2002
This newsletter is Copyright © 2001 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices. |
|
"Data! data! data!" he cried impatiently. "I can't make bricks without clay."
