Start with a decision, not a demonstration
A usability test asks someone to try a product or prototype while you observe where the experience works and where it breaks down. It is not a presentation of your design, and it is not a test of the participant’s ability. A few carefully observed sessions can expose confusing labels, missing information or steps that require more effort than the designer expected.
Begin with a specific question you can act on. For example, if you have a prototype for a home energy dashboard, you might ask whether people can find how much electricity they used yesterday. That is more useful than asking whether they like the dashboard. The prototype may not contain live energy data; the test can still show whether its navigation and explanations make sense. Note what is simulated so you do not mistake a reaction to placeholder content for a reaction to a working service.
Choose participants who resemble the people the design is meant to serve in relevant ways. They do not need to be experts. Someone unfamiliar with the product may be especially helpful if the design is intended for first-time users. Make clear how long the session will take, whether anything will be recorded, and that they can stop at any time.
Write tasks that leave room for natural choices
Give each participant a goal rather than a set of instructions. “You want to check yesterday’s electricity use. Show me how you would do that” leaves room for the person to choose a path. “Tap the Usage tab and select Yesterday” reveals the route you are trying to evaluate. Avoid using interface labels in the task unless those words would naturally be part of the person’s goal.
Prepare a short set of realistic tasks that exercise the decisions you care about. For a device concept, one task might involve finding its battery status; another might involve changing a setting. Start with an ordinary task before introducing a less common one. If the prototype has limits, plan how you will handle them consistently. You can say, “This part is not interactive yet; what would you expect to happen here?” without pretending a feature works.
Decide in advance what you will observe: where people begin, which options they consider, where they pause, whether they complete the goal, and what they believe happened afterward. These observations are more informative than a single success-or-failure score. They also help you notice a design that technically permits completion but makes the route hard to understand.
Use a neutral introduction and prompt sparingly
At the start, explain that you are evaluating the design, not the participant. Invite them to describe what they are looking for or expecting as they work, but do not require a constant narration. Tell them you may stay quiet so they have space to decide what to do. A neutral introduction can reduce the pressure to please you or guess the answer you want.
During a task, resist the urge to point, explain a label or reassure someone that they are close. Even a well-meant “Did you see the button at the top?” changes what you are measuring. If a participant pauses, give them time. If you need to speak, try an open prompt such as “What are you thinking now?” or “What would you try next?” Use the same approach across sessions so differences in your behavior do not shape the results.
When someone asks, “Is this right?”, you can reply, “What would you expect to happen if you chose it?” If they become stuck and cannot continue, record where that happened before moving on. Helping them afterward is fine; silently treating a coached completion as an independent success is not.
Separate what happened from what you think it means
Take brief notes in two parts: observation and interpretation. “Participant opened Settings, then returned to the home screen” describes behavior. “They did not understand the icon” is a possible explanation that needs checking. Ask a follow-up after the task, such as “What were you looking for when you opened Settings?” This lets the participant explain their choice without being pushed toward your theory.
Avoid praise or surprise that could influence later answers. Instead of “Great, that was easy!” ask, “How did that compare with what you expected?” Likewise, “Was the menu confusing?” suggests an answer, while “What, if anything, was unclear?” allows for several possibilities. People may say they like a screen while struggling to use it, so consider their comments alongside their actions rather than treating either as the whole story.
Turn observations into a small design change
After the sessions, group notes by task and look for repeated points of friction. A problem seen once can still matter, particularly if it prevents someone from completing an important goal, but avoid assuming that every individual preference applies to everyone. Describe the issue plainly: “Participants looked under Settings for battery status, but the prototype shows it only on the device card.” That gives the team something concrete to address.
Choose a change you can test, such as revising a label, making status information easier to spot or adding a clearer confirmation after an action. Then try the revised design with people who have not seen the earlier version. The purpose is not to prove the design is good. It is to make the next decision with a clearer understanding of what people actually do when no one guides them.
