Last week I spent some time shadowing an employee of a potential client, to understand what her work day is like, how she uses the technology she has, how it could be better, and what are some of the limits and constraints of her environment, tools, and patience dealing with it all.
When I called her to set up the appointment, she said, “you know, I’m not sure how much you’re going to get out of watching me. I don’t use the laptop and software on the job. I write everything down and then go back home to use it.” What she didn’t realize is that her description of her situation is actually a gold mine for people like me. The real puzzle is why it’s better to do things twice than do them once with the available tool.
In the day I spent with her, I learned a lot of detail about “real life” in a job like hers. Because realistically, when I set out to design a system for someone whose occupation is very different from mine, involving people very different from me, I can’t do a very good job unless I immerse myself in that world. Design isn’t in the details, it is the details. Those details are the difference between something people like to use, and something they leave at home.
For example, the software program she uses expects information in a linear format. You fill in a section, click next, fill in another, change tabs, and so on. But the delivery of that information, from the customer, isn’t linear at all. Part of this has to do with the fact that the customers are elderly and generally in poor health. They forget things and then “ah-hah!” they come back to them (don’t we all). The software has to be forgiving in instances like this, and right now it’s not. The domain is a fuzzy one. Things don’t always go according to plan. Anticipating these kinds of situations and handling them gracefully is essential in an effective software application.
There’s just no substitute for ethnographic research in an unfamiliar domain. Even in a familiar one, you can always learn something when you view the situation from a different perspective. Before you set out to define requirements, take a stab at understanding context. You’ll be suprised at how much that shapes the entire endeavor.