UI Design Newsletter – April, 2004

Insights from Human Factors International

In This Issue:

Tell me the story...
The unifying role of scenarios in conceptual design

The Pragmatic Ergonomist

Dr. Eric Schaffer, Ph.D., CPE, founder and CEO of HFI offers practical advice.

Start at the beginning

You are starting a new interface design project. On one side, you have a set of developers who are waiting for the technical requirements and specifications of the system they need to engineer. On the other, you have subject-matter experts and end users waiting for you to make their world a better place. How can you build a bridge that coherently conveys the context and tasks – the story – of the users to the developers? What strategies or tools can you use to translate from one world to the other?

One approach to bridging this gap is to use scenarios. Scenarios are narrative descriptions of what users do in the course of completing a task. Rather than describing the state of the system, scenarios present the perspective of a user moving through the task space. To be effective, scenarios need to be detailed enough so that designers can infer, and reason about, the implications that the activity flow and interactions have on the interface design (Carol, 1997).

Scenarios add to the set of artifacts found in design (e.g., requirements description, interface prototypes) by describing requirements and processes at the task level. To that end, they anecdotally ground software engineering projects in the users' work. Further, unlike prototyping, scenarios can be created before the system is (Carroll and Rosson, 1992). Therefore, they can be reused throughout the conceptual design lifecycle to guide and iteratively evaluate the completeness of the system requirements and business processes.

Scenarios have gained popularity through their application in the Use Case methodology within object-oriented programming (Jacobson, Booch & Rumbaugh, 1999). However, creating and maintaining scenarios throughout the lifecycle of a design project requires a significant investment of effort. Therefore, to get the most out of their application, we should understand:

• When should scenarios be developed within the conceptual design process?
• How they are used?
• What benefits do they contribute?
• When do they contribute most?
• How do scenarios interact with other design artifacts and processes?

What we know so far...

A few descriptive studies explore the use of scenarios in real-world projects. Weidenhaupt, Pohl, Jarke and Haumer (1998) report a survey of scenarios use across 15 projects of varying size and complexity. They find that the timing of use, form, and contents of scenarios varied greatly from project to project. However, across the projects they observed, scenarios were consistently used to:

• facilitate consistent, shared understanding within the engineering team,
• make abstract models concrete,
• reinforce interdisciplinary discovery and learning.

Because the scenarios increased in number and individually evolved throughout the design process, Weidenhaupt and colleagues note that because scenario management constitutes a major burden, their use was abandoned before system testing in most projects. As a result, the scenarios were not current enough to provide input to derive test cases – a clear loss of potential value. They conclude that scenarios offered critical links among stakeholders in the development process. However, their ultimate effectiveness was undermined by the existing tools and lack of guidance.

Potts and Catledge (1996) conducted a longitudinal case study focused on collaboration and communication patterns and strategies in an industrial software project. They were interested in describing the teams' convergence on a shared vision. In their study, commitment to scenarios use was not a requirement. In fact, scenario use in the project was rare. When scenarios were created, they were used as transitory tools to explore core problems in the design process, but not holistic usage. The scenarios that were created were not named or catalogued for later use.

In their project, engineers focused on describing the functions rather than describing the triggers for functions and their subsequent interactions. This finding is consistent with the infrequent use of scenarios (Hertzum, 2003). Overall, they observe that the project team:

• failed to ground the system architecture in any concrete consideration of user needs,
• returned repeatedly to challenges,
• reached a common vision of the system only after a long and slow negotiation process.

Potts and Catledge (1996) do not offer any discussion as to why scenarios were not adopted in this project.

Hertzum (2003) describes scenario use during the first 12 months of a CASE-based, redesign of a large information system. This study specifically examines the use of four types of design artifacts in the conceptual design process:

1. requirements specifications,
2. scenarios,
3. the business model, and
4. user interface prototypes.

The requirements specification and the business model were required elements of the design methodology. However, the use of both scenarios and interface prototypes was voluntary in this project, since neither design artifact was prescribed by the institutionalized software development methodology.

They found that the design artifacts filled a specific role in the design and documentation process. However, scenarios provided the glue held the various specifications and requirements together. Further, without that glue, the utility of the other design artifacts was undermined.

Scenarios provide a unifying, task-level description

Hertzum reports that the scenarios provided a critical view of the flow and contents of the users work. Their narrative nature established a concrete, common ground that was easy for the engineers to relate to. This finding is consistent with early work of Johnson-Laird and Wason (1977) on the benefits of concrete problem space descriptions to support effective solution generation.

Critically, the scenarios provided an intermediate level of description between the business model (a comprehensive domain description instantiated in CASE as events and elementary processes) and the requirements specifications (a catalogue of sub-task elements of the system processes).

