PROCESS

Here is How to Build

Design

Rules

The fork

An exception, once found, cannot simply sit. It has been surfaced, at the desk, by a what-if, by the early watching, and now it waits for a decision, because a found exception that is neither handled nor recorded is worse than one never found: it lives in someone's memory, half-remembered, until the day it is needed and gone. So every surfaced exception meets the same fork. Either it is scoped in, handled now, given a way forward and, where it can be, folded toward the rules, or it is parked, recorded honestly as a known exception and set down for a later design cycle. There is no third road where it is left unsorted. Sorted it must be, one way or the other.

This is the discipline that keeps a design honest. A designer under pressure to declare the work finished is tempted to treat every exception as handled, or to let the awkward ones quietly disappear. Both are lies the design will pay for. An exception treated as handled when it is not becomes a Performer stranded without warning. An exception let to disappear becomes the same, arriving one day with nothing prepared for it. The fork refuses both. It says of each exception, plainly, this one is handled now, or this one is known and waiting, and it writes the second down rather than pretending it away. A design that goes live with a short, honest list of parked exceptions is sounder than one that goes live claiming to have none, because the first knows where its edges are and the second only thinks it does.

So the fork is not a formality but a commitment. To scope in is to commit the effort now, to give this case a real way forward before the work meets it. To park is to commit to honesty now and effort later, to say this case is real, it is not yet handled, and here it is written so it is not forgotten. What the designer may not do is neither: handle nor record, decide nor defer. Every exception found is either scoped in or parked, and the choice between them is the work of this discipline.

The highest possible standard is to bring every surfaced exception to a decision, scoped in now or parked honestly for later, and never to leave one unsorted, half-remembered, or quietly wished away, so the design always knows which of its edges are handled and which are still open.

Key Takeaway: An exception, once found, cannot sit unsorted; a found exception neither handled nor recorded is worse than one never found, because it is half-remembered until the day it is needed and gone. So every surfaced exception meets one fork: scoped in, handled now and folded toward the rules where it can be, or parked, recorded honestly as a known exception for a later cycle. This keeps the design honest: a design that goes live with a short, honest list of parked exceptions is sounder than one claiming to have none, because it knows where its edges are.

Every surfaced exception is either scoped in now or parked honestly for later; it is never left unsorted.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 3: Scope In or Park · Section: The fork

MarvinPro | June 2026

marvinpro.com

Low effort or high effort

What decides which way an exception goes is the effort to handle it, weighed against how often and how urgently it arrives. An exception is low effort to scope in when handling it is mostly a matter of rewriting the manuals, with little stakeholder or partner alignment needed, the designer can do it largely at the desk, without rounds of consultation. It is high effort when its handling needs real development work, or wide alignment across many stakeholders and partners, the kind of thing that takes time and cannot be done alone.

This is about the effort to handle the case, not the size of the case itself, and the two are easily confused. An expensive refund may be low effort to scope in, if all it needs is a line in a guide that says where such a refund is approved. A small, cheap matter may be high effort, if handling it means aligning three teams and an outside partner on who does what. The money at stake in the case tells you how much care the handling deserves; it does not tell you how hard the handling is to design. So the designer judges the effort, the writing, the alignment, the development, and not the value of the case, when deciding how quickly it can be scoped in.

From this the rule of triage follows. When an exception is low effort to scope in, scope it in at once, however rarely the case occurs, because parking a quick fix costs more than the fix. To set a small manual change onto a backlog, to be revisited in some later cycle, is to spend more managing the item than handling would have taken, and to leave the executing team without support in the meantime, where an avoidable issue can grow while a one-line answer waits. Low effort means do it now. When an exception is high effort, frequency decides. A high-effort case that is frequent, urgent, or harmful earns the effort and is scoped in now, its cost justified by how often or how badly it bites. A high-effort case that is only occasional may not yet be worth designing a solution for, and can wait for the next design cycle, because building handling for what rarely happens spends effort the design does not yet owe. And readiness gates all of it: even a worthy exception waits if the team is not ready to take on its handling, since scoping it in before they can perform it would strand them anyway.

The highest possible standard is to judge each exception by the effort to handle it, not the size of the case, scoping in at once whatever is low effort however rare, scoping in the high-effort cases that are frequent or urgent, deferring the high-effort cases that are only occasional, and never scoping in faster than the team is ready to perform.

