1. CCT 333: Imagining the Audience in a Wired World Class 9: Scenarios and Requirements

2. Scenarios A narrative that is accessible and useful to all stakeholders (designers and users) A narrative that outlines complexity to designers A narrative that envelops full complexity of design in context

3. Scenario elements Action and reflection balance Fluidity and concreteness balance Envelops external factors/constrains Allows for understanding of many effects at many levels Can build scientific understanding (grounded theory)

4. User Stories Anecdotes, observation, interview transcripts etc. As close to user’s direct experience as possible - ideally in their own words expressing their own issues Left just at this level - just a collection of interesting stories, no attempt at creating common themes

5. Conceptual scenarios Identification of common themes and problems Builds conceptual models Used for generating ideas for design alternatives, specifying requirements One level of abstraction from user stories - but does not yet address how technologies resolve issues

6. Requirements From user stories and conceptual scenarios, done can build a list of what the technology should (and should not) be or do Functional (e..g., task oriented - what it does) or non-functional (e.g., aesthetic, legal, cultural, ease of use issues)

7. Prioritization (MoSCoW) Must have (without this, it’s useless) Should have (would be a clear value-added requirement but will work without it) Could have (might be nice but not essential) Want but Won’t have (can wait until future iterations) Functional - must have - non-functional, should/could/want to have

8. Concrete scenarios Defines requirements from conceptual scenarios more concretely Builds physical/prototypical models Starts involving technologies and interaction patterns at a general level May be many concrete scenarios from one conceptual scenario

9. Use Cases Formalized interaction patterns All design questions resolved Can be modeled using formal procedures and language (e.g., UML) In software, this is “pseudocode” - in hardware, the first functional iteration

10. Documenting Scenarios Important to collect user stories - and from this, build conceptual scenarios from which concrete scenarios can be derived Documentation of stories through text and other media - the wikis will help there… HIC example in text quite good - scenarios of playing an MP3 on a home information system, with annotations of potential issues

11. Next week Prototypes and evaluation - seeing if you got it right (and what to do if you haven’t…) Identification of scenarios and requirements in projects