Cool stuff and UX resources

< Back to newsletters

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?
Toyota Prius

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.

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.

Message from the CEO, Dr. Eric Schaffer — The Pragmatic Ergonomist

Leave a comment here

Reader comments

Paula Thornton

This is a brilliant piece that needs a permanent link to many individuals' list of "important stuff."

In years past, while I've recommended Carroll's book for reference, I wasn't 'happy' with his approach. I still haven't moved past the 'intuitive' nature of this disturbance to identify the issues. I do know that there was still a strong aire of Systems Engineering as a discipline that concerned me. In the experiment we called "Internet speed" we threw out all of the disciplines (admittedly most of the resources were so young they'd never been exposed to the disciplines) and survived quite well. That's not to say that over time some of the disciplines wouldn't have been helpful...but we're talking just a few.

I fundamentally believe there is an economic (continuum/balance of choice) principle at play here that is largely ignored: the longevity/criticality of the effort. If you're building a system to keep airplanes in the sky, lives are at stake. If you're building a system to keep the Federal Monetary system moving, you're keeping financial disasters at bay. I've lived through far too many efforts that lived less than 6 months to a year after they were implemented (or worse, never saw the light of day). Wouldn't those efforts have been better served with less rigorous disciplines? Or, perhaps, if they had been implemented in a more flexible approach, they might not have been shelved in the first place?

Unlike the fields of engineering and architecture, where lives are nearly always at stake, in our field of endeavor, we have to step away from the situation and realize that some projects simply do not command/deserve the rigor that many want to apply to them.

Subscribe

Sign up to get our Newsletter delivered straight to your inbox

Follow us

© 1996-2018 Human Factors International, Inc. All rights reserved | Privacy policy | Terms and conditions for public training courses

Privacy policy

Reviewed: 18 Mar 2014

This Privacy Policy governs the manner in which Human Factors International, Inc., an Iowa corporation (“HFI”) collects, uses, maintains and discloses information collected from users (each, a “User”) of its humanfactors.com website and any derivative or affiliated websites on which this Privacy Policy is posted (collectively, the “Website”). HFI reserves the right, at its discretion, to change, modify, add or remove portions of this Privacy Policy at any time by posting such changes to this page. You understand that you have the affirmative obligation to check this Privacy Policy periodically for changes, and you hereby agree to periodically review this Privacy Policy for such changes. The continued use of the Website following the posting of changes to this Privacy Policy constitutes an acceptance of those changes.

Cookies

HFI may use “cookies” or “web beacons” to track how Users use the Website. A cookie is a piece of software that a web server can store on Users’ PCs and use to identify Users should they visit the Website again. Users may adjust their web browser software if they do not wish to accept cookies. To withdraw your consent after accepting a cookie, delete the cookie from your computer.

Privacy

HFI believes that every User should know how it utilizes the information collected from Users. The Website is not directed at children under 13 years of age, and HFI does not knowingly collect personally identifiable information from children under 13 years of age online. Please note that the Website may contain links to other websites. These linked sites may not be operated or controlled by HFI. HFI is not responsible for the privacy practices of these or any other websites, and you access these websites entirely at your own risk. HFI recommends that you review the privacy practices of any other websites that you choose to visit.

HFI is based, and this website is hosted, in the United States of America. If User is from the European Union or other regions of the world with laws governing data collection and use that may differ from U.S. law and User is registering an account on the Website, visiting the Website, purchasing products or services from HFI or the Website, or otherwise using the Website, please note that any personally identifiable information that User provides to HFI will be transferred to the United States. Any such personally identifiable information provided will be processed and stored in the United States by HFI or a service provider acting on its behalf. By providing your personally identifiable information, User hereby specifically and expressly consents to such transfer and processing and the uses and disclosures set forth herein.

In the course of its business, HFI may perform expert reviews, usability testing, and other consulting work where personal privacy is a concern. HFI believes in the importance of protecting personal information, and may use measures to provide this protection, including, but not limited to, using consent forms for participants or “dummy” test data.

The Information HFI Collects

Users browsing the Website without registering an account or affirmatively providing personally identifiable information to HFI do so anonymously. Otherwise, HFI may collect personally identifiable information from Users in a variety of ways. Personally identifiable information may include, without limitation, (i)contact data (such as a User’s name, mailing and e-mail addresses, and phone number); (ii)demographic data (such as a User’s zip code, age and income); (iii) financial information collected to process purchases made from HFI via the Website or otherwise (such as credit card, debit card or other payment information); (iv) other information requested during the account registration process; and (v) other information requested by our service vendors in order to provide their services. If a User communicates with HFI by e-mail or otherwise, posts messages to any forums, completes online forms, surveys or entries or otherwise interacts with or uses the features on the Website, any information provided in such communications may be collected by HFI. HFI may also collect information about how Users use the Website, for example, by tracking the number of unique views received by the pages of the Website, or the domains and IP addresses from which Users originate. While not all of the information that HFI collects from Users is personally identifiable, it may be associated with personally identifiable information that Users provide HFI through the Website or otherwise. HFI may provide ways that the User can opt out of receiving certain information from HFI. If the User opts out of certain services, User information may still be collected for those services to which the User elects to subscribe. For those elected services, this Privacy Policy will apply.

How HFI Uses Information

HFI may use personally identifiable information collected through the Website for the specific purposes for which the information was collected, to process purchases and sales of products or services offered via the Website if any, to contact Users regarding products and services offered by HFI, its parent, subsidiary and other related companies in order to otherwise to enhance Users’ experience with HFI. HFI may also use information collected through the Website for research regarding the effectiveness of the Website and the business planning, marketing, advertising and sales efforts of HFI. HFI does not sell any User information under any circumstances.

Disclosure of Information

HFI may disclose personally identifiable information collected from Users to its parent, subsidiary and other related companies to use the information for the purposes outlined above, as necessary to provide the services offered by HFI and to provide the Website itself, and for the specific purposes for which the information was collected. HFI may disclose personally identifiable information at the request of law enforcement or governmental agencies or in response to subpoenas, court orders or other legal process, to establish, protect or exercise HFI’s legal or other rights or to defend against a legal claim or as otherwise required or allowed by law. HFI may disclose personally identifiable information in order to protect the rights, property or safety of a User or any other person. HFI may disclose personally identifiable information to investigate or prevent a violation by User of any contractual or other relationship with HFI or the perpetration of any illegal or harmful activity. HFI may also disclose aggregate, anonymous data based on information collected from Users to investors and potential partners. Finally, HFI may disclose or transfer personally identifiable information collected from Users in connection with or in contemplation of a sale of its assets or business or a merger, consolidation or other reorganization of its business.

Personal Information as Provided by User

If a User includes such User’s personally identifiable information as part of the User posting to the Website, such information may be made available to any parties using the Website. HFI does not edit or otherwise remove such information from User information before it is posted on the Website. If a User does not wish to have such User’s personally identifiable information made available in this manner, such User must remove any such information before posting. HFI is not liable for any damages caused or incurred due to personally identifiable information made available in the foregoing manners. For example, a User posts on an HFI-administered forum would be considered Personal Information as provided by User and subject to the terms of this section.

Security of Information

Information about Users that is maintained on HFI’s systems or those of its service providers is protected using industry standard security measures. However, no security measures are perfect or impenetrable, and HFI cannot guarantee that the information submitted to, maintained on or transmitted from its systems will be completely secure. HFI is not responsible for the circumvention of any privacy settings or security measures relating to the Website by any Users or third parties.

Correcting, Updating, Accessing or Removing Personal Information

If a User’s personally identifiable information changes, or if a User no longer desires to receive non-account specific information from HFI, HFI will endeavor to provide a way to correct, update and/or remove that User’s previously-provided personal data. This can be done by emailing a request to HFI at hfi@humanfactors.com. Additionally, you may request access to the personally identifiable information as collected by HFI by sending a request to HFI as set forth above. Please note that in certain circumstances, HFI may not be able to completely remove a User’s information from its systems. For example, HFI may retain a User’s personal information for legitimate business purposes, if it may be necessary to prevent fraud or future abuse, for account recovery purposes, if required by law or as retained in HFI’s data backup systems or cached or archived pages. All retained personally identifiable information will continue to be subject to the terms of the Privacy Policy to which the User has previously agreed.

Contacting HFI

If you have any questions or comments about this Privacy Policy, you may contact HFI via any of the following methods:
Human Factors International, Inc.
PO Box 2020
1680 highway 1, STE 3600
Fairfield IA 52556
hfi@humanfactors.com
(800) 242-4480

Terms and Conditions for Public Training Courses

Reviewed: 18 Mar 2014

Cancellation of Course by HFI

HFI reserves the right to cancel any course up to 14 (fourteen) days prior to the first day of the course. Registrants will be promptly notified and will receive a full refund or be transferred to the equivalent class of their choice within a 12-month period. HFI is not responsible for travel expenses or any costs that may be incurred as a result of cancellations.

Cancellation of Course by Participants (All regions except India)

$100 processing fee if cancelling within two weeks of course start date.

Cancellation / Transfer by Participants (India)

4 Pack + Exam registration: Rs. 10,000 per participant processing fee (to be paid by the participant) if cancelling or transferring the course (4 Pack-CUA/CXA) registration before three weeks from the course start date. No refund or carry forward of the course fees if cancelling or transferring the course registration within three weeks before the course start date.

Cancellation / Transfer by Participants (Online Courses)

$100 processing fee if cancelling within two weeks of course start date. No cancellations or refunds less than two weeks prior to the first course start date.

Individual Modules: Rs. 3,000 per participant ‘per module’ processing fee (to be paid by the participant) if cancelling or transferring the course (any Individual HFI course) registration before three weeks from the course start date. No refund or carry forward of the course fees if cancelling or transferring the course registration within three weeks before the course start date.

Exam: Rs. 3,000 per participant processing fee (to be paid by the participant) if cancelling or transferring the pre agreed CUA/CXA exam date before three weeks from the examination date. No refund or carry forward of the exam fees if requesting/cancelling or transferring the CUA/CXA exam within three weeks before the examination date.

No Recording Permitted

There will be no audio or video recording allowed in class. Students who have any disability that might affect their performance in this class are encouraged to speak with the instructor at the beginning of the class.

Course Materials Copyright

The course and training materials and all other handouts provided by HFI during the course are published, copyrighted works proprietary and owned exclusively by HFI. The course participant does not acquire title nor ownership rights in any of these materials. Further the course participant agrees not to reproduce, modify, and/or convert to electronic format (i.e., softcopy) any of the materials received from or provided by HFI. The materials provided in the class are for the sole use of the class participant. HFI does not provide the materials in electronic format to the participants in public or onsite courses.