Plan a recommendation tool people can understand

Start with the visitor’s decision

Suppose someone wants to find a suitable community workshop. The useful result is a short list of sessions they can actually attend, with reasons: “This session matches your evening requirement and its access information is confirmed.” A badge saying “Best for you” without the underlying reason does not help them decide. Write down the decision the visitor will make after reading the result, the options in scope, and the facts needed to evaluate them.

Use this format when stated needs change which options can be suggested. A comparison tool puts stable differences side by side. A configurator keeps a combination of chosen parts valid. An assessment interprets answers against a scoring framework. A recommendation tool evaluates each available option against the visitor’s stated requirements, then explains the resulting set. It may link to a comparison for the remaining trade-offs; it need not manufacture a score.

Separate “must have” from “would prefer”

Ask a visitor whether each answer is a hard requirement or a preference when that distinction changes the result. If step-free access is required, a session confirmed as stairs-only is excluded. If a morning slot is preferred, an otherwise suitable evening session remains eligible and can still be shown. Do not silently relax a hard requirement to fill a results page. A preference should change presentation only through an explained rule, never turn a known mismatch into a claim of eligibility.

Keep the questions short and label the choices in the visitor’s words. W3C’s Forms Tutorial recommends labels, clear instructions and asking only for information needed to complete the process. Offer “not sure” where it has a useful meaning. Explain before submission how an unanswered requirement will be treated; a missing answer is not permission to assume a preference or a positive fact.

Write one inspectable rule trace per option

Use the downloadable worksheet to record a hypothetical visitor case against each candidate option. Give every row the stated need, whether it is hard or preferred, the option fact, rule and precedence, evidence with its checked date, rule owner and version, expected outcome, visitor-facing explanation, next action and review trigger. A teammate should be able to reproduce the result with the sheet and no access to the code.

Evaluate in this order: check for contradictory or invalid answers; confirm the current rule set and option facts; apply every hard requirement; keep missing or expired evidence as unknown; then use preferences to order eligible options if the ordering rule is documented. “Excluded” requires a confirmed hard mismatch. “Unknown” means the available evidence cannot establish the answer. “Eligible” means the option meets every stated hard requirement on current evidence. “Selected” is a further editorial choice that needs an explicit reason; it must not be a synonym for paid placement.

• Define each option fact in a common vocabulary, including conditions such as dates, locations and accessibility arrangements.
• Name the evidence source, last checked date, expiry or next review trigger, accountable owner and rule version.
• Document any preference ordering and the tie behavior. Show tied eligible options together when the rule cannot distinguish them.
• Write a short explanation for selected, eligible, excluded, unknown, conflict and no-match states, with a useful next action.

Hypothetical example: a community workshop finder

The worksheet contains invented sessions A (morning, confirmed step-free), B (evening, confirmed step-free), C (evening, confirmed stairs-only) and D (evening, access information out of date). These are planning examples, not real events or Kinetivy client results. For a visitor requiring an evening time and step-free access, B can be selected; A and C are excluded for different hard mismatches; D remains unknown until its access information is checked. The result should show those distinct reasons instead of quietly dropping A, C and D.

Change only the visitor’s time answer to “morning required.” A becomes the selected option and B is excluded. That one-answer test proves the tool is responding to stated needs. In a separate case with no hard access requirement and only an evening requirement, B, C and D are all eligible and tied because no documented preference distinguishes them; keep D’s stale access fact visible even though access was not required. If someone states both morning and evening as required for one session, treat the answers as a conflict to resolve before evaluating options. If all current options are confirmed mismatches, say “No matching session is listed” and offer the choice to revise a requirement or contact a human. Do not recast a mismatch as a near match without clearly saying which requirement fails.

A further hypothetical variant removes B’s access fact altogether. For a visitor requiring evening and step-free access, B becomes unknown rather than eligible or excluded. The worksheet keeps this missing-fact test separate from its expired-fact test, because an empty source field and an out-of-date claim need different human corrections.

Explain what happened and what to do next

A useful result starts with the visitor’s requirements in plain language, followed by the eligible options and the reason each appears. Put exclusions and unknowns where they can be inspected. For an unknown, name the missing or stale fact and give a verification route; do not treat it as either a match or a confirmed failure. Conflicting answers need correction before any matching. Reserve “no match” for a valid request where every option is excluded by confirmed facts. If no option is confirmed eligible but some remain unknown, say that the answer is unresolved and show what must be checked.

If the business owns, sponsors or benefits from an option, disclose the relationship where it could affect inclusion or placement. The UK Competition and Markets Authority’s evidence review describes how defaults, ordering and presentation can shape online choices. This guide uses that evidence as a design prompt: inspect preselection, unexplained priority and any pressure to accept one result. It does not establish a legal test or a universal ranking formula.

Let people correct answers and inspect changes

Show the answer summary next to the result and provide an obvious way to change one answer without restarting. Validate a contradictory requirement with a specific message beside the relevant controls and an instruction for resolving it. W3C’s validation tutorial covers clear required-input feedback and user confirmation or undo. Use visible labels, keyboard-operable controls and clear focus states; test the journey at narrow widths and with zoom. Review the complete interface against WCAG 2.2 AA rather than assuming that a correct rule matrix makes the page accessible.

When results update in place, announce a concise status such as “One eligible session; one needs confirmation,” while leaving the full explanation in readable content. W3C’s guidance on status messages discusses making such changes available to assistive technology without moving focus. Do not read a long option list into the status message or change focus unexpectedly after every answer.

Test the decision trace before and after each change

Ask a person who did not write the rules to calculate every worksheet case by hand, then compare the interface result and explanation. Include a selected option, a confirmed exclusion, missing evidence, stale evidence, a tie, no match, conflicting requirements, a hard-versus-preference change and the one-answer change that switches the suggestion. Test the same cases after an option fact, rule, label or explanation changes; version rules and copy together so an old result can be understood.

Assign a human owner to each source of changing facts. If a required fact passes its review date, remove that claim from eligibility until it is checked or mark the option unknown. Provide a route for a visitor to question an error and for staff to correct the source, review affected outcomes and publish the new version. If the tool is merely applying explicit rules, call it a rules-based recommendation; there is no need to describe it as AI. The finder can evaluate answers in the browser without saving them. Do not send raw answers, personal details or result traces to analytics.