"Design: the day follows the evidence"

A reading of a team tells you what is actually constraining it — which of the eight dimensions is weak, where the real problem sits, what is holding the team back beneath the visible symptoms. That reading is not the end of anything. It is the input to a design. And the design stage — the second stage of the method, after the scan — is where the evidence about a specific team becomes an experience built for that team and no other. It is the stage most often skipped, because it is the one that looks optional, and it is the one that separates a day that moves a team from a day that merely fills an afternoon.

Design, in the sense the method means it, is not choosing an activity. It is building an experience backward from a reading — starting with what this team actually needs and constructing a day that addresses it, rather than starting with an activity and hoping it fits. That difference sounds small and is total: the first produces a day aimed at a real constraint, the second produces a day aimed at nothing in particular. Understanding what design actually is, and why it cannot be replaced by selection from a catalogue, is understanding the difference between an intervention and a decoration.

Design starts from the reading, not the catalogue

The defining feature of design is where it starts. A designed day starts from the reading — the evidence about what is actually constraining this specific team — and works backward to an experience that addresses that constraint. A selected activity starts from the activity — what it is, what it is known for, what the catalogue says it does — and applies it to the team regardless of whether the team needs it. The two run in opposite directions, and the direction determines whether the day is aimed at anything real.

This is why design cannot be done from a catalogue, however good the catalogue is. A catalogue lists activities by what they are, and choosing from it means choosing an activity for its properties rather than building an experience for a team's needs. Even a well-chosen catalogue activity is chosen for the category of thing it addresses, not for the specific constraint this team actually has, which the catalogue could not know because the catalogue was written before the team was read. Design requires the reading to come first and the experience to be built to it, which is exactly what selection from a catalogue cannot do, because selection starts from the activity and design starts from the team.

What the design stage actually produces

The output of good design is an experience whose every significant choice traces back to the reading. The activity, its framing, its sequence, the moments of difficulty and the moments of release, what the facilitation emphasises and what it lets pass — all of it is chosen because the reading indicated this team needs it, not because it is standard or popular or enjoyable. A designed day has a reason for each of its major elements, and the reason is always the same kind of reason: this serves the constraint the reading surfaced. Nothing is in the day by default; everything is in it by design.

This is what makes a designed day feel different to the team experiencing it, even when the team cannot say why. The day fits — it addresses something the team actually feels, moves something that was actually stuck — because it was built to the team's real constraint rather than applied to it generically. A generic day, however polished, has a slightly off-target quality that people feel without naming: it is fine, it is pleasant, and it does not quite touch the thing that was actually wrong, because it was never built to. A designed day touches it, because touching it was the point of every choice in the design. The difference is legible to the team even when the design behind it is invisible.

Designing to the constraint, not the symptom

The hardest part of design is that it has to target the real constraint, which the reading identifies, rather than the visible symptom, which is what everyone can see. A team's presenting problem — the thing people complain about, the visible dysfunction — is usually a symptom of a deeper constraint, and a day designed to address the symptom will not move the constraint. If the reading found that a communication complaint is really a safety problem, the design has to address the safety, not the communication, even though the communication is what everyone named. Designing to the symptom produces a day that addresses what people see and misses what is actually wrong.

This is where design depends most heavily on the reading, and where skipping the reading is most costly. Without a reading, a designer has only the symptom to go on, so the design inevitably addresses the symptom, which is the wrong target. The reading is what lets the design aim past the symptom to the constraint — and a design that aims at the constraint can move a team that a hundred symptom-addressing days would leave exactly where it was. This is the same logic that runs through diagnostic-first design: the value of reading first is that it lets design target the real thing, and the cost of skipping it is a design aimed at the wrong thing, however well executed. Design to the constraint, and the day can work; design to the symptom, and it cannot, whatever it does.

Why enjoyable is not the same as effective

A designed day and an enjoyable day are not the same thing, and conflating them is one of the most common design failures. A day can be thoroughly enjoyable — people have fun, the feedback is warm, everyone leaves in a good mood — and move nothing, because enjoyment was the goal rather than a by-product of addressing the real constraint. Enjoyment is easy to produce and easy to measure, so it becomes the target by default, and a day designed for enjoyment optimises for the wrong thing: it maximises the fun and ignores whether anything actually changed.

