Usability testing before deployment: test your product branch with users
An interface can pass automated checks and still leave people uncertain about what to do. Functional checks tell you whether specified behavior works. Usability research asks whether the people it is intended for can understand the experience and complete a meaningful task. Both matter before a team puts a change in front of its wider audience.
Palette’s usability tests let you connect a codebase, select a branch, and build a testable version in a sandbox. Participants interact with the app, which makes it possible to examine a feature before deploying that branch. The research still needs a clear task, suitable participants, and careful interpretation.
Choose a question about task completion
Begin with an uncertainty that using the product can resolve. For example: can a workspace administrator invite a colleague with the intended level of access? That question is more specific than “Is the new onboarding good?” It points toward a task and a result the team can examine.
Keep the question separate from the expected answer. If the team believes a new permissions preview makes invitations clearer, the test should leave room for participants to misunderstand it, overlook it, or use it successfully. A task that explicitly tells them to inspect the preview removes the very uncertainty you wanted to investigate.
Use a user study for motivations or past experiences that cannot be observed through the task alone. A participant can successfully send an invitation while still having a strong reason not to invite someone in their real workplace. Usability evidence explains interaction with the tested experience; it does not establish demand by itself.
Prepare the branch as a research environment
Select the branch containing the experience you want to examine, then verify the complete task path in the sandbox. Check the starting screen, sample data, account state, and destination. A missing dependency or broken login can prevent participants from encountering the interaction you intended to study.
Use suitable test data and a clear starting state. If the task involves reports, provide a believable report. If it involves permissions, make the available roles understandable in context. Record any differences between the sandbox and the intended release, including unavailable integrations or simulated data. Those differences may influence the participant’s behavior.
Palette provides the branch-based testable version described on its usability testing page. Before recruiting, try the participant journey yourself and ask someone unfamiliar with the change to pilot it. This checks the study setup as well as the branch.
Write tasks that describe goals rather than controls
| Task that gives away the path | A goal-based alternative |
|---|---|
| Open Settings, select Members, and press Invite. | A new colleague needs to join your workspace. Add them with the access they need. |
| Use the export menu to download a CSV. | You need to work with this report in a spreadsheet. Save a copy you can use there. |
| Click the month filter and choose March. | Find the report for March and check its total. |
Give enough context for the goal to make sense, while leaving the route open. If a colleague needs a particular access level, explain what they should be able to do rather than naming the role label the participant must select. That tests whether the interface communicates the distinction.
GOV.UK’s usability testing guidance recommends believable tasks with clear goals that do not reveal the answer. Its guide addresses moderated sessions; the task-writing principle is also useful when participants work independently.
Recruit for the role and level of familiarity
A product expert and a first-time administrator may approach the same task differently. Decide which experience matters to the question, then recruit accordingly. If the feature depends on familiarity with your account model, your own users may be a better fit. If first-use comprehension is the focus, external participants with relevant workflow experience may provide a useful view.
Palette supports both your own users and an external participant panel for usability tests. Use screening questions to establish the responsibilities and experience that matter. Avoid mixing groups and reporting a single result without noting who was included. The recruitment guide explains how to define that fit.
Plan for the devices and access needs relevant to the product experience. A successful task on one setup cannot establish that the experience works across all devices or for all users. Include the coverage you actually achieved in the research note.
Review outcomes together with explanations
Review task results, success and ease ratings, and follow-up answers together. A successful outcome can still involve confusion or a workaround; a low ease rating may concern a problem outside the task you expected. Use source responses to understand what the result means before turning it into a finding.
Separate interface problems from study setup problems. If participants cannot access the sample account, that is different from being unable to find an invitation control. Keep incomplete or missing evidence visible rather than silently counting it as success or failure. Where the evidence does not explain what happened, say what additional observation is needed.
After a revision, run another focused round with a recorded version and comparable task conditions. Avoid presenting different audiences or changed tasks as a controlled before-and-after result. For the broader choice of methods, read user study vs. usability test vs. microstudy. For reviewing findings, use the research synthesis guide.