A whiteboard legend is a small key that tells people how to read the notes on a shared board. For a workshop, the most useful distinction is often not which department wrote a note, but whether it records a fact, an assumption, a decision or an action.
When all four look alike, “We think this will help” can quietly become “We agreed to build it.” You can use a shared Boardmix whiteboard to keep these different kinds of statements together without giving them the same meaning.
Start with four labels, not four unexplained colors
Put the key beside the workshop question. Write the label on each note as well as in the key; color can help scanning, but readers should not need to remember a palette to interpret a claim.
| Label | What belongs here | What the note needs |
|---|---|---|
| Fact | A specific observation or a checkable statement within a stated scope | Source, date and relevant context |
| Assumption | An explanation or expectation not yet established by the available evidence | What is uncertain and what could challenge it |
| Decision | A choice made by the person or group authorized to make it | The choice, its scope, decision owner and date |
| Action | A concrete piece of work someone has accepted | Owner, deliverable and due date or agreed checkpoint |
“Fact” does not mean timeless truth. “Three participants opened their email” can describe a recorded observation; “People prefer email” is a broader interpretation. Likewise, a quotation proves that someone said something, not necessarily that the statement itself is correct.
These labels describe the role of a note, not its progress. If an action is finished, add a separate status such as “Done.” Do not change its label to “Fact” or reuse its color to mean approval.
Split a note that contains more than one kind of statement
Consider this workshop note:
People cannot find the event time, so we should redesign confirmation and have Mara ship it on Thursday.
It combines an observation, a possible cause, a proposed solution and an assignment that may not have been accepted. Ask four different questions before moving it into the plan:
- What did we actually observe, and where is the record?
- What explanation are we adding to that observation?
- Has anyone with decision authority chosen a response, or is it still a proposal?
- Has the named person agreed to a specific deliverable and date?
Keep an unchosen proposal in the discussion area with “Proposed” written on it. An unanswered question can stay there too. You do not need to force every contribution into one of the four categories before you know what it means.
Worked example: an event-registration confirmation
Imagine an event team reviewing a registration flow. In this illustrative case, the team has notes from five walkthroughs of the current flow. Its question is: “What should we change in the confirmation experience before the next usability review?”
Fact F1: record the observation narrowly
In three of five walkthroughs, the participant reopened the confirmation email to find the event time. Add the session date and references to those walkthrough notes. The statement does not claim that three in five customers will behave this way, or that the email caused a problem. Someone may simply have found email convenient.
Assumption H1: make the interpretation visible
Making the event time more prominent on the confirmation page may help registrants find it without opening email. Reference F1, but keep H1 as a separate note. The team can investigate it by asking people to find the event time in a revised prototype. A clear time on the page might still be overlooked, so the explanation remains open to challenge.
Decision D1: distinguish a test from a release
Prepare a prototype with a more prominent event time for the next review; do not change the live registration flow yet. The event lead records their name and the decision date. This choice is justified as a way to explore H1, not as proof that H1 is correct. “Everyone liked the idea” would not communicate the same scope or authority.
Action A1: name the handoff
Mara will prepare the current and revised confirmation screens by Thursday for the review. Mara accepts the task, and the team agrees where the screens will be placed. This is design work, not a promise to deploy. Reference D1 so a colleague can see why the task exists.
The four notes remain separate. F1 informs H1; D1 authorizes a limited response; A1 carries out that response. Their connections show the team's reasoning, not that an assumption has automatically become a fact.
Build the legend and example in Boardmix
Start with a blank board and add the workshop question as text. Boardmix's User Guide covers text, sticky notes, basic shapes and connection lines—the ordinary tools needed for this layout.
- Create a compact key. Add four sample notes labeled Fact, Assumption, Decision and Action. Under each label, add the fields from the table above. Leave the key near the question rather than in a distant corner.
- Add the four example notes. Use F1, H1, D1 and A1 as short references and put the full label first. These are labels you type, not special Boardmix record types.
- Keep references with the claims. Place a source reference beside F1. Put “Based on F1” on H1, “Test H1” on D1 and “For D1” on A1. Simple connecting lines can reinforce those relationships.
- Leave room for unresolved contributions. Place the original mixed note nearby until its author confirms that the separate notes preserve the intended meaning. Keep proposed work outside the agreed-action area.
- Review the wording together. Ask a teammate to identify what is known, what remains uncertain and what Mara is expected to deliver. Use a comment beside an unclear note to request clarification, then update the note itself when the wording is agreed.
Choose board access appropriate to the material before inviting contributors. Keep private participant details in your organization's approved location and use source references on the board. The labels, assignments and relationships in this example are maintained manually; writing an owner or due date does not create an automatic reminder or approval.
When evidence or decisions change, keep the distinction
If the next review produces a new observation, add it with its own source and date. Then update the assumption's explanation or confidence. Do not replace the original observation with the hoped-for conclusion.
If a decision changes, mark the earlier decision as superseded and point to the replacement. If Thursday's task finishes, record the deliverable and mark the action done. Those are different updates: completing a prototype does not validate the assumption or authorize release.
If the board contains many assumptions and the next question is which to investigate first, use an assumption map to compare importance and evidence. The legend solves a smaller problem: helping everyone read the same statement in the same way.
Open Boardmix and try the four-label key on one ambiguous note from your next workshop. A useful result is not a perfectly colored board; it is a colleague being able to distinguish the observation, the possible explanation, the authorized choice and the work someone has accepted.
