Usability testing (also known as user testing) is one of the foundational methods that we as UX researchers, use to understand how our end users interact with the products and services we are researching. It’s also one of my personal favorites. In my UX career, I’ve written, reviewed, or moderated hundreds, likely more than a thousand, usability tests. With all of that experience, there is one tip that I always share first when teaching someone how to write a usability test or giving advice to improve existing tasks: the structure of Character plus Situation plus Command.
On a very simple level, a character tells the participant who they are, the situation tells them why they are doing something, and the command tells them what to do. I find that having a good structure like this not only makes it easier for me to simply fill in the pieces but also makes my tasks better and easier for participants to understand and follow. So, let's break down each of the pieces.
- Character - The character of a usability task tells the participant who they are in this scenario. One of the simple joys of this part of the structure is that if you have a good understanding of your target user group and have done a good job recruiting folks from that group, your character can be just a single word: “you.” When we know that our participant is part of our target user group, we can simply allow them to play themselves in our little usability testing play and let them fill in the details of character motivation and such from their own lives. It’s almost always easier to play oneself than it is to play someone else. However, sometimes, the interface that we are testing has a name that displays for demo purposes. In those situations, we need to tell the participants that, for the purposes of this study, they are Daniel, Joyce, or whoever is displayed in the interface.
- Situation - The situation in this structure gives the participant all of the necessary details that they will need to know in order to complete our task. These details are information that they would naturally have when completing the task in the real world. This might be things like giving them addresses or phone numbers that need to be entered into a form, telling them details about the client next on their sales call list, or whatever other information is essential to completing the task we set for them. The key to writing a good situation is finding the balance between giving the participant the information that is critical to their decision-making while completing the task – but no more. The “aha moment" for me personally came when I understood and became comfortable with allowing participants to fill in extraneous or tertiary information with their own pre-existing knowledge and experience. That allowed me not only to keep my situation information to a minimum but also gave me insight into how participants are working and thinking in this space today.
- Command - The command of a usability task tells the participant what needs to be done in order for the task to be completed. It is the “do this” of the task. Examples might include “Schedule an oil change” on the mechanic’s website or “Tell me how you would contact customer service” if testing a consumer product. The key to a good command is that it tells the participant what to do, not how to do it. Another mark of a good command is that it tells the participant to do the task in real-world language rather than in the language the product or system uses, like a button or menu title. Another “aha moment” for many UX researchers is remembering that the product or service that we’re researching is a means to get things done in the real world, not the end in and of itself.
Let’s tie it all together with an example that calls out each piece of this structure.
You are paying some bills and want to see if you have enough money in your account to pay them all or if you need to pay some in a few days after you get your paycheck. Using the bank's website, tell me how much money you have in your account.
Character - “You.” We do not need to be more specific in this instance since we are not testing with a very specialized user group and we can be reasonably certain that paying bills is a nearly universal experience that our participants can relate to and a scenario that they can imagine themselves in.
Situation - “[You] are paying some bills and want to see if you have enough money in your account to pay them all or if you need to pay some in a few days after you get your paycheck.” The situation tells the participants what they are doing and why they are doing it. In this case, do I have enough to pay all my bills now, or do I need to wait for my paycheck to come in?
Command - “Using the bank's website, tell me how much money you have in your account.” From this statement, it should be clear to the participants what they need to do and when they have completed the task. You’ll notice that I did tell the participant a little bit of the “how” in this case by telling them to use the bank’s website. This is because I’m researching the website and not the bank’s interactive phone system, which would be another way the participant could get their balance, but not what I’m trying to learn about right now. There is nuance here. It’s okay to give a little of the “how” when you’re testing a specific feature and need to see how the participant interacts with it.
To wrap things up, tasks are better when they follow the Character + Situation + Command structure. Not only is it easier to write tasks when you just have to fill in the individual pieces, but it also is easier for participants to understand as the structure clearly lays out all the information they need to know. The next time you are working on a usability test, I challenge you to use this structure for your tasks and see how much better your tasks become!
Does your business need any UX research support? Reach out to Key Lime Interactive, a full-service UX Research agency. We look forward to hearing from you!
Comments
Add Comment