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