Users Don't Know What They Want

Years ago, I was called in to redesign the user interface for a very large system that a very large multinational company was building for a very large government agency in a very large state. Yeah, that's a lot of very large in one sentence, but I'm trying to give you an idea of scale. The company had developers in four states working on the project. They had some of the best and brightest architects working on the project, some relocated just to be able to work on the project. And the overall manager for the project was a stellar up-and-coming executive.

Yet, on this entire project, they had not one user interface designer. Not a single person with actual user experience expertise. The closest thing they had was a tester who, to his credit, had identified a number of the flaws. But, the flaws didn't really matter much. They were picky details on an interface that was fundamentally flawed -- because they had committed the cardinal sin of exposing their schema. The system they had built had an interface which was barely better than a raw database viewer. Every complexity and oddity of the underlying schema (usually necessary for good data design reasons) were plopped down right in front of the users. The client (the state) was very unhappy and on the verge of canceling the project.

Someone on the project had worked with me in the past and he suggested that they call me in to help out. Of course, I was stunned to learn everything I described above. But the real stunner came later.

You see, in addition to the hundreds of company employees, there were also four state employees working on the project. The very first thing that I did was to interview one of those people, who had been working on the project every day for two years. And I asked her questions that nobody had ever asked her!

For two years, she had been helping define what the system did. She had been spent thousands of hours answering questions and just as much time working on data relationships. They'd taken this government employee, this subject matter expert who knew nothing about computers, and made her into a schema designer! And nobody had ever asked her about her job.

Instead, they had, in essence, asked her what she wanted. She didn't know what she wanted. But, worse, she didn't know that she didn't know what she wanted. So, she answered their questions with information about the data of her job -- the details of her job. This was certainly useful information, but they could have gotten it from anybody. But the true expertise that she and her three state co-workers had not even been tapped.

In contextual inquiry, you are supposed to observe users in their "natural environment." It's sort of like going to a zoo and watching the animals. But your observation changes things and you frequently don't learn what you want to. Beyond that, you will miss things, even if you're lucky enough that the time you observe is a representative sample. And, for a typical product, there are many different target users and observing all of them is an arduous task. I think that contextual inquiry works best when you already have a product and are trying to improve it.

Fortunately, most people know a lot about not only their own work but the work of their co-workers. In the case of the state worker I interviewed, she had a pretty good idea of what everybody did, from top to bottom. The trick was in asking her about her work and the work of the agency, not her data, and certainly not how she thought the software should function.