Scenario-based usability engineering: Difference between revisions
m (using an external editor) |
|||
(16 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Stub}} | {{Stub}} | ||
== Definition == | == Definition == | ||
{{interaction-design|Overview article}} | |||
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 | Scenario-based design elaborates a traditional theme in human | ||
Line 12: | Line 16: | ||
Scenario-based design takes literally the adage that a tool is what | 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). | 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 [[user-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 (e.g. in education you would choose 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 prototype 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 == | == References == | ||
Line 18: | Line 91: | ||
* 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 | * 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. | * 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, 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. | * 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)] | ||
[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. | * 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]] | [[Category: Design methodologies]] |
Latest revision as of 15:24, 27 April 2011
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 (e.g. in education you would choose 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 prototype 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:
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
- 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
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.
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.