Just the Essentials—Adapting Contextual Design to a Narrowly-Scoped Project

The Design Challenge

It’s a set of techniques, not a set of steps. This is one of the first things you hear when learning about Contextual Design. But it’s hard to see how to put this into practice when the processes and work models of Contextual Design all serve a unique purpose, often not filled by other practices you’ve used before. You feel you must do it all or you won’t be doing a successful Contextual Design project. Then you’re faced with a real-life project, and you quickly find that it’s not always possible, or even appropriate, to use the full set of Contextual Design techniques.

The project where I learned this lesson was for a re-design of a search interface for one of our client’s websites. The company I worked for creates “smart” or “guided” Web searches, which run inside a client’s website. The user is presented several categories to choose from as entry points into the system. They are then presented various questions with sets of answers to choose from, which vary depending upon the entry point chosen, as well as previous answers. This information, along with a query the user may type in, is used to narrow the set of documents returned. For this re-design, we were not going to change the underlying design of the site. Rather, we needed to change the entry points and follow-up questions so they made more sense to the user and would hopefully lead to a more successful search experience.

Using Only the Pieces We Need

Using a small team and a limited number of interviews

Since we’d never collected field data, we started by doing six Contextual Inquiry interviews. Given the narrow focus of the re-design (make this thing better, but don’t invent a new thing), six interviews seemed like a reasonable number to start with, especially since we were introducing field interviewing into a start-up company where every resource was precious. We were working with a small team of three core people (myself-a user experience specialist–and two knowledge engineers from my company who would ultimately be responsible for building the new system), supplemented as necessary with developers and others. Also, while our top priority was to show improvement in the site design, we were given about one month for the entire re-design process, so we needed to turn the data around fairly quickly.

We captured affinity notes and sequence models, as well as some artifacts. We built the affinity, and then walked it and the sequence models for design ideas. We decided not to consolidate the sequence models primarily because we had very few of them (roughly one per interview), and some were rather high-level. Instead, we simply laid the models out to refer to during the visioning and storyboarding.

Designing for function and content

Next, we did some visioning, though it didn’t look like a “typical” Contextual Design visioning session. We followed all the same rules, but again, since we weren’t changing the overall design of the system, the visioning centered on how to make the entry page work for users: what categories should we include, should we include a space for the user to type additional information, how would those two pieces of information (the category plus query) work together to tell the system what to display next. We also brainstormed good starting categories and what kinds of information would be included under each category. And we visioned ways to make the system easier for the novice user (our primary target audience), such as presenting some information with graphics rather than a drop-down list of choices.

We then built storyboards, one for each path through the system, showing what questions and sets of answers would appear on each screen as the user moved through the system. Because the system was so simple on a user experience level-a starting page and then a varying number of subsequent pages with questions, all of which had the same format-we found it unnecessary to create a User Environment Design (UED). The storyboards held the essential information for us at this stage: what the user saw at each point as they worked through the system.

After storyboarding, we had the order in which we wanted to present questions, as well as some idea of what the potential answers should be for each question (for example, the answers to “What kind of Mac are you working on?” would be the various types of Macintosh computers: iMac, G4, PowerBook, and so on). Now we needed to start working on the next level of detail, that is, making sure we had exactly the right categories for our starting page. Our interviews had given us some idea of what the starting categories should be, but given the limited number of interviews, we didn’t feel confident that we had seen the breadth of possible questions types: here was a hole in our data that needed filling.

To make things a bit more complicated, whatever categories we came up with had to map not only to the user’s expectations and language, but also the body of documents we were running the search on. In other words, we didn’t want to create a category for which there were no documents, thereby always resulting in a fruitless search for the user. While we had been working on the Contextual Design piece of this project, the knowledge engineers were also doing preliminary studies of the documents to develop some potential starting categories and subsequent question/answer sets. We needed to bring these two pieces of data together so that the users would be able to successfully navigate the system and the questions would successfully distinguish the data so as to return a viable set of answers.

Testing content categories

To help us get a lot of user input quickly, we ran an in-house user test on possible starting categories. We developed a screener and used a recruiting service to find 20 home users who had either called customer support or used the existing website within the last few months. Each user was asked to bring a list of five specific questions they had looked for answers to recently. During the test, each user was given a set of questions they were asked to match to first one set of starting categories and then another. They were then asked to categorize each of their own questions. At any point, they were able to change, delete, or add new categories to fit the way they thought the questions should be grouped. This technique, while not part of Contextual Design, helped us get more user data to validate and adjust the categories suggested by the knowledge engineer research as well as the contextual interviews we’d done. And of course, the paper prototype interviews would help us validate and adjust the entire system.

Testing with paper prototypes

We did one round of paper prototype interviews with three users, collecting the interpretation notes by front page category. We evaluated these notes and updated the storyboards accordingly, just as one would traditionally update a UED. We did a second round of prototype testing and interpretation, and then updated the storyboards one last time.

Using Visio Diagrams to Communicate with Engineering

We were now ready to communicate our findings to the larger engineering team. To do this, we created Visio diagrams, one for each path through the system. The diagrams gave us an easy way to communicate to the engineers the exact order in which the question/answer sets needed to appear, as well as whatever answers we had that we felt should be included in each set. These example answers, drawn directly from user data, helped the engineers understand the kind of information that each set should contain. They could now approach the task of structuring the documents and building the system with clear, validated user data to help ensure the final system would be understandable to the end user. The engineers no longer had to design in the dark, coding strictly from an analysis of the document set. And users would no longer have to struggle to use a system that used terms, categories, and questions that didn’t make sense to them and the way they thought about their issues.