Good design treats enjoyment as a means, not an end. The day should be engaging, because an experience people are checked out of moves nothing — but the engagement is in service of the intervention, not a substitute for it. A designed day is enjoyable because being enjoyable helps it work, not because enjoyable is the goal. This distinction matters because the market is full of days optimised for enjoyment that produce warm feedback and no change, and a company that judges a day by whether people liked it will keep buying those days, mistaking the enjoyment for effectiveness. Design that follows the evidence produces days that are enjoyable and effective, because the enjoyment is built to serve the constraint rather than to replace addressing it. The test of a design is not whether people liked it; it is whether it moved what the reading said needed moving.

Design is a craft, not a selection

Because design builds backward from a reading to an experience, it is a genuine craft — a skilled act of construction — rather than an act of selection. It requires understanding how experiences move dimensions, how to translate a constraint into a sequence of moments that addresses it, how to build difficulty and release, challenge and safety, in the proportions a specific team needs. This is expertise, and it is not the same expertise as knowing a lot of activities; it is the expertise of building an experience to a purpose, which is closer to design in any other field than to picking from a menu.

This is why design cannot be automated into a lookup — reading X, therefore activity Y. The relationship between a constraint and the experience that addresses it is not a lookup table; it is a design problem, requiring judgment about this specific team, its specific constraint, its specific context, and how all of that translates into an experience that will actually move it. Two teams with the same weak dimension may need quite different designs, because the constraint sits in different contexts, and the craft is in seeing that and building to it. Treating design as selection — as if the reading just indexes into a catalogue — loses exactly the craft that makes design work, which is the judgment that builds a specific experience for a specific team rather than retrieving a generic one.

Design and the stages around it

Design sits between the scan and the build in the method, and it depends on both sides. It depends on the scan for its input — a design is only as good as the reading it is built from, and a design built from a poor reading will be well-crafted and aimed at the wrong thing. And it hands off to the build, where the design becomes a real, runnable day; a design that cannot be built, or that is built poorly, does not reach the team as intended. So design is a middle stage, receiving the evidence and producing the blueprint that the build will turn into an actual experience.

This position is why design failures often masquerade as scan or build failures, and vice versa. A day that did not work might have failed at the reading, at the design, or at the build, and telling them apart requires understanding the stages as distinct. A design aimed at the wrong constraint failed at design even if the reading was good and the build was flawless; a good design executed badly failed at build even though the design was right. The method separates the stages precisely so that a failure can be located and fixed at the right point, rather than blaming the activity when the problem was the reading, or the reading when the problem was the design. Design is one link in that chain, and it has its own way of failing, which is aiming a well-crafted experience at the wrong target.

Design works within real constraints

Design does not happen in a vacuum; it happens inside real constraints — a budget, a time window, a group size, a venue, a set of logistical limits — and good design treats those as inputs rather than excuses. The constraint on time or budget shapes what is possible, and a good designer builds the best possible intervention within those limits rather than either ignoring them or hiding behind them. A design that pretends the constraints do not exist produces a day that cannot actually be run; a design that treats the constraints as a reason to do nothing meaningful abandons the point. The craft is to build the most effective experience the real constraints allow.

This is where design shows its skill most clearly, because designing to a real constraint is harder than designing without one. Anyone can imagine an ideal day with unlimited time and budget; the craft is building a day that moves the team's actual constraint within a half-day, a fixed budget, and a group of forty, which requires genuine design judgment about what to prioritise and what to let go. A good design under tight constraints is aimed at the constraint the reading found and shaped to the limits the situation imposes, achieving the most it can within them. The limits do not change the target — the design still follows the evidence — they change the means, and working out the best means within real limits is exactly what design is for. A design that uses constraints as an excuse for a generic day has abandoned the craft; a design that achieves a real intervention within them has exercised it.

The reading becomes a brief

Between the reading and the built day sits something worth naming: the design brief — the translation of the evidence into a specification for what the day must do. A good brief states what the day is for in terms of the constraint the reading found: this day exists to move this dimension for this team, given this context and these limits. Everything the design then contains is answerable to that brief, which is what keeps the design honest — each choice can be checked against whether it serves what the brief says the day is for, rather than drifting toward what is familiar or easy.

