Prioritize Design Findings by Task Impact

Keep observations separate from explanations

Record what happened before deciding why it happened. “The participant opened three menus before finding export” is an observation; “the navigation is badly organized” is an interpretation. Include the task, starting state, relevant quote in your internal notes where appropriate, and any assistance provided. Clear evidence lets another reviewer propose a different explanation without dismissing the participant’s difficulty.

In a hypothetical document workspace, several participants may search for export inside sharing. The cause could be unclear labels, an unfamiliar information model, or a missing connection between sharing and downloading. Keep those possibilities visible until the design team reviews the behavior. Avoid turning the first plausible explanation into a permanent requirement before exploring simpler changes.

Assess consequences and recovery

Consider whether the issue blocks completion, causes an incorrect outcome, delays progress, or creates minor friction. Then ask whether the person can recover independently and whether the consequence is reversible. Frequency matters, but a rare failure with significant task consequences can deserve attention before a common cosmetic annoyance. Avoid reducing the discussion to an unexplained numerical severity score.

For document export, selecting the wrong file version may be more consequential than a slow menu search. A clear version confirmation could therefore be a higher priority than moving the button. State which users and contexts are affected. A finding observed on a small screen may still matter greatly if that is the only device available to an important audience.

Group symptoms and choose a focused response

Look for related observations that could share an underlying cause. Confusion about export, sharing, and permissions may indicate unclear distinctions between actions rather than three independent button problems. Grouping helps the team avoid scattered fixes, but do not merge findings merely because they appear on the same page. Explain the proposed causal link and its uncertainty.

Choose the smallest change that addresses the supported cause without creating a new inconsistency. In the workspace example, clearer action labels and contextual descriptions may help before a full navigation redesign. Compare alternatives by expected task benefit, implementation effort, and risk to established workflows. Document deferred findings so they remain available when related work occurs.

Verify the change against the original task

Write what should improve and what could regress. If the goal is independent export of the correct version, the verification must include version selection and completion, not just finding the button. Use relevant participants or rendered workflow checks appropriate to the uncertainty. Keep the original observation available for comparison without implying that one successful attempt settles every context.

After implementing a change, record whether the evidence supports the intended improvement, remains inconclusive, or reveals a different problem. Update the priority rather than protecting the original recommendation. A useful findings log captures the decision, owner, status, and next check. It should help the team act and learn, not become a large archive that nobody consults.

• Record behavior before assigning a cause.
• Assess consequence and independent recovery.
• Group symptoms only with a clear rationale.
• Verify the intended task outcome after changes.

If a finding changes permissions, completion, or recovery, update the user flow so the fix remains consistent across branches instead of becoming a local screen patch.Map a User Flow Before Drawing Screens