└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Learn User Experience Testing 2 | Learn how to test your app with real humans 3 | 4 | ## Why? 5 | This is _probably_ the most important/useful skill any "_creative technologist_" 6 | has. πŸ’ͺ 7 | 8 | Well conducted user experience testing helps you ensure at each stage of 9 | development that what you are planning to build is going to solve the problem 10 | for your users that you set out to solve. βœ… 11 | 12 | Done properly, it prevents you from wasting time ⏳/ effort πŸ˜“/ money πŸ’°on 13 | guessing πŸ€”β“what your users want, need or understand by getting them to critique 14 | your product as you go rather than retrospectively. 15 | 16 | Testing usability and following usability guidelines is not something we have to 17 | do to restrict ourselves or because we're told to. Understanding usability is 18 | about ensuring users can use our product effectively πŸ“ˆ πŸ‘ 19 | 20 | ## What? 21 | User experience testing is a means of collecting feedback πŸ—£from users on 22 | whether the UX/UI presented allows them to achieve their desired goal in the 23 | fewest steps. 24 | 25 | It should be performed from the very beginning of a project and throughout in a 26 | cycle of: 27 | - πŸ—£βŒπŸ‘Žgathering feedback on your designs from users -> 28 | - adapting your designs in light of user feedback πŸ€” ✏️ -> 29 | - getting feedback on your amended designs to see if they now meet the users' 30 | needs πŸ—£βœ…πŸ‘ -> 31 | - Once you are satisfied the users needs have been met then you can 32 | begin to build the agreed designs. πŸ— πŸ‘·β€β™€οΈ πŸ‘· 33 | 34 | User experience testing cannot be performed as a 'token gesture' to produce 35 | insightful results. Care must be taken to ensure that guidelines are followed 36 | properly so that the results are not invalidated by ["_**confirmation bias**_"](https://en.wikipedia.org/wiki/Confirmation_bias). 37 | 38 | ## How? 39 | 40 | There are many approaches to user experience testing that you may choose to use 41 | based on your product, stage of product development, budget πŸ’΅, client base πŸ‘₯ etc.: 42 | 43 | The first stage of user testing you may wish to conduct is known as the discovery 44 | phase, for information on this stage see: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works 45 | 46 | To perform usability user testing you may use one/some of the following methods: 47 | 48 | * interviews 49 | * Surveys/ questionnaires 50 | * Usage pattern analysis using "analytics" data. For more on this see: 51 | https://github.com/dwyl/learn-analytics πŸ“Š 52 | * Screen recordings #1 πŸŽ₯πŸ–₯ 53 | * App usage/demo video capture 54 | 55 | Ensure that when you conduct tests you are testing them across devices so that 56 | your data reflects all of your users experiences e.g. mobile πŸ“±, tablet and 57 | desktop πŸ’» . 58 | 59 | ### How to conduct interviews 60 | 1. Create a **script** to run through with your testers πŸ“ƒ 61 | 2. Decide **who** you will interview πŸ‘₯ 62 | 3. Find some**where** appropriate to conduct your interviews 🏒 63 | 4. Decide on a **time/date** to perform your research πŸ“† πŸ• 64 | 5. Decide **who** in the team will **conduct the interviews** πŸ‘©β€πŸ’ΌπŸ‘¨β€πŸ’Ό 65 | 6. Decide **how many** interviews you wish to do 66 | 6. Decide how you will **record the findings** of your interviews. πŸ“πŸ”‰πŸŽ₯ 67 | 68 | **1. Writing a script πŸ–Š** 69 | 70 | A script is a helpful way of ensuring interviews are delivered in a consistent 71 | way (if different team members conduct them) and that the interviewer can feel 72 | relaxed ☺️ because they know what they've got to say. It's important that scripts 73 | aren't read like an autocue πŸ€– as you want the tester to feel relaxed too, so 74 | making them more like a normal conversation is beneficial. However if you are 75 | anxious 😰 about missing something out, one way to deal with this is to tell the 76 | participant 'I'm going to read through this part of the process to make sure I 77 | don't leave anything out'. By telling them what you are doing and why it can 78 | help alleviate worries they may have constructed otherwise, you're telling them 79 | that you're reading it so they benefit from all of the information, not because 80 | this is a formal setting and you're avoiding their eye contact πŸ‘€πŸ˜Š! So make sure 81 | the team familiarises themselves with the script before they start. The script 82 | doesn't need to be followed word for word but team members should bare in mind 83 | that certain word choices are important in order to not influence the testers 84 | responses. Here is a script outline that might be of use for some 85 | projects: https://docs.google.com/forms/d/e/1FAIpQLSfM2Uaje8gpBde-RqU01DlxrGUEsWZrjiy8yTKmYaeJYAZUuw/viewform 86 | 87 | The script came from this 5 min Google tutorial: https://www.youtube.com/watch?v=0YL0xoSmyZI. 88 | Remember though to always tailor your script to what you are testing e.g. you 89 | may not need as many introductory questions as this one depending on what you 90 | are aiming to find out from your testing at this stage. 91 | 92 | These are some of the key points from it and other resources (see list at the 93 | bottom of readme): 94 | 95 | #### Introduction 96 | - Ensure your screen is set to something non-distracting (not a view of the 97 | product) during the introduction to the session e.g. a blank google search page 98 | - Thank the tester for taking part ❀️ 99 | - Explain the context of the research e.g. β€˜We're asking people to try using a 100 | website we're working on to make sure it works as intended...’ 101 | - Explain what they should expect e.g. β€˜in a minute I will show you the 102 | application and I’ll ask you some questions about it, it will take about 10 minutes…’ 103 | - Explain what is expected of them e.g. β€˜as you go through the application I 104 | want you to think aloud, to voice whatever you’re thinking or feeling as you go 105 | through it’ - this β€˜**think aloud**’ method is crucial for getting inside a 106 | user’s head. πŸ’­πŸ€”πŸ’¬ 107 | - Encourage honesty and help them relax by letting them know there are no right 108 | or wrong answers, you are not testing them. ’please be honest, this is a test of 109 | the application not of you’ 110 | - 'If you have any questions as you go through the test feel free to ask them' - 111 | I may not be able to answer them right away since we're interested in how people 112 | do when they don't have someone sitting next to them to help but I'll make sure 113 | to answer them at the end.' 114 | - Inform the tester if you are going to record any of your test (e.g. screen 115 | recording πŸ“Ή or audio recording πŸ”‰) and what the recording will be used for 116 | 'it will only be seen/heard by people working on the site, it will not be used 117 | outside of the project.' 'Recording the test helps me as I don't have to take 118 | as many notes...' πŸ“ 119 | - Ask them if they have any questions after your introduction, before you start 120 | showing them the application. 121 | 122 | #### Initial Questions 123 | - Basic questions about the participant that are easy for them to answer and not 124 | too sensitive. This helps them warm up and also helps you learn a bit more about 125 | them as a user. E.g. what's your occupation? πŸ‘¨β€πŸ³ πŸ‘©β€πŸš€ πŸ•΅οΈ πŸ‘©β€πŸŽ¨ 126 | - You might want to learn more about their habits with technology to gain an 127 | understanding of how technologically competent they are (giving context to their 128 | responses) or whether they're familiar with the device you are testing your 129 | product with them on in that test ie. are they an android or iOS user πŸ“±. 130 | 131 | #### Exploring your wireframes / product πŸ”Ž 132 | - For a homepage exploration you might prompt them with these questions before 133 | showing them the page: 'Look at this page and tell me what you about it...' 134 | 'Whose site do you think it is?' 'What strikes you about it? What you think you 135 | could do here? What you think this site is for?' 136 | - For testing a specific flow or user journey tell them about the task you want 137 | them to try and complete. You can read out the task aloud and give the 138 | participant a written copy for their reference. The task should give the user a 139 | scenario to follow, that might include any relevant background details about 140 | them, why they are on your site, how they came to know about the site and what 141 | they are looking to do on the site. 142 | - Reiterate that you want the participant to think out loud as they go along. πŸ’­πŸ€”πŸ’¬ 143 | 144 | - Ask them about other applications they might use that relate to your product. 145 | Consider carefully whether you do this before or after showing them your own 146 | application. The order in which you do things will prime the tester to have 147 | whatever you have just discussed on their mind, consider whether this is helpful 148 | in the context of your research or not. 149 | - Wrap up and ensure to ask your tester if they’d like to ask you anything. It’s 150 | not only polite but also sometimes reveals subjects that the test failed to 151 | capture. β€˜I think that’s everything, do you have any questions for me?’ 152 | - Be comfortable with silence πŸ˜ΆπŸ‘, when someone is exploring the application 153 | don't fill the awkward silences by telling them what to do next, wait for them 154 | to talk. Responses like 'I'm not sure what to do now, where does this page go?' 155 | are really useful because they show you that your designs are not self explanatory. 156 | - Avoid using leading questions or all yes/no questions. Open ended questions 157 | encourage people to give more detail and depth of analysis. 158 | - Be mindful of the language you use to respond to the tester, if a tester is 159 | talking about whether they like the app or not, saying 'ok' in confirmation 160 | rather than 'good' is more neutral. Saying 'good' would suggest that you are 161 | pleased with their response and may influence them to give other answers they 162 | think you would like to hear. 163 | 164 | **2. Who πŸ‘₯** 165 | 166 | If you have existing users for your product reach out to them and ask if any of 167 | them would like to participate in some research to help improve the product. If 168 | you don't have any existing users yet, aim to test your application on people 169 | who represent your target user group. Even when you do have an existing user 170 | base, testing with people who are new to your product can offer a different 171 | perspective to those who already know it and what it does. If you are struggling 172 | to find participants encouraging people by informing them of how long it takes 173 | to participate (10mins is reasonable) or you can offer something to thank them 174 | for participating e.g. buy them a coffee β˜•οΈ if you are in a coffee shop. Just be 175 | mindful that you don't want what you offer as a thank you to impact what 176 | responses they give. You may get a better response rate for participation from 177 | people who are on their own πŸ‘€. 178 | 179 | **3. Where πŸ—Ί** 180 | 181 | Key for determining where to conduct your interviews are: 182 | - **proximity and comfort** - how relaxed will your interviewee feel where 183 | you're meeting them, is it easy for them to get to, would they feel relaxed in 184 | that environment? is there somewhere comfortable for you to both sit? is it too 185 | noisy? or is what you're discussing potentially sensitive so is the environment 186 | private enough? 187 | - **practicality** - what space do you have available to you for your 188 | time/budget? πŸ•πŸ’°do you have a meeting room that you can use? If not, what about 189 | a public space like a coffee shop β˜•οΈor somewhere relevant to your product e.g. a 190 | leisure centre if your product is a fitness application πŸ‹οΈβ€β™€οΈ. 191 | - **bias** - will the location of your interview influence your interviewees 192 | response in any way? Ie. would a staff member respond differently to a question 193 | about procrastination at work when asked in their open plan office in front of 194 | their colleagues in comparison to if you asked them in a setting outside of 195 | their office? or in a private space? 196 | 197 | **4. When πŸ•₯πŸ•š** 198 | 199 | When is a time that suits you and your interviewees. If you're looking to source 200 | interviewees on the day when is a time that your chosen location is likely to 201 | have plenty of people around e.g. office hours for an office, would people be 202 | happier to talk on their lunch break or are they likely to leave the office 203 | altogether? Does the day of the week or time of year make a difference πŸŒžπŸ‚β„οΈ? 204 | Are there any key events within your company or in the public eye that would be 205 | good to coordinate with to conduct your research πŸŽƒπŸŽ„πŸ’˜? E.g. conducting research 206 | in January to coordinate with '[Dry January](https://en.wikipedia.org/wiki/Dry_January)' 207 | when researching for a product aimed at people interested in low/no alcohol drinks options. 208 | 209 | **5. Who will conduct interviews** 210 | 211 | 1 or 2 people is sufficient (you don't want to make your tester feel 212 | uncomfortable). Everyone involved in your product should go at some point 213 | (developers too!) 214 | 215 | **6. How many interviews** 216 | 217 | Up to **85% of core usability problems** can be found by **observing just 5 218 | people using your application** according to Jakob Nielsen (see 219 | https://www.youtube.com/watch?v=0YL0xoSmyZI and 220 | https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/). The 221 | reason for this is that the core usability problems are easy to spot for 222 | people who are new to your application (and difficult for you to spot as you 223 | are too close to the product to see how real people perceive it for the first 224 | time). The 'magic 5' approach suggests that you find out the most from the 225 | first person you to speak to and then a little less from the next person and 226 | so forth. 227 | 228 | **7. Recording the findings of your interviews πŸ“ and interpreting them πŸ“Šβ“** 229 | 230 | Agree before you conduct your interview who is going to take notes and in what 231 | format or whether you're going to record the session (the screen or audio). 232 | Think about how you will later collate your results to see patterns from them. 233 | Once you have all of your findings discuss them with your team to find trends 234 | and see how you can make improvements based upon them. 235 | 236 | Testing with small sample sizes like 4 or 5 people is worthwhile when often the 237 | alternative is no testing at all. However, you shouldn't rely on statistics from 238 | such small groups. So if 1/4 people take issue with something don't consider it 239 | 25% and therefore something that must be changed. Consider what the issue for 240 | that 1 person was and interpret it with your knowledge to deduce if you should 241 | change the designs based on their response. Remember that small and simple 242 | amends are just as good, if not better than a total redesign. Just because you 243 | have areas to improve on doesn't mean you should start again from scratch. Also 244 | remember it's better to make your existing product work rather than adding new 245 | feature after new feature when the original product isn't working well for users 246 | yet. If you have made changes to the existing product and people are reacting 247 | badly to them remember that aversion to change is normal. Give it a bit of time 248 | to allow users to adjust to the new designs or leave assistance mechanisms to 249 | point people in the right direction to teach them the new way of doing things. 250 | 251 | **Be conscious of bias** - think about how every aspect of your set up 252 | (time/location, interviewee demographic, script etc.) could influence the 253 | responses you gained in conducting your research. Could interviewing loved ones 254 | about your idea expose only the positives of your idea because they don't want 255 | to give you negative feedback for fear of hurting you? 256 | 257 | ### Resources: 258 | * A demo of a 25 minute usability test - Rocket Surgery Made Easy by Steve Krug: 259 | Usability Demo https://youtu.be/QckIzHC99Xc 260 | * Notes from this talk have been integrated into this readme. Talk on usability 261 | not so specifically usability testing. Jakob Nielsen: "Mobile Usability Futures" (Google Talk) 1hr: https://youtu.be/sELOUAmFHjA 262 | --------------------------------------------------------------------------------