Scenario-based usability engineering: Difference between revisions

The educational technology and digital learning wiki
Jump to navigation Jump to search
Line 86: Line 86:


* [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.
* [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.
* [http://www.professays.com/info/technical-essay-writing-help/ Engineer Essay]


== References ==
== References ==

Revision as of 01:22, 7 October 2010

Draft

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 presentation. This methodology also would be quite useful to engineer IMS Learning Designs.

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 “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 much or less user-centered (if 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:

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, “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

Summary of the process
Scenario-based Usability Engineering. Origin: PPT slides Chris Fowler, University of Essex

Links

  • Scenario-based design page at JISC by Chris Fowler. Includes a pointer to Fowler Chris, Scenario-based design, PPT slides, Chimera: Institute of Social and Technical Change, University of Essex. The initial version of this entry is based on these.
  • Engineer Essay

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, 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). 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 (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. 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.