Lecture+9

// CCT333 – Lecture 9 // // March 9, 2009 //
 * Activity Theory Continued/Scenarios and Requirements **

Labor || __Nodes in Activity Triangle:__ -  Subject – people -  Object – goal, task -  Artefact – tools, technologies -  Community – others affected by activity -  Division of labor – power relations -  Praxis – norms governing activity
 * Artefact ||
 * Subject ||
 * Object ||
 * Praxis ||
 * Community ||
 * Division of

__Contradictions:__ -  Primary – conflict at node (ex. two people, different notions) -  Secondary – conflict between nodes (ex. power relations frustrating action) -  Tertiary – conflicts when activities are redesigned (ex. new process conflicts with models used in old) -  Quarternary – conflicts between simultaneous activities (ex. one activity diagram contradicts another) __ Limitations of HTA: __ -  Difficult to analyze as whole – there’s no ‘right’ way to attend a conference -  Specific elements can be analyzed though – ex. conference registration and payment -  Nested series of tasks possible – in software design, essential – but conflict and error handling becomes an issue __ Limitations of Activity Theory: __ -  Hard to map connections –many iterative loops -  Terminology and theory can be dense – hard to describe, hard to engage others in use

__Scenarios:__ -  A narrative that is accessible and useful to all stakeholders -  A narrative that outlines complexity to designers in context -  A narrative that is shaped both by designers and users – and increasingly shaped by users -  Talk to people first and find out what they want before the final solution __ Scenario Elements: __ -  Allows for understanding of many effects at many levels -  Allows you to set the tone of redesign and sell it effectively to bosses, users, etc.  -   Highlights actions and potential -  Envelops external factors/constrains

__User Stories:__ -  Anecdotes, observation, interview transcripts can directly yield information for scenarios -  Should be as close to user’s direct experience as possible – 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 problems – give a narrative that is convincing -  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

__Concrete Scenarios:__ -  Defines requirements from conceptual scenarios more concretely -  Operates on 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 (ex. HTA, UML) -  In software, this ‘pseudocode’ – in hardware, the first functional iteration

__Requirements:__ -  From user stories and conceptual scenarios, build a list of what the technology should (and should not) be able to do  -   Functional (ex. task oriented – what it does) or non-functional (ex. 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 (cam wait for until future iterations) -  Prioritizing is important – you can’t often do it all, and it’s often a bad idea even if you could

For Final Projects: -  Tell stories based on user data collected -  Build conceptual scenarios from which more specific concrete and use case stories can be derived -  Stories should be of technology as it exists now – don’t tell stories of redesigned technology (in other words, it’s not a marketing gimmick) -  One per person in group minimum – should be a broad enough collection of stories to envelop complexity of potential uses and failures -  Short and to the point – no filler