JoAnn Hackos, PhD
CIDM Director

“Harry has just downloaded the latest version of the project-planning software. He opens the program and faces a blank screen with a task bar. Although he spends many minutes clicking menu items, he can’t figure out how to get started developing his project plan. He clicks the HELP menu and finds a list of topics that parallels the menu items on the task bar. Not much help there. What he really wants to do is plan his project but he has no idea of where to start.

He calls his friend Tom, who has the same software. Tom tells him that he needs first to set up his project planning parameters. He needs to decide whether he wants to plan the project on a daily, weekly, or monthly basis and how he wants to account for tasks. Tom explains how he created his first project. Harry decides that Tom has good advice but he doesn’t want to use exactly the same configuration. But he has enough information from Tom to get started and make his own decisions.”

What you’ve been reading is a rudimentary user scenario that illustrates the problem that many of our users face when they find documentation that explains how the product works but not how they want to use it. Instead of real life examples, like the one that Tom offered to Harry, they are faced with lists of menu items and dialog boxes. The procedures tell them how to click things and complete forms on the screen but not how to reach their business goals.

In my minimalism workshop, I urge writers to begin with user scenarios as they design user information. User scenarios are narrative descriptions of users at work on real business problems. These scenarios become the basis for the information architecture upon which to hang tasks, conceptual information, and supporting data. The recommendation to begin with user scenarios springs from the first principle of minimalism—anchor the information in the users’ task domain.

Most writers understand that users are trying to reach their own goals, not become software gurus. Unfortunately, most writers do not know what the goals are. They don’t know enough about the users’ world to ground their instruction in real life situations. As a result, they fall back to describing the product interface and its features and functions, leaving the user without the guidance that will ease their learning and enhance their capabilities with the products.

In the December 2006 issue of the IEEE Transactions on Professional Communication (Vol. 49, No 4), John Carroll, the father of minimalism, and co-author Mary Beth Rosson, describe how user scenarios contribute to learning and support minimalist information design. The article, “Case Studies as Minimalist Information,” explains how Carroll and Rosson use case studies as an instructional method in their usability courses and how they believe that case studies adhere to the fundamental principles of minimalism:

  1. Case studies provide “guidance and encouragement for user action by describing specific activities, events, and problems from real-world practice.”
  2. Cases “anchor the presentation of information in meaningful domain activity by integrating presentation of technical domain knowledge
    [i.e., how to use the software] within a story of professional practice.”
  3. “By describing the misadventures, misjudgments, and outright errors that were part of the story, case studies emphasize the contingency of real practices to novices while also calling attention to … specific errors.”
  4. Cases “support the development of greater autonomy in action by scaffolding the user’s knowledge and capabilities with paradigmatic models of practice.”

Case studies, as described by Carroll and Rosson, are like the user scenarios that we develop as we plan user assistance in documentation. By building the user scenarios into the documentation itself, we can promote the minimalist information design principles and provide users with the real-world context that they require to apply the product to their goals.

Developing user scenario

User scenarios are brief stories that describe real people handling real business problems by applying the specific functions of a product to their needs. Carroll and Rosson describe four basic properties of well-designed user scenarios that we can apply to user assistance:

Typical actors in real-world situations

User scenarios, like the one that begins this article, need real people who have names, personalities, and dilemmas. They need just enough characterization to help the readers identify with them and their problems. They don’t need irrelevant details, which can distract from their usability, but they must be built with sufficient details to be convincing. I particularly like using quotations to make the people in the scenario seem real.

A brief scenario that I once used in a manual reads:

“Cheryl, the owner of The Stained Glass Shop, thought that her best customers came from the older part of the city and were replacing old stained glass. By looking at her customers based on their zip codes, she realized that many of her big spenders were young professionals who had recently purchased houses in the new subdivision. This realization opened up a whole new marketing area for her business.”

Following the scenarios, I explain how to look up customers by zip code and then how to create a mailing list from a selection of customers. The brief scenarios appeared at the beginning of every section of the manual, presenting a typical business case with which the readers were familiar.

Open-ended issues

User scenarios should introduce a typical situation but one that has several possible directions and solutions. In the scenario about Cheryl, readers can easily generalize from Cheryl’s experience to an experience like their own. They may not find their best customers using the zip code lookup, but they may be able to use other look-up scenarios to identify marketing opportunities. They might, for example, look up customers who have purchased a major item in the last year.

The scenarios you create do not have to be comprehensive, just realistic. They can even address complex problems that don’t have one solution but encourage readers to think about their own situations. Our readers are most often immersed in complex scenarios that have multiple possible solutions.

Scenarios that unfold progressively

A few years ago, Autodesk introduced user scenarios to their online help topics to encourage customers to try new features. The scenarios, contained in the New Features Workshop, progressively added more complications through a series of help topic frames.

The first scenario reads:

“You are an architectural renderer doing a presentation drawing of a stadium elevation. You want to use gradient fills to soften the foreground and background colors.”

The second scenario adds another aspect of the design problem:

“Instead of a solid color for the foreground, you want a gradient that goes from dark to light gray.”

The third scenario continues the progress toward understanding how the gradient fill features works:

“Instead of a solid color for the background, you want a gradient that goes from yellow to orange.”

Instructions for completing the tasks follow the simple, brief scenarios.

Scenarios help readers make their own generalizations

