Contextual Design: Goal and General Approach
Contextual design, of which contextual inquiry is a component, can be best understood by reflecting on IT's role within the overall company. IT is a support role; our main reason for existence is that upper management wants the rest of the company (marketing, sales, operations, whatever) to be as productive as possible, and believes that technology is often a useful approach toward that end. Sometimes it is OK for IT to come up with unsolicited technology, but that is a secondary function; IT's main purpose is to help the rest of the business become more productive by entering into a development partnerships with various business clients.
Who should we involve in the IT-business partnership?
The need for a partnership between IT and "the business" is clear and uncontroversial enough, but let's elaborate just a bit since not all development efforts recognize even this truism. The reason it has to be a partnership is that neither the business side nor the IT side knows the whole story on the app to be developed. Each side has about 55% of the story. The business side knows the business, but has only a shaky knowledge about what technological solutions are plausible or even possible. The IT side knows the technology, but has only a shaky knowledge of the task domain for which it is building the app. (Over time, each side will learn more about the other side, but in general neither will know so much that it can go it alone.)
The controversy comes in when trying to identify the representatives of the business and IT sides. Traditional approaches typically allow managers to serve as proxies for their respective functions (i.e., some set of business managers represents the business, and the IT manager represents the IT team). It is also common for the IT side to be represented by the IT manager plus a couple of senior engineers. It is not common for the business side to be represented by real users (i.e., the managers' direct reports), nor is it common for the IT side to be represented by a large number of IT team members.
The main reason for involving only a few people in the discussion is simply that it reduces the number of lines of communication. And clearly it does do that.
Contextual design means real users, not just their managers
In spite of the foregoing advantage, contextual design rejects this traditional approach to software development, opting instead to involve a sufficiently representative subset of real users (not simply their managers), and opting to involve all members of the IT team. I'll explain the reasons below, and why there is a net benefit even given the increased communication load. But for the moment, the main point is this:
Contextual design is a software development methodology that reduces risk by including business users and IT team members as equal partners in the effort. The IT team seeks to understand the users' work in context, to design an appropriate process/technology solution given that context, and to test the result against the users who will actually use the solution.
According to contextual design, real users (and not simply their managers) must be involved in the development effort from start to finish—they need to be involved in helping the IT team understand the nature of the work to be done, creating and evaluating design ideas, and testing the software when it's done—before the rollout—to make sure that it does what it's supposed to do and that it's easy to understand and use. This kind of deep involvement by the users and the full IT team (rather than only their respective managers) reduces risk in at least two ways: (1) involving sufficiently many real users provides for a more representative picture of the work to be addressed, and (2) involving users and the full IT team puts more people in the position to correct misunderstandings about the business process, and to generate plausible design ideas.
It is important to note that contextual design does not claim that every last business user needs to be involved. It is rather that some business users need to be involved, instead of only their managers. And there need to be enough business users for the IT team to get a good picture of the variation in the ways that the business users do their jobs.