Because scenarios describe the contingencies that trigger when and whether a task is performed, followed by the sequence of steps to completing a task, they preserve the real-world flow and contents of the users often dynamic world. In this sense, they contrast with essential use cases, which describe user intentions and associated system responsibilities, but quickly lose any coherent or holistic view of the users' work.

Hertzum notes two reasons for discontinuing the use of the scenarios in this project. First, project deadlines and pressures of the effort required that the few domain experts who could maintain and evolve the scenarios were reassigned. Second, scenarios-level descriptions are not captured by the CASE methodology tool. Because of the commitment to CASE, focus reoriented toward articulating the business model as the appropriate level of description for the tool.

Anecdotally, the engineers quickly voiced concerns with this approach. Team members pointed out that, even when the constituent events and elementary cases were transferred to the CASE tool, coherence of the system level description was lost. By discontinuing scenario maintenance, a critical evaluation tool was lost.

"Once it [i.e., a scenario] has been entered into [the CASE tool] you can't say 'I want to pull the green thread, which is deaths, and see what happens.' That's not possible. In [the CASE tool] it's not possible to say: What will happen given this situation?" (Hertzum, 2003, p. 10)

Further, since the team was very multidisciplinary, there was a very uneven understanding of the work domain. Discontinuation of the scenarios meant that the common-ground accounts of the users' work would no longer be maintained and the engineers would no longer have a shared context describing their own work in relation to the goals of the larger project. Clearly, the engineers in this project understood the descriptive role and communicative value of scenarios in the conceptual design process.

The benefits of scenarios

It appears that scenarios play a critical unifying role at several levels in the early stages of conceptual design. They bring a level of coherence to system and business requirements by providing a coherent "real world" task-level description of the motivation and events that trigger tasks and the users flow as they navigate to task completion. They also provide a design-neutral bridge between engineers working on different modules of the interface design to maintain a holistic view of the design process. Finally, they provide a common ground for communicating and conveying the minds and needs of the users to the system models that the developers create which is meaningful and accessible to both groups.

In these studies, scenario use tended to drop off later in the conceptual design process. However, it is important to note that that drop off is attributed to extraneous factors and not to a perceived loss of value for scenario use. Exploring projects in which adequate time and appropriate tools are provided to exploit scenarios throughout the design process is needed before we can evaluate their hypothesized value at later points in the design process.

Years ago we would do a "task analysis" that described every step in a system. With more complex and non-modal systems there were soon too many possible flows. So we picked a few flows and called these "scenarios". They were a SAMPLE of taskflows in the system. Today we rarely can do a comprehensive task analysis. We need to use these samples and rely on them to keep us grounded in the user's reality. Because of this need, grounding scenarios are core to user-centered design. We have to design based on how the user will work in the system.

We need to set the right level of detail and formalism. More detail and formalism is not necessarily good! It means more work and more chance of dropping the scenario process. So we want to keep it as simple as possible. Big fancy tools and processes are not necessarily best. The scenario process must first be a perspective. The designers need to think through what the users will really DO. Second it is a foundation for communication. The whole team can look at a given scenario and see the implications. So a blizzard of detailed scenarios is counterproductive. It is about perspective and sharing. Not populating a lengthy shelf.

References

Carroll, J.M. (1997). Scenario-based design. In M. Helander, T.K. Landauer & P. Prabhu, Eds. Handbook of Human-Computer Interaction. Second, Completely Revised Edition, pp. 383-406. Amsterdam: Elsevier.

Caroll, J.M. & Rosson, M.B. (1992). Getting around the task-artifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems, 10, 2, 181-212.

Hertzum, M. (2003). Making Use of Scenarios: A Field Study of Conceptual Design. International Journal of Human-Computer Studies, 58(2), 215-239.

Jacobson, I., Booch, G. & Rumbaugh, J. (1999). The Unified Software Development Process. Reading, MA: Addison-Wesley.

Jarke, M. (1998b). Guest editorial: Interdisciplinary uses of scenarios. Requirements Engineering, 3, 3&4, 153-154.

Johnson-Laird, P.N. & Wason, P. C. (1977). A theoretical analysis of insight into a reasoning task. In P N. Johnson-Laird & P.C. Wason, Eds. Thinking: Readings in Cognitive Science, pp. 143-157. Cambridge: Cambridge University Press.

Potts, C. & Catledge, L. (1996). Collaborative conceptual design: A large software project case study. Computer Supported Cooperative Work (CSCW), 5, 4, 415-445.

Weidenhaupt, K., Pohl, K., Jarke, M. & Haumer, P. (1998). Scenarios in system development: Current practice. IEEE Software, 15, 2, 34-45.

Past Issues