One of the most useful things a team can do is talk to their users about what they are creating. Ideally, this happens before you build anything, and then along the way to validate the designs and implementation. Understanding how the user thinks about the system and how they react to certain designs is crucial to creating a usable solution.
Usability testing comes with a connotation of being a drawn out, complex process that only UX experts can do. Certainly, there is a place for these formal and controlled usability tests. They are important for drawing hard metrics that teams can improve against over time, and for gathering full, unbiased feedback on a system. However, there is also a place for informal usability testing – and in a project where formal usability testing isn’t an option, informal usability testing gives the team a lot of information to use and improve from.
I highly encourage development and product teams to perform their own information usability tests as often as possible. During a project, about half a day a month is a good rule of thumb for how long you should spend on usability tests – and that includes set up, performing the tests, and organizing the feedback. Below I’ve laid out a guide that will help you run these tests.
Who do I test?
Ideally, your target users. In reality, almost anybody. Recruit loosely, and grade on a curve based on how close they are to your target users.
Getting any person that is not woven into the project team to provide you feedback will show you where you started making assumptions and thought people might be able to follow your logic, but they can’t. A large percentage of usability issues are due to layout, wording, or design problems that really have nothing to do with the domain. Almost any user you pick out can help find these problems for you.
Getting your target users is important when you need to test the true workflows and information about the ways that people that use this daily will handle your solution.
For some systems, target users will be more important because domain knowledge is required in order to succeed at the task flows, discussed below. Once again, you can get some non-target users just to catch layout and design problems.
How do I prepare for the test?
Before the test, you want to identify the task flows/scenarios that you will be having the users perform. These should be based on the primary use cases defined for your product. You’re looking to understand if people can find the information they need, and perform the tasks they expect without any problems. Here’s some examples of scenarios for a usability test:
- You are traveling to Seattle for your job next week and you want to check on the amount you can be reimbursed for meals and other expenses.
- You have returned from your trip and you need to scan and add your hotel receipt into a new expense report.
For each scenario you should have an expected outcome or flow that you expect the user to reach so that you know if the user has been able to accomplish the task or find the information if you are not familiar with that part of the product.
How do I run the test?
Once you have your users and your tasks, you can run your test. There are two main of ways to physically run the test:
In person.
Get your users in the hallway, lunchroom, a mall, some other public location, or in a private room/office if you have contacted your users ahead of time. You can show them something on paper, on your laptop, or however you have it designed/built currently.
Remotely.
Get your users onto a Google hangout, WebEx, BlueJeans, or other screen & voice sharing software. Share your screen with them and give them control of the mouse so they can drive the application on your computer. With remote testing, always try out your setup before you start to make sure you have it all working! Volunteering users don’t want to be bothered by your technical challenges.
When you’re performing the test, there are just a few protocols that you want to follow:
- Introduce yourself and tell them what you are doing with them and why. Make sure they know you’re not testing them, your testing your design/software.
- Ensure their privacy and confidentiality. Results should be abstracted from their person.
- Give the user the task/scenario, and then be quiet! When they are trying to perform the task, don’t help them. If they look to you for help, try to turn it into a question. “What would you expect the software to do at this point?” “What would you expect to see here?” If you start answering their questions, you’ll be leading them and giving them more information than a real user of your software would get.
Want to know more?
A great short book (and I mean short!) that covers informal usability testing is “Rocket surgery made easy” by Steve Krug. I highly recommend a quick read-through of this if you want to get more serious about including usability feedback into your product development process.