July 2012
Volume 27 Number 07
Don't Get Me Started - The Patient Knows What's Wrong with Him
By David Platt | July 2012
.jpg)
I hear the same complaint in every UI class I teach: “The users don’t know what they want. How can we build it for them if they won’t tell us?”
This isn’t a new problem. At my first job, my boss handed around a poem entitled “T’was the Nite Before Implementation” (bit.ly/189U65). It ended with the lines:
And the user exclaimed with a snarl and a taunt,
“It’s just what I asked for, but not what I want!”
That was 30 years ago, and I doubt the poem was new then.
Users have valuable information for us. Their satisfaction is our ultimate quality metric. But users don’t know how to design UIs, in the same way that medical patients don’t know how to diagnose their own diseases. They can tell you if something feels good or bad once you ask them. But pulling the correct diagnosis out of the void isn’t their problem. It’s ours, trained professionals that we claim to be.
Think about it. When a patient goes to the doctor, he doesn’t usually say, “I think I have type C fulminating leprosy, Kaminski variation.” No. He says something like, “Ow, my elbow hurts.” It’s the doctor’s job to figure out whether the patient’s elbow hurts because cancer is eating away at his bones, or his wife’s cheating on him and he’s displacing anxiety, or maybe he just banged it on something. It’s a difficult skill to learn, and doctors who can do it well are good doctors.
My father, a retired physician, comes from the old school of medicine, which subscribes to this belief: The information you need to make the diagnosis is in the patient’s head. But the patient doesn’t know which pieces are important, or how to relate one piece to another. It’s the doctor’s job to ask the right questions: “When did your elbow start hurting? Does your other elbow hurt too? Does it hurt when I bend it this way? That way?” Lab tests and imaging might confirm it, but all diagnosis stems from interviewing and examining the patient.
Likewise, it’s our job to ask the right questions, extract the relevant data from our users’ heads and use it to construct a good UX. We need to learn to interview our target users and observe them at work. UX designers who can do that well are good designers.
It’s also important to distinguish between symptom and cause. My father tells the following story about one of the first patients he ever treated. The ink wasn’t even dry on his M.D. diploma as he started his first job at the hospital clinic. (Brand-new doctors were called interns back then, before Bill and Monica gave that term a different meaning.)
A patient came in complaining, “I haven’t had a bowel movement in a week.” “OK,” thought my dad. “Bowel movement. No problem. Four years of medical school; I can handle this.” He prescribed a mild laxative; nothing happened. Tried a stronger one; still nothing. Getting a little frustrated, he tried an enema. Nothing again. An ultrasound was negative, an MRI scan didn’t show anything, and blood work was unremarkable.
Getting desperate, he took the patient up to the operating room and did an exploratory laparotomy; sliced open his abdomen to look around. There was nothing to see—the patient had a completely normal belly. Finally, he did what he should have done in the first place: took a thorough history, during the course of which he asked the patient what he did for a living. The patient said, “I’m a musician.” Finally, the light bulb flashed on. “Ah! Of course!” exclaimed my dad. “Look, here’s 10 bucks. Go buy yourself something to eat.”
So it is with our user population. They have some notion of what hurts: “I worked for three hours, then up came this stupid box saying, ‘Microsoft Word has encountered an error and needs to close,’ and all my work was gone.” It’s not their job to say, “Jeez, I wish some animated character with bushy eyebrows would pop up and say, ‘It looks like you’re about to crash. Don’t you think you ought to save your work?’” It’s our job to figure out what’s really hurting them, so we can make it stop.
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.