Scenarios and Minimalism

Bill Gearhart, Independent Consultant

Bill Gearhart has recently joined the team of instuctors for the JoAnn Hackos Workshop Series. We are happy to work with you to develop a minimalism workshop for your team.

One of the most frequently asked questions I encounter when teaching the minimalism workshops is how to incorporate scenarios and case studies into a minimalist information set. Information developers who wrestle with this question often have some preconceived ideas that make dealing with scenarios and case studies problematic. In this article, I describe scenarios and cases studies, define and debunk common misperceptions, and provide some guidelines for developing effective scenarios and case studies from a minimalist perspective.

Characteristics of Scenarios and Case Studies

For all of their usefulness in technical communication, scenarios and case studies are perhaps the least well-defined and understood deliverables. Carroll and Rosson define scenarios as narrative describing one or more users interacting with a system in pursuit of one or more task goals.1 Usually these narratives are fictional descriptions of events based on the goals of a typical user. Most definitions of case studies are similar, except they are based on a look back at events that actually happened at a user site, even if names and minor details are changed.

Scenarios and case studies are powerful documents that frequently are requested by customers, field personnel, marketing departments, and sales teams. They often make the request because the subject matter is extremely complex and difficult to explain. A well-crafted example can show how one customer successfully met a goal and draws on the reader’s prior knowledge to adapt a solution that works for them.

Common Misconceptions about Scenarios and Case Studies

Scenarios and case studies fall in the “reading to learn to do” category. As such, they do not provide a specific “one-size-fits-all” solution to the details of each customer’s situation. And, although presented in action-oriented language, the structure of the document is typically a narrative, or sometimes a graphic or series of graphics. These structures can be a stumbling block for writers accustomed to procedural information; they have conditioned themselves to believe action-oriented content must be presented in a step-action format—the classic “reading to do” solution.2

However, relying on the step-action format can lead the writers to produce “scenarios” that are too lightweight and put undue focus on manipulating the tool rather than on applying the tool to the situation and goal. Many also have a misunderstanding that scenarios only teach the rote performance of tasks instead of an intersection of concepts, decisions, and tasks. The goal of a scenario or case study is not to provide step-by-step instruction, but to convey, as Carroll says, “domain concepts authentically by showing how concepts are employed in the context of a practice.”3

The very nature of the instructional material best covered by scenarios and case studies is that the combinations of possible steps and decisions are too great and too complex to boil down into a procedure. Scenarios excel in these applications because they stimulate the readers to make connections to knowledge they already have and, therefore, allow creative solutions to the unique situation at hand.

Another widely held misconception is that scenarios and case studies are not sufficient to serve as the only components of an information set. While this may be true in many instances, there are times when scenarios and case studies are the most important deliverable, and in fact may be the only document that is needed. Those instances are when the

  • basic features and functions of the product or tool are easy to use or already widely adopted and understood
  • user group is experienced and competent in their domain
  • problems to be solved are complex, non-standard, and require analysis and creativity

In this situation, the information development team can use scenarios or case studies to focus on the higher-level information that bridges the gap between the domain and the tool—exactly what the customer needs. Most writers I talk to work scenarios into their documentation set as a supplement to already existing user or reference guides. Others want to add them. Usually they are concerned with the amount of additional work or topics generated. But in the instances I just described, the writers would do well to replace their traditional deliverables with scenarios because minimalism stresses eliminating from the documentation set information that is already known by the user. Alternatively, information developers could use the approach of providing scenarios as the first deliverable in an information set, working to the other more traditional documents as time allows. Such an approach would focus their efforts on the most important deliverable first.

Determining When to Use a Scenario or Case Study Rather than a Procedure

Use procedures when the following applies:

  • You need to teach a discrete set of steps.
  • You do not need to teach concepts and principles for the audience to have success.
  • The information contains relatively few decisions or alternate paths.
  • The information you present has little need to draw on prior knowledge of the user.

Use case studies when the following applies:

  • The audience has a significant amount of experience.
  • You need to teach concepts and principles and how to apply them.
  • The range of possible decisions or procedural branches is greater than 3.

Guidelines for Producing Scenarios and Case Studies

While scenarios used in a minimalist way can be effective for different levels of user, they are most effective when the users are at least advanced beginners or competent performers in their domain. Carroll says the strength of case studies is that “they directly exemplify domain events, activities, and processes.”4

To be effective, scenarios must be based in the domain of the user. For example, a recent project I encountered contained three scenarios for a reporting product used by financial professionals. Each scenario was task-based but focused on a lower-level procedure that centered on how to use the tool. I suggested combining all three scenarios into a single scenario, “Creating a Profit/Loss Analysis,” that would more closely resonate with the domain experience of finance and accounting professionals.

I then suggested creating a narrative that described a fictional sales and marketing department with business needs to measure, report on, and discuss

  • its historical achievement of sales, budget, and profit attainment in the past quarters, with a discussion of what worked and how to improve in the future
  • how it is progressing towards its sales, budget, and inventory targets in the current quarter and for the fiscal year with a discussion of any mid-quarter or mid-year changes that are necessary

Such a narrative makes for a more powerful scenario because it uses the accounting and finance knowledge and business experiences already assimilated and committed to memory by the users. As they read the scenario, they are encouraged to explore. They rely on their experience to adapt the situation they are reading to their own in ways that are unique and that a writer, no matter how experienced, would be hard-pressed to anticipate. The key with such a scenario is to begin with a goal that is meaningful in the domain of the user, for example, creating a profit/loss report for the current quarter.

In many instances writers have difficulty finding meaningful domain goals. An interesting source that I’ve found in the past is the many unstated domain goals contained in procedures. Wherever I’ve examined procedures and found myself asking “Why would you want to do that?” I’ve found a tip-off that there is a domain-based reason that should be the starting point. A rule-of-thumb I give to writers who are writing interface-centric tasks is “the why is the what,” from a domain perspective.

Using a narrative approach allows the writer to present the thought process and decision-making of the fictional team, including their mistakes, errors, and methods of recovery. In this way, users can learn to avoid or minimize errors without ever having to experience them first-hand.

Finally, scenarios and case studies are most effective when they are specific and provide details that allow the users to not only identify with, but to put themselves into the shoes of the characters and situation profiled. Using domain archetypes and personas can help to bring those characters to life effectively.


Scenarios and case studies can support minimalist principles and, for certain audience profiles, can contain enough essential information to be a self-sufficient information set. However, to create effective scenarios, information developers often must set aside their pre-conceived ideas, look deeper at the instructional goals at hand, understand the users and their domain, and connect the concepts, decisions, and tasks of the scenario with the experience and knowledge already possessed by the user.

1 “Scenarios, Objects, and Points-of-View in User Interface Design”, by Mary Beth Rosson and John M. Carroll,
2 “Reading to Learn to Do,” Janice Redish, IEEE Transactions on Professional Communication, Vol. 32, Iss. 4, December 1989.
3,4 “Case Studies as Minimalist Information,” John M. Carroll and Mary Beth Rosson,IEEE Transactions on Professional Communication, Vol. 49, Iss. 4, December 2006.