personas,-scenarios,-and-use-cases.wiki (4416B)
1 %template math 2 == Personas, Scenarios, and use cases == 3 === Goal directed design === 4 Design activity that links requirements to implementation (what do you need, why? what are you solving?) 5 6 Generally, you have marketers, decision makers, and developers making decisions, and the result is shit. 7 What's missing is the user's perspective: goals, actions, motivations, responses, and the context (how it fits into the user's wider activities) 8 9 Design interactions - mental models 10 The user's mental model is not the implementation model, the user has to adapt to understand the implementation. 11 It's better if design model is good fit for user model (unless it hides important features) 12 13 Steps in design process: 14 * Research users: observation, interview, etc 15 * Discover non-user goals (business, technical, whatever else) 16 * Develop personas 17 * Use personas in scenarios to establish design requirements 18 * Find the functional requirements - use cases 19 20 Users react to a product on 3 levels: 21 * Visceral - the user's _immediate_ reaction before even using the product, should trigger emotional responses that are appropriate 22 * Behavioural - we need design that fits where the user currently is with knowledge, assumptions, and mental models 23 * Reflective - integrating product and its values into wider life, and if done well, you get brand loyalty 24 25 User goals: 26 * Experience: how the user wants to feel (visceral) 27 * End goals: what the user wants to do 28 * Life goals: who the user wants to be 29 30 Non-user goals: 31 * Customer goals (the customer is _not_ the user, like corporate IT buyers) 32 * Business/organisational goals (increasing profit, market share, reducing costs, increase QOS) 33 * Technical goals (maintaining security, cross-platformness, backwards compatibility) 34 35 User stories & goals: 36 * As a <type of user> I want <some goal> so that <some reason> 37 * As a <persona> I want <action> so that <expected outcome> 38 * When <situation> I want to <motivation> so I can <expected outcome> 39 40 === Personas - archetypal users === 41 Modelling users: identify major goals and behaviours, then build models of idealised users ("personas") 42 43 There isn't an 'average user', you use personas that capture important characteristics of users. 44 45 Persona: 46 * Demographic details: name, occupation, age 47 * Personal details: short biographical summary 48 * Attitudinal details: mental model, pain points, feelings about stuff that has to be done 49 * Goals and motivations: for using the product (maybe for life in general™) 50 * Behavioural details: how they act when using the product 51 * generally about half a page in length 52 53 Why? 54 * Coordination, getting a shared vision of the users and market 55 * Communication between devs, designers, marketers, other stakeholders 56 * Determining functionality and behaviour o product 57 * Help design decisions without testing on users 58 * they work. you don't focus on edge cases but on normal use, avoids the self-referential user (developers thinking users are like them), and avoids the elastic user (cuz users won't bend to your will, they don't give a shit) 59 60 === Scenarios === 61 Informal narrative descriptions: 62 * describe human activities in short stories 63 * You can explore needs, requirements, contexts 64 * Don't explicitly mention tech 65 * Are written in the users' language (well, english in our case) 66 * Have varying levels of detail 67 * You focus on the user's perspective 68 69 === Design Requirements & principles === 70 1. Establish needs & goals 71 * what info do users need? 72 * what capabilities? 73 * what goals must be achieved (business, technical)? 74 2. Brainstorm 75 * time-limited, like half an hour 76 * write them _all_ down 77 * no criticism allowed 78 * ideas are culled and refined later 79 80 Don't make the user feel stupid. 81 Define what the product will do before designing how. 82 83 === Use Case === 84 Focus on user-system interaction instead of user's task itself. 85 Describe processes as text or use case diagram 86 87 structure: 88 * users are actors - user types or categories 89 * use case consists of: 90 * header: 91 * name of use case 92 * goal of use case 93 * scope and level use case is covering 94 * preconditions 95 * success/failure conditions 96 * trigger that starts use case 97 * notes on performance, frequency, etc. 98 * steps (each assumed to be successful): 99 * description narrative 100 * variations 101 * notes 102 * exceptions 103 * notation is per step