Se connecter

Se connecter avec OpenID

CCT 333: Imagining the Audience in a Wired World

CCT 333: Imagining the
Audience in a Wired World
Class 9: Scenarios and Requirements
• A narrative that is accessible and useful
to all stakeholders (designers and
• A narrative that outlines complexity to
• A narrative that envelops full complexity
of design in context
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)
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
Conceptual scenarios
• Identification of common themes and
• 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
• 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)
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
• Functional - must have - non-functional,
should/could/want to have
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
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
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
Next week
• Prototypes and evaluation - seeing if
you got it right (and what to do if you
• Identification of scenarios and
requirements in projects
Без категории
Taille du fichier
265 Кб