Coverage planning
Build a user-journey coverage matrix without testing everything
UxerProof Editorial · · 3 min read
A list of tested pages can look comprehensive while missing the task that matters. The same screen can behave differently for a new member, a returning administrator or someone with an expired session. Coverage needs to describe the conditions of use, not only the route names.
A journey matrix makes those conditions explicit. Its purpose is to reveal meaningful gaps, not to generate every possible combination of every setting.
Begin with outcomes
List the few tasks your release needs to support. Use outcomes such as “save and reopen a draft” or “review a submitted request.” Avoid broad entries such as “test settings” that do not have a clear finish line.
For each task, identify the role, starting state and environment. Add a device or input condition when it changes the experience you need to assess. Then select a recovery state likely to expose a consequential gap.
Keep the first matrix small
The following example is illustrative, not a claim about a particular product's coverage.
| Task | Role and starting state | Important variation | Required evidence |
|---|---|---|---|
| Create first draft | New contributor; empty workspace | One invalid required field | Correction path and saved result |
| Find existing work | Returning contributor | Active filter returns no matches | Visible filter and usable recovery |
| Review submission | Authorized reviewer | Item changes before review | Current version and clear next action |
| Resume work | Existing member | Session expires mid-task | Reauthentication and preserved work, where promised |
Attach the release version and outcome to each executed row. Leave a row unassessed until evidence exists. Planning to run a test is not the same as covering it.
Choose variations by consequence
You do not need to begin with every browser, locale and account type. Ask what changes the task materially. A permission boundary, a narrow-screen layout or a different starting dataset may deserve separate coverage. Two cosmetic themes may not matter equally for the current release.
Record the selection rationale. For example, a team could prioritize mobile review because its pilot users perform approvals away from their desks. That is a product-specific reason, not a universal instruction to test one device first.
Preserve the gaps in the report
Do not average a failed critical task into a reassuring percentage. A matrix is most useful when the reviewer can see which outcomes are complete, blocked, failed or not assessed.
If one row cannot run because its dependency is unavailable, keep the dependency visible and name its owner. If a task changes, update the matrix rather than leaving an obsolete row to inflate the coverage count.
At review time, ask whether the untested combinations could change the release decision. That question keeps the matrix connected to the product's actual risk rather than turning it into a checklist maintained for its own sake.
Next step: Use the release-readiness check to identify prerequisites before executing your selected journeys.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.