Define the decision
Collect the actual question and the point in the workflow where it occurred. Record the user’s role, available information and intended decision without unnecessary personal details. Group similar questions only when their underlying problem matches. Frequent questions about graphic size may arise from confusing frame models rather than missing arithmetic.
Build a usable record
Identify whether the remedy is better content, clearer field wording, a deterministic calculation, an evidence request or a specialist escalation. Define the expected improvement in concrete terms: fewer unit mistakes, a more complete brief or easier identification of an unknown finish. Avoid adding a tool that merely gives a confident answer to an ambiguous input.
Check the evidence boundary
Build a small candidate with representative examples and compare it with the existing journey. Include missing and contradictory inputs. Explain the result’s scope and the user’s next action. Keep the old support record and resulting design decision so later teams understand why the feature exists and when it should be reviewed.
Worked example — illustrative
In a fictional support log, teams repeatedly ask whether a retained frame accepts a replacement face. The response becomes a compatibility evidence checklist linked to the asset reference, rather than a universal yes/no material selector. Users can record confirmed, incompatible or unknown states and request the actual model-specific information.
Put the method into practice
Use the corrective-action template to connect the recurring question, proposed change, owner and evidence of the trial. Evaluate whether the change helps users complete the task, not just whether it attracts clicks. Leaf’s public tools remain planning aids; a support-derived feature does not establish manufacturer approval or actual project acceptance.
- Preserve the real question context.
- Choose the smallest useful remedy.
- Test unknown and conflicting inputs.
- Measure task completion.
