View source for Scenario-based usability engineering

{{Stub}}

== Definition ==

Scenario-based Usability Engineering (SUNA) is a [[design methodology]].

An example use case in educational technology is the [[e-framework]]
for which Chris Fowler made a [http://www.jisc.ac.uk/media/documents/programmes/eframework/scenario_based_design_chris_fowler.ppt presentation].
This methodology also would be quite useful to engineer [[IMS Learning Design]]s.

Scenario-based design elaborates a traditional theme in human
factors and ergonomics, namely, the principle that human charac-
teristics and needs should be pivotal considerations in the design
of tools and artifacts. In scenario-based design, descriptions of
usage situations become more than just orienting examples and
background data, they become first-class design objects.
Scenario-based design takes literally the adage that a tool is what
people can do with it - the consequences it has for them and for their activities that use it (Beth and Carroll, 2002).

According to Lewis and Rieman (1993:20), a {{quotation | scenario spells out what a user would have to
do and what he or she would see step-by-step in performing a task using a
given system. The key distinction between a scenario and a task is that a
scenario is design-specific, in that it shows how a task would be performed
if you adopt a particular design, while the task itself is design-independent:
it's something the user wants to do regardless of what design is chosen.
Developing the scenarios forced us to get specific about our design, and
it forced us to consider how the various features of the system would work
together to accomplish real work. }}

== User needs analysis ==

Here is a summary of scenario-based User Needs Analysis (SUNA). SUNA can be quite complex or quite simple. It can be very [[used-centered design|much]] or [[instructional systems design|less]] user-centered (if [[User:Daniel K. Schneider|Daniel K. Schneider]] understands right). At a simple level SUNA can be best understood as a combination of People, Place, and Processes. (Gardner et al. :3)

=== Scoping and writing key scenarios ===

Firstly, identify prospective stakeholders (learners, teachers, etc.). 

Then, the most important step in needs analysis is to elicit/create scenarios. This step should be undertaken in a workshop in which everyone participates. A scenario:
* must be a narrative (story)
* should have a precise scope (like a real story) and a time-frame
* should describe:
** actors
** activities (tasks). What they do.
** things (objects) used

In addition, there should be a purpose to the story for the design process, e.g.
* communication
* analysis/design
* decision-making

Therefore a scenario can describe:
* a current "as is" situation (what people do, see above). This will help problem analysis
* a future proposed situation and also "what happens if" situations. This will help to build representations, i.e. a paper-based prototye of a design.

=== Scenario validation and refinement ===

Designers then can work on the scenarios, which are then shown and discussed with potential users.
In other words, these narratives are constructed in an iterative process:

[[image: user-needs-analysis-fowler.png|frame|none|Scenario-based User Needs Analysis. Origin: PPT slides Chris Fowler, University of Essex]]

=== Eliciting the needs ===

Once there are scenarios, a hierarchical task analysis (HTA) can be done. I.e. Task Goals can be analysed in terms of subtasks, i.e. scenarios in terms of smaller use cases.

In any case, each scenario is analysed and expressed needs (extracted textual descriptions) are
recorded in a Needs Table, that can be hierachized or not 

=== Use case description with technology mapping ===

* For each user need a technology must be identified. E.g. if the user express a need "Ability to submit work to Tutor for assessment", we may suggest use of an [[LMS]]

* Next,a designer constructs use cases, {{quotation | a concrete description of activity that the user engages in when performing a specific task, description sufficiently detailed so that design implications can be inferred and reasoned about (Carroll 1995).}} It starts with a ''functional need'' (e.g. deposit an exercise) but then describes the exact ''how'' (go to module X of course, click on "exercises"; select "upload homework"; ...) 

* Finally, one should define problem scenarios, i.e. identify ''claims'' and ''trade-offs'' that may arrise and may impact usability". E.g. if there is "send mail" button, teachers can become overloaded with mail and/or must respond to several identical requests.

=== Build it ===

* An redo according to your favorite design philosophy, e.g. a kind of [[user-centered design]] or something that is more oriented towards [[Instructional systems design]] (ISD).

; Summary of the process

[[image: scenario-based-usability-engineering.jpg|frame|none|Scenario-based Usability Engineering. Origin: PPT slides Chris Fowler, University of Essex]]

== Links ==

* [http://www.jisc.ac.uk/whatwedo/programmes/programme_eframework/eframework_modelling_workshop/synopsis_scenario.aspx Scenario-based design] page at JISC by Chris Fowler. Includes a pointer to Fowler Chris, Scenario-based design, [http://www.jisc.ac.uk/media/documents/programmes/eframework/scenario_based_design_chris_fowler.ppt PPT slides], Chimera: Institute of Social and Technical Change, University of Essex. The initial version of this entry is based on these.

== References ==

* Fowler, C.J.H, van Helvert, J; Gardner, M.G, and Scott, J.R. (in press). The use of scenarios in designing and delivering learning systems. In H. Beetham & R. Sharpe, Rethinking Pedagogy in a Digital Age: Designing and delivering e-learning. London: Routledge.

* Carroll, J.M (1995) Introduction: The Scenario Perspective on System Development. In J.M. Carroll (ed.) Scenario-Based Design: Envisioning work and Technology in System Development  New York: Wiley

* Gardner, Michael; Fowler, Chris and John Scott, Scenario-based User Needs Analysis, [http://www.essex.ac.uk/www.essex.ac.uk/chimera/content/pubs/wps/CWP-2003-02-SUNA.pdf PDF]

* Hutt, A.T.H., Donnelly, N., Macaulay, L.A., Fowler, C.J.H., & Twigger, D. (1988) Describing a product opportunity : A method for understanding the users' environment. In D. Diaper & R. Winder (eds). People & Computers III. Cambridge: CUP.

* Lewis, Clayton and John Rieman (1993) Task-Centered User Interface Design, A Practical Introduction, on-line book (shareware). [ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book/ PDF]

* Rosson, M.B. and Carroll, J.M. (2002) Usability Engineering: Scenario-based Development of Human-Computer Interaction. London: Academic Press.

* Rosson, Mary Beth and John M. Carroll (2002), ''Scenario-based usability engineering'', Proceedings of the conference on Designing interactive systems: processes, practices, methods, and techniques. [http://doi.acm.org/10.1145/778712.778776 http://doi.acm.org/10.1145/778712.778776 (PDF)]
  	
* Rosson, M. B., Carrol, J. M., and Rodi, C. 2004a. Case studies for teaching usability engineering. In Proceedings of the 35th SIGCSE Technical Symposium on Computer Science Education (Norfolk, VA, March 3-7, 2004). ACM Press, New York, 36-40.

* Rosson, M. B., Carrol, J. M., and Rodi, C. 2004b. Teaching computer scientists to make use. In Putting Scenarios Into Practice: The State of the Art in Scenarios and Use Cases. I. F. Alexander and N. Maiden (eds.). John Wiley, New York.

* Carroll, John M. and Mary Beth Rosson, ''A Case Library for Teaching Usability Engineering: Design Rationale, Development, and Classroom Experience'', ACM Journal on Educational Resources in Computing, Vol. 5, No. 1, March 2005. [http://faculty.ist.psu.edu/rosson/Papers/JERIC2005.pdf PDF]

* Van Helvert, J. and Fowler, C. (2004) 'Scenarios for Innovation (SUNA)', in Alexander and N. Maiden (eds.) Scenarios and Use Cases Stories through the System Life-Cycle. London: Wiley. 

[[Category: Design methodologies]]