Difference between revisions of "Projects/Usability/HIG/Scenario"
Line 5: | Line 5: | ||
== Guidelines == | == Guidelines == | ||
− | * Always create scenarios based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for | + | * Always create scenarios based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data. |
− | assistance with the collection of empirical data. | ||
* Take technical configuration, environmental condition, organizational and social aspects into consideration. | * Take technical configuration, environmental condition, organizational and social aspects into consideration. | ||
* If available, use real world images to support imagination. | * If available, use real world images to support imagination. |
Revision as of 16:42, 2 February 2014
Purpose
A scenario describes the whys and wherefores a persona makes use of the application. It illustrates how the users achieve their goals by means of a task-orientated example. In contrast to use cases known from requirements engineering a scenario is more descriptive. It is supplementary to a persona, providing together an efficient method applicable in a wide range of applications.
Guidelines
- Always create scenarios based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data.
- Take technical configuration, environmental condition, organizational and social aspects into consideration.
- If available, use real world images to support imagination.
- Try to include problem situations that will test the system concept, not just straightforward scenarios.
Best Practice
This page was last edited on 2 February 2014, at 16:42. Content is available under Creative Commons License SA 4.0 unless otherwise noted.