In a usability study of a government service, many participants requested dark mode. The design only had a light mode. The request was clear, but the reasons behind it were unknown.
That gap matters. A team could start designing a theme switcher immediately and still be unsure what it needed to improve. Was the request about reading comfort, a familiar setting, or a preference for how the interface looked?
A useful usability test plan starts by making those questions explicit. The five steps below show how to move from a requested feature to evidence that can guide a design decision. The dark mode examples that follow are illustrative; they describe possible research steps, not additional findings from that government study.
1. Capture the request alongside the task
Start with what the participant was trying to accomplish when the request came up. Record the task, the screen or step (ensure the user consented to recordings), and any behavior you actually observed. Keep the participant’s words separate from your interpretation. If you only have a summary of their comment, label it as a paraphrase.
In an illustrative session, a participant might ask for dark mode while reading instructions. Your note could record that they enlarged the page, reread a paragraph, and then asked about changing its appearance. Those details are observations. A conclusion such as “the bright background made the instructions difficult to read” would need more evidence.
Timing also matters. A request raised during a difficult task deserves a different follow-up from a suggestion offered when the moderator asks what features are missing. Record whether the request was spontaneous or prompted. Both can be useful, but the context affects what you can infer.
When several people make a similar request, preserve each person’s unique context before grouping the comments. You must be aware similar wording can describe different needs. Count the requests only when your records support a count, and keep that count tied to the study. It does not tell you how common the need is across the whole audience.
2. Ask neutral questions about the experience
Let the participant explain what they expect the feature to change. Begin with the moment in front of you: “What were you trying to do here?” Then explore the request: “What would you expect dark mode to change for you?”
Follow their answer with questions about context. “When would you use that setting?” or “Can you describe a recent situation where it helped?” can make a general preference more specific. Ask one question at a time and leave room for an unexpected answer, do not try to influence their decision at any point.
Avoid supplying the explanation yourself. Asking whether the screen is too bright introduces an answer before the participant has described the problem. If brightness comes up in their response, you can ask what they noticed and how it affected the task.
In the illustrative dark mode scenario, one person might simply prefer the appearance. Another might describe difficulty reading the text. Someone else might explain that a display setting helps them use a service comfortably. These accounts can overlap. Record what each person says without diagnosing a condition or assuming every dark mode request is an accessibility issue.
You also do not need to collect medical details to investigate the task. Ask what the person needs to use the interface and which settings they normally rely on. If accessibility barriers emerge, plan appropriate evaluation with relevant participants and expertise. Ideally, accessibility needs should have been accounted for during your recruitment exercise. A preferred color theme alone cannot establish that an interface is accessible.
3. Write competing explanations as hypotheses
Turn the possible explanations into statements you can investigate. Keep them specific enough that you can describe evidence that would support or challenge them.
For the illustrative reading task, one hypothesis could be that the participant finds the light appearance uncomfortable in their usual environment. Another could be that the instructions are difficult to scan because the text is dense. A third could be that the participant expects the service to match the theme they already use on their device.
Each explanation suggests a different comparison. Changing the theme could help investigate appearance. Revising the text layout could help investigate scanning. Observing what someone expects from their existing device setting could clarify a consistency concern.
Write down what would make you reconsider each explanation. If a participant still struggles to find a required instruction after changing the theme, a color change may leave an important problem unresolved. If clearer grouping helps them find it while their appearance preference stays the same, you have learned about two separate concerns.
Keep preference and task performance visible in the notes. Someone can prefer a version without completing the task more easily. They can also complete a task successfully while reporting discomfort. Neither observation cancels the other. Decide which uncertainty matters for the next decision before choosing what to test.
4. Choose a test that can change the decision
Start with the smallest study that can answer the immediate question. If you still do not understand the request, a moderated usability session gives you room to ask follow-up questions. If the task and questions are already clear, an unmoderated study may help you observe participants working independently. Loop11’s online usability testing platform is one option for running either type of remote study.
For the illustrative dark mode example, suppose the next decision is whether to develop a theme option. A short prototype test could compare light and dark versions of the same reading task. Keep the wording, layout, and functionality consistent so the comparison is easier to interpret. If participants see both versions, vary the order and use comparable tasks to reduce the influence of practice.
Give participants a realistic goal. For example: “Find the documents you would need before starting this application.” Avoid telling them to try the new theme or praising a design choice before they begin. If finding the theme setting is itself the research question, test that separately with an appropriate task.
Recruit people whose relevant use contexts you need to understand, including different theme preferences. Decide how many participants to recruit based on the study’s purpose and the decisions at stake. A small exploratory study can reveal questions to investigate further; it gives limited grounds for estimating how widespread a preference is.
Before the sessions, define what success means for the task. In this example, that could mean identifying the correct documents without moderator help. Record errors and requests for help alongside participants’ accounts of comfort and preference. Ask the same core questions across versions.
Specify how the findings would affect the next step. Clearer task performance and improved reported comfort could support further development of the theme option. Continued difficulty locating information would support investigating the content or layout as well. Mixed findings may justify an optional setting or more targeted research. Treat those as possible decisions to evaluate, and document what remains uncertain.
5. Keep a reusable record of the decision
Use a short note with four fields so the reasoning survives beyond the research session. The same structure can work for requests about filters, exports, notifications, or navigation.
Request: Capture what the participant asked for, whether it is a quote or paraphrase, and the task context. Note whether you prompted the suggestion.
Evidence: Record relevant observed behavior and reported experience separately. Include a session reference that lets an authorized teammate check the source. Keep identifying details out of broadly shared summaries.
Uncertainty: List the explanations still open, the limits of the evidence, and what would challenge your current interpretation.
Next step: Name the research question, method, participants, task, and evidence you will collect. State which decision the study should inform and who will review the findings.
Update the note after testing. Preserve findings that complicate the original explanation, and record the reason for the next decision. This makes it easier to revisit a request without starting the same discussion again.
The next time a participant names a feature, capture the request and ask what they expect it to change. Then choose a task and a comparison that can investigate that expectation. You will have a practical starting point for a usability test plan, with a clear connection between what someone asked for and what the team needs to learn.
- How to Turn Feature Requests into Usability Test Plans - October 26, 2026
Give feedback about this article
Were sorry to hear about that, give us a chance to improve.
Error: Contact form not found.
