From a bad situation to a running system.
Concept design proceeds in four movements: find something genuinely bad in the world as it is, identify the concepts that would mitigate it, define each one fully enough to predict its every scenario, and disentangle the whole into parts that compose without depending on each other. Each movement below is a compression of a longer guide.
Where you start determines where you end up.
Three common starting points quietly steer projects toward failure: embracing a technology before knowing why it’s relevant; framing goals as values like “efficient” or “customer-friendly” that are too blunt to guide anything; and trusting what people say they want, when wants are imagined solutions and users are rarely good designers.
A need is a figment
A stated need describes something that doesn’t exist yet, and people are unreliable narrators of the imaginary: given exactly what they asked for, they often decline to adopt it. Wants also arrive pre-shaped as features, which means the person is already designing — badly — instead of reporting.
A problem is observable
A bad situation exists today. It can be watched, confirmed, and pointed to, and people describe their problems far more accurately than their desires. Best of all, it’s a yardstick: when the design ships, you can check whether the bad thing still happens. People rarely change their behavior for an innovation; they adopt the one that removes what bothered them until being without it feels intolerable.
The iPod is the canonical case. MP3 players existed; a shinier one would have changed nothing. What Apple named were bad situations: you couldn’t carry all your music, getting files meant ripping or piracy, and buying one song meant buying the album. Each design element answered one of them — and once named, the badness was irrefutable.
Beware features in disguise. “Our email client has no emoji reactions” is not a bad situation; it’s a solution being smuggled in. The real situation might be: the lead asks her team to vote on a decision and gets long-winded replies and no commitments. That reframing opens better answers than reactions — an explicit voting mechanism, say.
Good bad situations are concrete rather than generic, recurring rather than one-off (unless catastrophic), carry a real cost — in money, attention, or well-being — and can be corroborated by observation, data, or workarounds people have already built.
Adopt what exists. Adapt what almost works. Invent what’s missing.
A concept enters a design one of three ways, and knowing which you’re doing tells you how much explaining your users — and your agents — will need. In its minimal form, a concept is just a name, a purpose, and a principle: one archetypal scenario of the behavior earning its keep.
Then generalize: strip the details that came from the motivating situation. Agentic email triage, generalized, is a pattern for any queue of work — an agent proposes, a person disposes. And generalizing often reveals that one concept was two: proposing what to do with an item and drafting content are separable activities, each reusable where the other isn’t wanted.
An outline persuades. A definition predicts.
The outline — name, purpose, principle — is enough to decide whether a concept fits. To evaluate a design you need the definition, which pins down every scenario the concept allows.
Identity without structure
An individual is an entity with a persistent identity and nothing else: a person, a company, a reservation. An airline ticket is the airline’s commitment to fly you; the printout is not the ticket. Crucially, an individual carries no properties with it. If a concept knows a person’s name, some Naming activity put it there — assigned at birth, changed at marriage — and that history is a concept of its own. This is what keeps concepts truly independent.
Structure without identity
A value is nothing but its representation: numbers, strings, times, a party size. Values can be compared and combined; two pixels with the same colors are one pixel, not two. When an action takes an individual as an argument, only the identity is passed — in practice a booking number, a link, a session — never a bundle of attributes.
- Purpose
Let you reserve a resource in advance so it will be available. Prevents: wanting to use a resource and finding it unavailable.
- Principle
You reserve a resource for a particular date and time in the future, and can redeem it at that date and time and then make use of it. The use itself — being seated, getting the haircut — belongs to other concepts.
- State
The reservations that have been made, and for each its reserver, the resource reserved, the time, and the party size. Think of it as pools of individuals and facts relating them — a table where every cell is one fact.
- Actions
-
reserve (reserver, resource, time, party size): (reservation)when there is no reservation already for this resource then create a new reservation for this reserver, resource, time, and party sizecancel (reservation)when this reservation exists then remove itredeem (reservation)when this reservation exists and its time is now then remove itnoshow (reservation)when this reservation exists and its time has passed then remove it
An action can record a non-happening: noshow fires when nobody arrives, and it’s what lets the system refuse serial offenders. Note also what the inputs are not — no restaurant name, no requested time slot. Finding an available resource is another concept’s course of action; Reserving takes the resource it produced. That gap between what a user types and what an action takes is what keeps the concept independent of any interface.
Break behavior into concepts. Recombine it with rules.
You could write a whole system as one enormous course of action. Decomposing it into focused concepts pays six ways — provided you cut along real seams. Arbitrary pieces are worse than one big one.
Composition is interleaving: a trace of the whole system, filtered to one concept’s actions, is always a legal trace of that concept. Composing never corrupts the parts. But not every interleaving should be allowed — a comment shouldn’t land on a deleted post — so reactions constrain the weave. And the same fork in a design becomes a visible, one-line choice. When a post with comments is deleted, three products write three different rules:
when a delete is requested
where the requester authored the post and no comment targets it
then Posting deletes the post
when Posting deletes a post
where comments target it
then Commenting removes each one
The first product refuses the deletion while comments remain; the second cascades it; a third might keep the post and merely mark it deleted. Reactions can only cause actions, never suppress them — so an action that must be guarded is kept internal, fired only by a rule responding to a request, and declining to fire is the refusal.
Design becomes primary. Code becomes a derivative.
Agile taught us to distrust upfront design and treat code as the source of truth. With models writing the code, that inverts: the design is where human effort belongs, and code is increasingly a translation of it. The same definitions serve every role — engineers structure modules with them, product and UX express interactions in them, leaders read direction and focus from them, and sales and legal get the shortest path to what a product actually does.
Built on what worked
Relational state from databases and formal specification, actions with when/then conditions from verification, granular services from microservices, coordination-by-rules from event-driven systems. Concept design assembles proven parts — and then departs from object orientation by organizing around purposes rather than entities, so unrelated functionality is never welded to the same object.
Simplicity as a decision
A rich domain doesn’t excuse a complicated design; it makes simplicity the only sustainable option. The technique is here: break the system into parts simple enough to be obviously right. The attitude — refusing to tolerate incomplete understanding — you bring yourself.
The four movements are compressed from the group’s working guides. The tutorials teach the machinery in smaller steps, the case studies show it applied to real systems, and the book makes the whole argument.