Key Takeaway: What decides the fork is the effort to handle the exception, weighed against frequency and urgency. Low effort means mostly a manual rewrite with little alignment; high effort means real development or wide stakeholder and partner alignment. This is effort to handle, not size of case: an expensive refund may be low effort (a line in a guide), a small matter high effort (many parties to align). So: low effort, scope in at once however rare, because parking a quick fix costs more than the fix; high effort, let frequency decide, frequent or urgent now, occasional deferred; and readiness gates it, never scope in faster than the team can perform.

Judge by the effort to handle, not the size of the case: do the low-effort now however rare, and let frequency decide the high-effort.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 3: Scope In or Park · Section: Low effort or high effort

MarvinPro | June 2026

marvinpro.com

Park honestly

To park an exception is not to fail at it. It is to make a deliberate choice: this case is real, it is high effort and only occasional, so its full handling will be designed in a later cycle, not this one. Parking is how a designer manages finite time without lying about it. The alternative, forcing every exception into the current design whatever the cost, would either delay the whole work or handle the rare cases so hastily that the handling is poor. Deferring the occasional, high-effort case to its proper time is not neglect; it is the honest economy of a designer who knows that not every edge earns attention at once.

But parking carries two duties, and without them it becomes mere abandonment. The first is to record. A parked exception is written down, plainly, as a known open case, so it is not forgotten and can be picked up in the next cycle. A recorded gap is a gap the design knows it has, and a known gap is safe in a way a hidden one never is: it can be watched, planned for, and closed in turn. An exception parked in memory alone is not parked; it is lost. The second duty is to leave a way through in the meantime, for a parked case has no bespoke handling yet, but it can still occur before the next cycle designs one, and no Performer may be stranded by it. So the parked case is covered, and its cover improves in stages. From the first, the standing escalation path holds: a case with no handling of its own is escalated for a decision. That path is shorter and more direct in the brief hypercare period just after go-live, when the designer is still close, and longer once the process has settled, running through several levels before it reaches the designer at the top, most cases resolved well below. Then, as soon as a work-around is found, a temporary, good-enough way through, the parked case gets it, and the Performer follows the work-around directly instead of escalating each time. And when the case is at last scoped in, the work-around does not linger: it transitions into, or is replaced by, the new rule or steps. Escalation, then work-around, then designed handling, each stage handing cleanly to the next, so the Performer always has a way forward while the design catches up. The escalation path and its levels are taken up in their own discipline; here it is enough that the parked case is never left with nothing.

And the parked list is not a graveyard. It is a live account of the design's open edges, revisited each cycle, worked down as the high-effort cases earn their handling and the recurring ones are folded into the rules. It should shrink, not grow. A list that only lengthens is a sign that scope-in is being avoided, that cases which could be handled are being parked to seem productive. Parking is for the genuinely high-effort and occasional, not a place to put work one would rather not do. The tending of that list over time, its review and working-down, is its own concern, taken up beyond this volume; what matters here is that when a designer parks, they record it honestly, they cover it until its turn, and they mean to return.

The highest possible standard is to park only the high-effort, occasional cases, to record each one plainly as a known open gap, to cover it in stages until its handling is built, escalation, then a work-around, then the new rule or steps, and to treat the parked list as a live account to be worked down, never a graveyard to be forgotten.

Key Takeaway: Parking is not failure but a deliberate choice, to design a high-effort, occasional case in a later cycle, the honest economy of finite time. It carries two duties: record the exception plainly as a known open gap, since a known gap is safe where a hidden one is not, and cover it until its turn. The cover improves in stages: the standing escalation path first (shorter in the brief hypercare period, longer and multi-level once settled), then a work-around as soon as one exists, then the new rule or steps, which the work-around transitions into or is replaced by when the case is scoped in. The list is live, worked down, never a graveyard or a place to put work one would rather not do.

Park only the high-effort and occasional, record it as a known gap, cover it by escalation then work-around until the rule or steps replace it.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 3: Scope In or Park · Section: Park honestly

MarvinPro | June 2026

marvinpro.com

A real example

Return to the software company, the what-ifs and the early cases now in hand, each waiting at the fork. The opted-out customer came first. It was low effort: handling it meant a line in a guide, when a customer has asked not to be contacted, suppress the message and proceed, with no partner to align and no development to do. Though such customers were not common, it was scoped in at once, because parking so small a change would have cost more to track than to make, and would have left Support without an answer for a case that could arrive any day. Low effort, done now.

