As we saw in the last post, one reason computerizing healthcare records can be a disaster is that the people designing the software don’t pay attention to how people will actually use it.
Some software designers argue that the way to avoid this mistake is to use “user-centered design.” Don’t assume that nurses in a hectic hospital see the world the same way software geeks in quiet cubicles do. Instead, go talk to nurses, doctors, administrative assistants, and everybody else who’se going to use the system. Watch how they work. Use what you learn to create a clear picture in your head of the different kinds of users who’re going to use the system — what matters to them, what assumptions they make. Then create “user scenarios” that explain how each type of user would expect to use the software to do their job.
It’s the same idea as in industrial design. Here’s what Toyota did when they wanted to build the Toyota Tundra:
In August 2002, Obu and his team began visiting different regions of the U.S.; they went to logging camps, horse farms, factories and construction sites to meet with truck owners. By asking them face to face about their needs, Obu and Schrage sought to understand preferences for towing capacity and power; by silently observing them at work, they learned things about the ideal placement of the gear shifter, for instance, or that the door handle and radio knobs should be extra large, because pickup owners often wear work gloves all day. When the team discerned that the pickup has now evolved into a kind of mobile office for many contractors, the engineers sought to create a space for a laptop and hanging files next to the driver.
But they couldn’t just pay attention to users’ needs. They also need to understand the needs of the folks who have to figure out how to build the truck.
Design engineers, however, cannot simply create the best truck they can; they need to create the best truck that can be built in a big factory. In other words, Tundra’s design engineers had to confer with Tundra’s manufacturing engineers at every step of the way to create a truck — or 31 trucks, really — that could be assembled efficiently and systematically.
Once in a while, policy geeks pay the same kind of attention to how folks actually work. But just as often they act like the software geeks who build brain-dead healthcare systems that cause as many problems as they fix.
A few years ago I heard a health care expert cheerfully explain how to create financial incentives to keep people from going to doctors unnecessarily. I wondered if he had any clue about what it was like to have a low-wage job and not have any health insurance. The folks I used to treat when I worked in a free health care clinic didn’t need extra financial “incentives” to not visit us. They already had a big financial incentive — they didn’t have sick days, so if they didn’t show up they didn’t get paid and they might get fired. He didn’t know anything about their world — and he didn’t want to, because it would complicate his neat little healthcare model.
The same is true for developers if you’re trying to encourage smart growth. If you don’t understand their world, it’s easy to create rules that’ll make even pro-smart growth developers ask, what did I do to deserve this? And you’ll miss out on opportunities. For example, for developers time is money. So if you can create rules that save developers time — like fast tracking permits that are smart-growth friendly — you can create real financial incentives for smart growth without spending a dime.
If you start from my model’s three assumptions about people, organizations, and markets/politics, this won’t fly. If you want to shape the economy, you need to think more like Toyota Tundra designers and sweat the details of the worlds folk really live in.
We’ve even got an advantage over the Tundra designers. When making a truck, giving customers a say is a good idea. When making a better world, making sure everyone has a say is their right. They own the joint, so they get to have a vote.
I don’t yet have a good name for this approach. For now, I’ll stick with a not-great name – user-center policy design. If you’ve got a better one, help me out and put it in a comment.