The brief is also what makes design reviewable, because it states the target the design is meant to hit, against which the design can be judged. Without an explicit brief, a design is judged by taste — does this look like a good day — which cannot catch a well-crafted day aimed at the wrong constraint. With a brief, the design is judged by fit — does this serve what the reading said the team needs — which is the judgment that actually matters. This is why the discipline of writing the brief, of stating in plain terms what the day is for before designing it, is worth the effort: it forces the design to declare its target, and a declared target can be checked, while an unstated one lets the design drift toward the generic without anyone noticing. The brief is the bridge from evidence to design, and a design with no brief behind it has usually skipped the bridge.

Design and the room

Design produces a plan, and a plan meets a room that will not behave exactly as the plan assumed — which is why good design builds in the capacity to adapt rather than specifying a rigid script. A design that can only run one way, exactly as written, is brittle: the moment the room differs from what the design assumed, the day has no way to respond, and it either forces the plan onto a room it does not fit or falls apart. A design that anticipates variation — that gives the facilitation room to read the room and adjust while still serving the brief — survives contact with the actual team, because it was built to flex toward its target rather than to execute a fixed sequence regardless.

This is the handoff from design to delivery: the design sets the target and the shape, and the delivery adapts the shape to the room in real time, still aimed at the target. A good design makes that adaptation possible by being clear about what is fixed — the target, the core structure — and what can flex — the pace, the emphasis, the specific moments — so the facilitator can adjust the flexible parts without losing the fixed ones. A design that fixes everything leaves no room to adapt; a design that fixes nothing leaves no target to serve. The craft is fixing the right things — the target and the essential structure — and leaving the rest adaptable, so the day can meet the actual room while still doing what the reading said it needed to do. Design that anticipates the room is design that will still work when the room is not what anyone expected.

Reading a design for whether it follows the evidence

You can read a design — before it is ever run — for whether it actually follows the evidence, and it is worth doing, because a design that does not follow the evidence will not work regardless of how well it is built or delivered. The test is whether the major choices in the design trace back to the reading: whether you can ask, of each significant element, "why is this in the day," and get an answer that refers to the team's actual constraint rather than to habit, popularity, or enjoyment. A design that passes this test is aimed at something real; a design that fails it is aimed at nothing in particular, however polished.

This is a more useful check than any after-the-fact measure, because it catches a doomed design before it consumes a day. A design whose elements trace to the reading may still need adjustment, but it is aimed correctly; a design whose elements trace to "this is what we usually do" is misaimed at the outset, and no amount of good delivery will make it hit a target it was never pointed at. Reading a design for its evidence-trail is how you catch the generic day disguised as a designed one — the day that looks bespoke and is really a standard activity with the team's name on it. Design that follows the evidence has an evidence-trail; design that does not is decoration, and the trail is what tells them apart.

A worked example

A team is read and the constraint turns out to be decision-making — the team cannot surface and resolve real disagreement, so its choices stall and unravel. A generic response would select a "communication and collaboration" day from a catalogue, because that is the category the symptom seems to fit, and run a pleasant, well-executed activity about working together. It would be enjoyable and it would move nothing, because it was aimed at collaboration when the constraint was decision-making, and a day aimed at the wrong dimension does not move the right one however well it is run.

Design that follows the evidence would build backward from the actual constraint. Knowing the team cannot safely surface disagreement, it would construct an experience that requires the team to surface and resolve genuine disagreement in a setting safe enough to do it — building the specific capability the reading identified, in the specific way this team needs it. The activity, the framing, the sequence, the facilitation emphasis would all trace to that constraint. Same team, same day-length, same budget — but one day is aimed at the real thing and the other at a plausible-looking wrong thing, and only the first can move the team. The measurable difference shows up later, at Day 14, 30 and 60, where the designed day's target actually moves and the generic day's does not, because the generic day was never aimed at it.

Build the day the evidence asks for

Design is the second stage of the method, and it is the one that turns a reading into an intervention. It starts from the evidence about a specific team and builds backward to an experience aimed at that team's actual constraint — not from a catalogue, not from habit, not from what is enjoyable, but from what the reading said this team needs. That is a craft, not a selection, and it is what separates a designed day from a generic activity with a team's name attached.

The discipline is simple to state and hard to hold: let the design follow the evidence, target the constraint rather than the symptom, and treat enjoyment as a means rather than the goal. A design that follows the evidence has a trail — every major choice traces to the reading — and a design that does not is decoration, however polished. Build the day the evidence asks for, not the day the catalogue offers, and the day can actually move the team — which is the whole reason to design rather than simply to select, and the whole reason the reading came first.