The unknown issue came next, and it too was scoped in, but for a different reason. Its handling, the escalation path and the shaped updates, was higher effort, touching the Technical Team and the Owner and the way the work was routed. But it was both frequent enough and harmful enough to earn that effort: an unknown issue stranded the Performer completely, with nothing to send and no one to turn to, and unknown issues would keep coming. High effort, but frequent and harmful, so scoped in now. Then the client whose administrator wanted every message routed through them. This was high effort, it meant aligning with the Back Office on a per-client channel and building a way to hold that preference, and it was only occasional, few clients asked for it. So it was parked, honestly: written down as a known open case, marked for the next design cycle. It was not left uncovered. Had such a client appeared before then, the Performer would have escalated, and in the early days that path was short, the designer close at hand during hypercare. Soon a work-around was found, a note the Back Office kept and followed by hand, and the Performer used that directly rather than escalating each time. When the next cycle finally built the per-client channel, that work-around was replaced by the new steps, and the exception was an exception no longer.

So the design went live with most cases handled and a short, honest list of one or two parked. Nothing was left unsorted, nothing was pretended away, and nothing rare and costly was forced in before its time. The low-effort fix was made at once to support the team; the frequent, harmful case earned its higher effort; the rare, costly one waited its turn, recorded and covered, escalation giving way to a work-around and the work-around in time to the built handling. That is the fork worked well: not every exception handled at once, but every exception decided, covered, and honest.

The low-effort fix was made at once, the frequent harm earned its effort, and the rare and costly was parked, covered, and handled in its turn.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 3: Scope In or Park · A real example

MarvinPro | June 2026

marvinpro.com

Scope In or Park

An exception, once found, cannot sit unsorted, because a found exception neither handled nor recorded is worse than one never found: it is half-remembered until the day it is needed and gone. So every surfaced exception meets one fork: it is scoped in, handled now and folded toward the rules where it can be, or it is parked, recorded honestly as a known exception for a later cycle. There is no third road. This is what keeps a design honest, for a design that goes live with a short, honest list of parked exceptions is sounder than one that claims to have none, since it knows where its edges are.

What decides the fork is the effort to handle the exception, weighed against how often and how urgently it arrives. An exception is low effort to scope in when handling it is mostly rewriting the manuals, with little alignment needed; high effort when it needs real development or wide alignment across stakeholders and partners. This is the effort to handle, not the size of the case: an expensive refund may be low effort if it needs only a line in a guide, while a small matter may be high effort if it needs many parties to agree. So the low-effort case is scoped in at once, however rare, because parking a quick fix costs more than the fix and leaves the team unsupported. The high-effort case is judged by frequency: frequent, urgent, or harmful, it earns the effort and is scoped in now; only occasional, it may wait for the next design cycle. And readiness gates all of it, for scoping in faster than the team can perform would strand them anyway.

To park is not to fail. It is to defer a high-effort, occasional case to its proper cycle, the honest economy of finite time. But parking carries two duties. The first is to record, plainly, as a known open gap, because a known gap is safe where a hidden one is not. The second is to cover the case until its turn, in stages: the standing escalation path first, shorter and more direct in the brief hypercare period when the designer is close, longer and multi-level once the process has settled; then a work-around, as soon as one is found, which the Performer follows directly instead of escalating each time; then the new rule or steps, which the work-around transitions into or is replaced by when the case is scoped in. So a parked case is never left with nothing; the Performer always has a way forward while the design catches up. And the parked list is live, not a graveyard, worked down each cycle as cases earn their handling and recurring ones are folded into the rules, never a place to put work one would rather not do.

So the discipline is this: bring every surfaced exception to the fork, and decide. Scope in the low-effort at once, however rare, to support the team. Scope in the high-effort that is frequent, urgent, or harmful. Park the high-effort that is only occasional, honestly, recorded and covered until its turn. Never leave one unsorted, never pretend one away, and never force the rare and costly in before its time. A design that does this knows itself: it can name every edge it has closed and every one still open, and it strands no Performer at any of them.

Every exception is decided at the fork, scoped in now or parked honestly and covered until its turn, so the design strands no Performer and knows its every edge.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 3: Scope In or Park · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.