Contextual Use Cases: Using Contextual Design to Define Use Cases

Recently I’ve been working with development teams in several organizations that are struggling with questions of Methodology — the Big-M Methodology where people want to write all the steps down in a book and ensure their development teams follow the mandated Methodology.

But those teams also want to be more closely tied to their customers. They know if they can’t work real customer data — the kind of data you collect in Contextual Design — into their process, they’ll never be able to produce the best systems for their users.

How, they want to know, can they reconcile the requirements of their Methodologies with the approach taken by Contextual Design? They want to do the right thing. But when the Methodology doesn’t specify the steps of Contextual Design, what are they to do?

Big-M Methodologies Don’t Address Up-Front Design

If you haven’t been in this situation yourself, you may not appreciate what a quandary this is. Surely any good Methodology will include understanding the users as the first required step?

Well, yes and no. The problem is that these large-scale Methodologies are rarely customer-centered in the sense that Contextual Design is. The first phase is often “needs analysis,” “requirements gathering,” or “requirements analysis.” But what do those activities mean? What techniques should a team use to do the work required by these phases?

The big-M methodologies I encounter when working with our clients tend to be designed for large IT or government systems. They seem to expect that the decisions have already been made about what the system is to do and focus on what happens afterwards. They assume that a preceding phase of “business analysis” has determined what the system should do and now all the development team has to do is pick up from there to define the system.

The trouble is, this basic assumption doesn’t work for most teams I deal with. First, the more systems become integrated with the work of people, the more the job of IT looks more like product development—figuring out how people can take advantage of technology to improve their work practice. This requires an act of invention the traditional methodologies don’t support explicitly. Second, the methodologies tend to be adopted for product development without making the kind of modifications necessary to adapt them to the needs of product development teams. Product developers don’t have that business analysis to depend on. Third, even when the business analysis has been done it’s too high-level to determine the details of what the system should do, how it should look, how the screens should be laid out, and how it should behave. The project team needs a process that guides them through the detailed design.

Use cases are not that process. When you use the development of use cases to drive your discussion of what the system should do and how it should be structured to do it, you mix a conversation about design options, system structure, and UI design with your conversation about the detailed behavior of the system in response to user input. The result is that the use case conversation becomes difficult and contentious—everyone has a different idea about what the system should do, and the conversation about use cases doesn’t provide process support for this design discussion.

Fill the Gap with Contextual Design

Fortunately, the solution is not particularly hard. Most methodologies specify that “requirements gathering” is to happen without specifying techniques for doing it. This gives project teams little guidance, but when you’re trying to fit Contextual Design in that’s an advantage. You just make Contextual Design your technique for gathering requirements. The mapping looks like this:

User needs analysis

This is Contextual Inquiry interviews and interpretation sessions, work model consolidation, and visioning. Your visioning will be scoped by your business analysis if you have one, or by your marketing input if you’re developing a product. Yes, visioning is part of user needs analysis. How else can you decide what to do? Where was the “user need” for an electronic spreadsheet before Dan Bricklin invented the spreadsheet? Most methodology promoters will admit, when cornered, that the design of the system is embodied in the requirements—so design the system, and then write the requirements.

Requirements definition

This is storyboarding and User Environment Design (UED). Your organization may call this “requirements analysis” or “functional analysis”—I’ve seen both. Either way the UED says, in detail, exactly what the user-visible behavior of the system must be without specifying either implementation or user interface details.

Some companies, in an effort to deal with the problem of design more directly, split their use cases into two levels—“high-level” use cases define the overall behavior of the system from an external viewpoint, and “low-level” use cases work out the precise behavior of a particular system interaction. If your Methodology does this, the high-level use cases map directly to CD’s storyboards. You’ll generate the low-level use cases after you have a UED.

Requirements analysis

This is usually where use cases come in. Earlier we asked how you know what to write into a use case — the use case depends on a pre-existing idea of what the system is to do. Now, that’s not a problem — this is defined by the whole Contextual Design process. You now know exactly what your system will do. Writing your use cases is an analysis process — walk through the User Environment Design writing use cases based on each group of function in each focus area. Your use cases will show you what the system must do to enable that user-visible behavior — exactly what you need to start object analysis and implementation design.

This isn’t the final answer to the Methodology wars — you, I’m afraid, will have to work that out to your satisfaction in your own organization. But it illustrates how you can fit the Contextual Design way of doing things into the corporate world you may be a part of. Use the CD techniques to drive the thinking process and to keep you tied to the user data — then you can generate from the CD artifacts the documents you need for your Methodology. Use the documents to keep the watchdogs happy, and control the process to get things done.