Load Bearing

A brief, a pile of parts, and fewer slots than parts. Build the thing — a shift handover, a job aid, a first week — then real situations arrive one at a time and each either holds or gives way. Every part is genuinely useful; none of them are junk. The mistake available is picking two that cover the same situation, which feels thorough and is the opposite: a slot spent twice on one risk while another sits uncovered. The debrief names that pair, and compares your coverage against the best any build of that size could have reached, found by enumerating every combination. Five looks ship with it — the activity’s own, plus a workshop, a harbour, a summit and a winter market, drawn in the file itself with no images to load.

Open the activityDownload

Problem

Checklists, handovers and job aids fail on what was left out, and the thing left out is rarely obvious at the time — it loses its place to a second item covering ground that was already covered. Nobody notices until the situation nobody planned for turns up, and by then the document has been in use for months.

Who it helps

Teams writing handovers, job aids, checklists or onboarding plans, and anyone being taught to design for coverage rather than for completeness.

In training

Make them say what each part is for before it goes in the build. Two answers that match is the moment the activity exists to produce, and it lands far harder coming from the room than from the debrief screen. Run it twice at different slot counts if you have the time — the same brief at three parts is a different conversation from five, because at three there is no build that covers everything and the argument moves to which failure you accept.

Skills shown

Coverage modelling, redundancy detection across a chosen set, exhaustive combination search for scoring against a real optimum, staged consequence reveal, in-browser editing with persistent export.