Note to doctors: No, I don’t really mean that title. I use provocative titles to get attention and capture an attitude. What? What are you doing? You’re going to stick that thermometer where?
Doctors are the stupidest users. If you’ve ever had to write software for doctors, you’ve discovered this: the phrase “RTFM” was made for doctors. They just can’t be bothered to read even the simplest help docs. They can’t bother to learn even simple tools that a bright grade-schooler can master.
OK, that’s the programmer perspective. Now let’s look at it from the doctor’s perspective. On her desk is a small mountain of medical journals she needs to read to keep up with her specialty.
Next to those is a small mountain of textbooks for the new specialty she’s trying to learn.
Next to those is a small mountain of new regulations and guidelines she must comply with to maintain her license.
Next to those is a small mountain of insurance guidelines she’ll probably never have time to read but should if she wants to make sure she’s charging within guidelines.
Next to those is a small mountain of insurance paperwork that demands her scarce attention. She has no time for it; but if she doesn’t keep up with it, patients may be denied treatment that would’ve been approved if she had.
Next to those is a small mountain of accounting statements that she’d rather not bother with, but has to if she wants to pay her student loans and malpractice insurance.
And next to all of those is a large mountain of patient histories, test reports, specialist reports, and hospital reports she needs to keep straight in order to treat her patients.
And somewhere, buried under all of those papers, are a few pictures of the family she hopes to see once or twice this week.
And along comes this programmer person who says, “What’s the deal? This is easy! Just read this, and this, and then try this, and learn this, and look at this, and it’s easy! You’re a doctor. You’re supposed to be smart. This should be easy!”
After she schedules the programmer for an emergency barium enema, the doctor goes back to her work.
This is part of the reason (by no means the entire reason) that there’s a profession of Medical Technician. These people’s responsibility, in part, is to be the doctor’s user interface to programs that the doctor just has no time to master. They have time to specialize in arcane software. They usually have more technical experience.
But really: should it be this way? Not that I want to put Medical Technicians out of work; but shouldn’t the programmers spend more effort understanding the doctors and their needs, rather than requiring the doctors to understand programs and programmers?
For years, I’ve spoken and taught about a principle I call Conservation of Complexity. For any given task, there’s a minimum complexity required for that class. You can’t make it less complex. (But trust me, some idiot can always make it more complex…) If I’m automating that complexity, I take some of that work onto myself, and leave some for the user; but no matter what I do, I can’t reduce the complexity below the minimum. And being lazy by nature, I’ll want to do the minimum necessary to meet the requirements: minimum complexity for me, and let the user do the work.
But we can cheat! We can’t reduce the complexity of one instance of the task; but we can reduce the complexity of multiple instances, especially when those instances are performed by multiple users. In so doing, we can reduce the net complexity in the system.
Let’s say the user and I split the complexity, C: I get 0.5 C, and he gets 0.5 C. Now if 100 users do the task 100 times, we have:
Cnet = 0.5 C + 100 * 100 * 0.5 C = 5000.5 C
Cave = Cnet / n = 5000.5 C / 10000 = 0.50005 C
So we’ve cut the complexity in half. That’s great, right? That’s why we write code, right?
But suppose some idiot — i.e., me — didn’t make that app very usable for the user. Oh, it’s easier than working by hand, or I won’t sell any copies; but say it’s 0.8 C. In that case:
Cave = 0.80005 C
So I took an easy way out. The system is still less complex on the whole. We’re still winning, right?
But now, let’s go the opposite way. Let’s say I put in the extra effort to reduce the user’s work to 0.2 C. And let’s assume this takes me a simply ghastly effort, 2 C. That means that:
Cave = 0.2002 C
By me working twice as hard, the system as a whole works roughly 80% less.
Now these numbers are just examples, of course. But I think they make my point: if all I worry about is getting code out the door, I may not work hard; but my users have to work a lot harder. Too often, we programmers see our perspective too clearly, and the other guy’s perspective too dimly. (In other words, we’re human.) But the smarter thing to do is to put forth the extra effort to reduce the user’s complexity. Because after all, there’s money to be made in reducing your user’s workload!
I’m reading Alan Cooper’s The Inmates are Running the Asylum; and with practically every page, I’m reminded of Conservation of Complexity. And of the doctors.
Also see Joel Spolsky’s discussion on mental models. He approaches the same idea: the programmer has a mental model of how the code works; the user has a mental model of how the code works; and great software results when the programmer’s mental model is very close to the user’s. It’s easier for a team of motivated programmers to change their handful of mental models than to change all those users.