Why it matters:
- Systems need to support the work of the customer or end user
- Teams need a design representation to explicitly reveal how well the system supports the customers’ work
- The User Environment Design offers that representation, and serves as the basis for requirements and specifications
In San Jose, California there is a popular tourist attraction called the Winchester Mystery House. It’s a 160-room Victorian mansion that owner Sarah Winchester continued adding to until she died, keeping carpenters and craftspeople busy for 38 years. The mansion is famous because it’s a “crazy quilt.” There are staircases going to nowhere, maze-like hallways, and completed rooms leading into incomplete ones. It’s as though the builders lost their place all the time and kept starting anew.
Sarah kept adding rooms and features with no thought to how she would actually use them, or how they would function together as a whole. At one point she even decided that she was spending too much time on the front of the house, so she boarded up 30 rooms and never used them again. The house does have some creative features, including a shower specially designed so Sarah could wash without getting her hair wet, an elaborate servant call system, a conservatory room designed to save water, and a patented laundry room sink with built-in scrub-board and soap holders.
Why houses and systems are similar
By now you must be wondering what the Winchester Mystery House has to do with product design. Think about it—it’s a structure where:
- Places have no clear purpose
- You cannot move easily from one place to another
- There are some creative features, but many functions were never used
- Much time and effort was spent building things that were eventually abandoned
- It was pieced together over time, but they lost sight of how it would hang together in the end
Let’s face it; a lot of products end up like the Winchester Mystery House.
What’s fun about the Winchester Mystery House and makes it a tourist attraction is that Sarah Winchester completely ignored the fundamental principles of good house design. (Sarah was driven not by the desire to build a livable home, nor was she listening to an architect. She was following instructions from the spirit world delivered in daily séances).
However, if we take the metaphor of a house and its floor plan, follow the principles of good house design, and apply them to system design we’d end up with a product structured to support our customers’ work practice (or life practice for consumer products). That’s what Contextual Design does with the formalism called the User Environment Design, which takes the idea of a floor plan and adapts it for system design.
The User Environment Design
The systems we design need to have the appropriate function and structure to support the natural flow of our customers’ work through the system. Architects draw floor plans to see the structure and flow of a house. Floor plans are devoid of “user interface” issues; a floor plan doesn’t show the electrical wiring or the plumbing. It doesn’t care about the color of the walls or the type of tile or carpet on the floor. We don’t need those details to determine if the room arrangement will support the life activities of the people who will live there.
As designers we need to see the “floor plan” for what we are designing—which is hidden behind user interface drawings, implemented by an object model, and responding to the customer work. This floor plan is not made explicit in the typical design process. Contextual Design makes it explicit in the User Environment Design.
The User Environment Design (UED) shows the floor plan of the system. It shows each part of the system, how it supports the user’s work, exactly what function is available in that part, and how the user gets to and from other parts of the system—without tying the structure to any particular user interface. Just like a house floor plan serves as scaffolding for where the practice of life occurs, the UED’s system design is scaffolding for where the user’s work practice will occur. This representation is devoid of interface issues and it is devoid of implementation issues. It allows us to run through user scenarios to understand the structure, function, and flow needed in our system to support their work.
The UED formalism
The User Environment Design is made up of places called focus areas. A focus area is a place where a coherent work activity takes place. Focus areas are places where you pay attention to a task; you shift to a different focus area when you switch tasks. Each focus area needs to have a coherent purpose. Functions are the work functions required to perform the tasks. You don’t include UI representations of the function (i.e., drag and drop, click, scroll). Links support transitions from activity to activity. Work Objects are worked on in the place.
Here you see a partial and simplified UED for an email system.
When finished, the UED is your basis for creating the requirements and specifications documents.
The UED supports a coherent rollout plan
Using an explicit User Environment Design, you can make sure the structure is right for your customer, plan how to introduce new features in a series of releases, and manage the work of the project across teams. Using a diagram that focuses on keeping the system coherent for the customer counterbalances the other forces that would sacrifice coherence for ease of implementation, delivery, or “pet” features.
Returning to our house metaphor, you can have a floor plan for a big house, even a mansion, but move in before it is finished. The first “release” can be the minimum “rooms” (focus areas) and functions that your family needs just to move in and have their life supported. If you were building a house, you might love the beautiful built-in bookcases you have planned for the den. But, you don’t need to have that den, or the bookcases, to first move in. You can add it later. Having a UED lets you do the same thing. You have a series of product releases, and since you know what the overall floor plan is going to look like your design stays coherent. You don’t add a feature just because someone in your organization loves it (or seemingly got the idea like Sarah did, in a séance); you add it when it’s the right time.
Reverse UEDs for existing systems, specifications, and competitors
Don’t limit the User Environment Design to creating new systems. You can also build a reverse UED to represent a product that already exists. If you have usability problems with an existing system, creating a reverse UED for it can quickly reveal many structural problems. Use the reverse UED as a focus for follow-on contextual inquiries. If you’re extending an existing system, the same sort of diagram will show you what you’re starting with. It will help you keep the system coherent while extending it and be an ally against feature creep. Sketching small, informal User Environment Designs during design meetings visualizes your design discussions and avoids getting in the details of a UI. Address structural problems at this level and you’ll have less to do when you get to the UI.
The User Environment Design is also a good way to analyze competitive systems. It strips away the detail of a UI so you can compare systems at a structural level. How well does your system compare in function? More important, does your competitor match the customers’ work better than you do?
Use a reverse UED to help make sense of the huge spec sitting on your desk. Then show the result to the designers so they can see the structure of their proposal. One company recently made it a requirement that all proposed and existing specifications have a reverse UED done as a quality check. You can create a reverse UED on your own without investing a lot of time. As a first step it has the added benefits of not having to deal with resistance to Contextual Interviews, convincing team members to take on a new methodology, or overcoming other organizational hurdles.
One account of the Winchester Mystery House describes it like this: “You will be impressed by the staggering amount of creativity, energy, and expense poured into each and every detail.” No doubt, but all of this work was for a house that was so unusable that no one could live there after the creator died. That should be a lesson to us all; let’s not build products that our customers can’t live with. If we do that, I’m willing to bet they will not be impressed with the staggering amount of creativity, energy, and expense we poured into it.
Selected Bibliography
Hugh Beyer and Karen Holtzblatt. Contextual Design: Designing Customer-Centered Systems. Morgan Kaufman Publishers Inc. San Francisco, CA. 1998.
Hugh Beyer and Karen Holtzblatt. “Contextual Design” in interactions. January/February 1999.
Betsy Malloy. Part 1: The Winchester Mystery House History. Sarah Winchester’s Mystery House. Available at: http://gocalifornia.about.com/library/weekly/aa091800a.htm
Betsy Malloy. Part 2: The Winchester Mystery House History. Sarah Winchester’s Mystery House. Available at: http://gocalifornia.about.com/library/weekly/aa091800b.htm
Winchester Mystery House website. The Story of the Winchester Mystery House. Available at: http://www.winchestermysteryhouse.com/story.html