Good, comprehensive scenarios enable users to see themselves in the case and bring their own experiences to bear on the archetypical situation.

Here is a scenario I used to describe the problems faced by a Level 1 department according to the Information Process Maturity Model:

“Dr. Q, the leader of our content-management consulting team, has been asked to work with Checko Systems, a huge manufacturing company with a wide range of products. When it was a fledgling start-up, Checko had a central technical publications organization.

Today, however, Checko has some autonomous documentation departments, each associated with a set of products. All that is left of the original central organization is a production unit. Dolores Jones, production head, is interested in developing a content-management system to deliver documents to the company Web site and release them on CD-ROM. She needs the cooperation of all the other departments, some co-located and others distributed around the world at company plants. Some of these documentation departments were once part of the central group; others have had little or no contact with Dolores.”

The situation described has no simple solution or even a single solution for Dolores or the readers who may find themselves faced with the same problems.

Finding the best scenarios

How then do you find the scenarios that you need to situate the readers’ learning in their real-life business goals and problems? You don’t find them by talking to the programmers or engineers. Product developers rarely understand the users’ world. You may have better luck with product managers and marketing professionals who decide on new features to add to the problem. They may know what customers want to accomplish as justification for the new feature in the first place.

The best resources for user scenarios are, however, the users themselves. Discussions with application engineers, sales support, and customer support may give you the first level of insight into what the customers actually do on the job. Focus groups and site visits are even better to help you learn what the users are really trying to accomplish.

In her presentation at the September 2006 Best Practices conference, Cheryl Jenkins and Samantha Robertson of Microsoft’s SharePoint user assistance team, described how their team developed user scenarios for their restructuring of the SharePoint documentation. They rounded up the relevant stakeholders, including members from marketing, the product team, the product planners, early adopters, consultants in the field, and others. They asked everyone to help them describe the customers’ business goals, workplace situations, features required – anything that could help them prepare their scenarios.

They created posters that depicted the user scenarios and reviewed them with the stakeholders. The reviews helped them add details and correct misconceptions.

A small section of one scenario reads this way:

“Contoso, Ltd., is a large organization of 12,000 employees in North America that uses the EPM Solution to gain insight into how resources spend time. Contoso, Ltd., provides consulting services in the area of technical software solutions for health care companies. Although the company identifies 600 of its employees as project managers, those project managers create projects primarily to track time and costs, and only secondarily to gauge progress against specific milestones.

A typical project consists of 5 to 50 tasks to which all project team members are authorized to charge time, but resources are not specifically assigned individual tasks. Project and resource custom fields are used to support different business metrics that enable managers to more effectively analyze how resources are being used across the organization. In a few cases, projects will last several months and will contain hundreds of tasks, but these projects are not common. The company will create about 1,500 projects throughout the year.”

You can find the business scenarios at

Their plan is to restructure their user assistance information to help other customers use the product in ways that parallel or enhance the typical scenarios.

Here is one example of new, scenario-based SharePoint documentation from the Microsoft website:

Coordinate My Sites across your organization

In organizations where multiple server farms are deployed or where multiple SSPs are configured, it is possible for users to create multiple My Sites. For example, in a geographic deployment with a central farm in Europe and a regional farm in Africa, a user can click the My Sites link when browsing content hosted by either farm. Consequently, the user can create a My Site on the Europe farm and a My Site on the Africa farm.

If your organization includes multiple farms or multiple SSPs that host My Sites, you can prevent users from creating multiple My Sites by using the Trusted My Site Host Locations feature. This feature enables you to specify trusted My Site locations. When trusted My Site locations are specified, users are redirected to the My Site that is intended for their user accounts, regardless of where they are browsing when they click the link to create a My Site. This feature ensures that each user creates only one My Site in the organization.

You can further increase usability across multiple My Sites applications by selectingEnable My Site to support global deployments on the My Sites Settings page. However, this option relies on a profile replication solution to share profile data across multiple SSPs in an organization. When these are in place, users can incorporate content or profiles from other SSPs into their My Site:

  • When users add links to their personal site to content that is hosted by other SSPs, trusted SSPs create the link from the context of the user’s SSP, rather than the SSP the user is currently browsing.
  • When users add colleagues, they are added from the context of the colleague’s SSP.

To configure trusted My Site host locations, perform the following steps. [The steps in the procedure follow.]

Benefits of user scenarios

User scenarios are not only great planning devices for organizing and writing user assistance documentation, they provide a minimalist perspective for your content that helps users learn more quickly and reach their business goals. User scenarios are

  • Anchored in the users’ activities. Readers find meaningful information that conforms to their goals and is written in language they can relate to easily.
  • Oriented toward action. Readers are encouraged to understand and take action immediately. The content is designed in recognition that users want to act before they want to learn.
  • Support error recovery. Comprehensive scenarios include what can go wrong by describing typical problems that occur and how the characters in the scenario solved the problems.
  • Helps users work on their own. Customers do not come to our information to learn. They come to gain enough insight to do their own work now and in the future. Scenarios support active learning that customers can translate into future needs and goals.

Carroll and Rosson are continuing their research into case studies and minimalist design. They are seeking ways to present scenarios more effectively and enhance learning. In the same way, I continued to look for ways to use scenarios in user assistance documentation and help systems because I recognize how important the scenarios are to productive learning and customer satisfaction.