How to prioritise assumptions before building your next idea.

1. Name the next commitment you might change.

Start with a concrete decision: whether to build an account system, print a first batch, recruit a pilot group, or ask a coordinator to maintain a resource. A broad question such as will this mission succeed is too large for a useful assumption map. You need a decision that could reasonably change when new evidence arrives.

Write what the commitment would require in time, effort, money, or responsibility, without inventing precise figures you do not know. Then name the part that is hard to reverse. You may learn something with a draft before ordering a full print run, or confirm an operational owner before promising weekly updates. The map should influence an actual choice, not become another document that sits beside an unchanged plan.

2. Turn a broad belief into specific assumptions.

GOV.UK's alpha guidance focuses attention on the assumptions that could prevent a service from working. Use that principle without importing a government delivery timetable into a small project. Ask what must be true about the person's need, the proposed experience, the delivery arrangements, and the conditions for keeping the promise over time.

Separate people need help choosing a role from people will use our new page and the team can keep the page current. Each is a different belief and may need different evidence. Avoid combining them into people want our solution. One interview account cannot automatically support all three, and a working prototype cannot confirm that someone has accepted an ongoing maintenance responsibility.

3. Compare the consequence of being wrong with the evidence available.

For each assumption, ask what would change if it were false. Would you adjust wording, change the format, stop a planned feature, or withdraw the promise? Then record the most relevant evidence you have and its limits. A dated observation with likely users is different from a colleague's confident opinion; an old observation in a different context may still leave the current question open.

You can discuss importance and support in plain language rather than multiplying invented scores. For example: important because the promise fails without current information; weakly supported because no maintenance owner has agreed to it. Keep the reason beside the judgement. A low-looking score must never be used to wave away a safety or access concern that requires specialist attention.

4. Match the learning method to the uncertainty.

Use an interview to understand a recent experience, an observed task to examine whether someone can use a proposed version, and an operational check to confirm a dependency with the people who own it. These methods answer different questions. Asking whether a page looks helpful is not the same as watching someone use it; a friendly reaction does not establish a future purchase or repeated use.

Write the question, method, decision rule, and limitations before the test. Keep the effort proportionate, but do not make a promise incomplete simply to make a test small. If a person would rely on information that has not been checked, resolve that dependency before inviting them to act on it. Choosing another method, asking for qualified review, or stopping can each be the right next step.

5. Work through a hypothetical assumption map.

Imagine a team considering a searchable volunteer-role directory. This is a hypothetical example, not a SIX33 result. The proposed directory depends on three beliefs: people need help finding a suitable role, a searchable list helps them choose, and coordinators can keep availability accurate. The team has recent accounts about unclear options but no observed use of a directory and no agreement about maintenance.

The maintenance assumption matters before a public pilot: stale availability would make the promise unreliable even if search worked perfectly. A first action is to ask the responsible coordinators what updating would involve and whether anyone can own it. That is an operational dependency check, not evidence that the directory has demand. If nobody can maintain the information, the team may need a smaller, dated resource or a different service arrangement.

If the dependency can be resolved, the next uncertainty is whether the proposed list helps people complete the task. A bounded prototype session can investigate selection and confirmation, recording assistance and confusion. It cannot establish long-term participation, the size of the wider market, or impact on the community. The map has earned its place if it changes the order or scope of the work before a costly commitment.

6. Record what changed, including what remains unknown.

After the learning step, keep the result and interpretation separate. Record which version was involved, what happened, who or what the evidence describes, and whether the original decision rule was met. If you change the rule afterward, retain the original and explain why. Otherwise an ambiguous result can be quietly rewritten as the answer the team hoped for.

Update the assumption's status in bounded language: supported for this context, contradicted in this test, or still unresolved. Do not mark an assumption permanently proven. A different audience, a larger delivery, or a new operating arrangement may change what is relevant. Give unresolved assumptions an owner and a review trigger so uncertainty stays visible rather than disappearing from the document.

Finally, state the next decision: proceed with a limited commitment, change the response, gather different evidence, or stop. A completed map is not the outcome. The useful result is a better sequence of responsible commitments, with fewer unsupported beliefs hidden inside a public promise. Keep completed worksheets private when they refer to participants, internal constraints, or material that was not agreed for publication.