PROCESS

Here is How to Build

Design

Principles

Where design begins

You have seen the process as it really is. You read the documents and the signed-off material, you compared them to the work, you mapped the as-is and aligned it with the people who hold it. Seeing is done. Now you design, and design begins with one question: what must the new process do?

This is where requirements come in, and the first discipline of design is to separate the must-haves from the nice-to-haves. A must-have is something the design fails without. A nice-to-have is something the design would be better for, but could live without. They are not the same, and treating them as if they were is how designs become bloated, late, or impossible. Everything wanted is not everything required. So you take the true picture you built in seeing, and the discrepancies it surfaced, and from them you draw the list of what the process must achieve, and separately the list of what it would be good for it to achieve. The first list is the design. The second list is where you improve it if you can.

The reason this matters so much is that a design is a set of choices under constraint. You never have unlimited time, money, or room to build everything. So you must know, before you start, which things you cannot give up and which things you can trade. The must-haves are fixed points the design has to hit. The nice-to-haves are the give in the system, the things you keep if they are cheap and drop if they are costly. A designer who has not separated the two has no way to make the hard choices that designing always requires, because they cannot tell what is load-bearing from what is decoration.

This separation is also what you carry into every conversation that follows. When you align the design, when you meet pushback, when you negotiate, you are trading nice-to-haves and defending must-haves. If you have not sorted them in advance, you will give away something load-bearing under pressure, or fight to the death over something you could have let go. Knowing which is which is what lets you bend without breaking.

The highest possible standard is to draw the requirements from the true picture you saw, and to separate clearly what the process must do from what it would merely be good for it to do, before you design a single thing.

Key Takeaway: Design begins with requirements, drawn from the true picture seeing produced. The first discipline is to separate the must-haves, which the design fails without, from the nice-to-haves, which it could live without. This separation is what lets you make the hard choices design requires, and what lets you trade and defend wisely when the design meets pressure.

Everything wanted is not everything required. Know which is which before you build.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Where design begins

MarvinPro | June 2026

marvinpro.com

Design for the future, not only the present

The requirements in front of you are the ones you need today. But a process designed only for today is a process you will be redesigning tomorrow. So before you design, you look ahead, and you ask what is coming.

There are future requirements just as there are present ones, future must-haves and future nice-to-haves. Some you can see clearly: a volume that is going to grow, a market that is going to be added, a rule that is going to change, a system that is going to be replaced. Others you can only sense as likely. The discipline is to bring the foreseeable future into view while you design, instead of designing as if today's conditions will hold forever. They will not. The process you build today will live into a future that is already partly visible, and designing blind to it builds in rework you can see coming.

This is not a call to design for every imaginable future. That way lies a process so general it does nothing well. It is a call to know the future you can reasonably foresee, and to hold it in mind as you shape the present design, so that the choices you make today do not quietly close doors you know you will need open. A design that is right for today and impossible to extend tomorrow is not a good design. It is a bill you have deferred.

So you design with two horizons in view at once. The present requirements tell you what the process must do now. The future requirements tell you what it must not prevent later. The first shapes what you build. The second shapes how you build it, so that what comes next can be added without tearing down what you made.

The highest possible standard is to bring the foreseeable future into the design, knowing the future must-haves and nice-to-haves you can reasonably see, so that today's design does not close the doors tomorrow will need open.

Key Takeaway: A process designed only for today is one you will redesign tomorrow. Look ahead to the future requirements you can reasonably foresee, the coming volumes, markets, rules and systems, and hold them in view as you design, so today's choices do not close doors you know you will need. Design with two horizons: what the process must do now, and what it must not prevent later.

A design that is right for today and impossible to extend tomorrow is a bill you have deferred.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Design for the future, not only the present

MarvinPro | June 2026

marvinpro.com

Build in the future where it is cheap

Knowing the future is one thing. Deciding how much of it to build in now is another, and that decision is governed by economics.

Here is the useful truth: a great deal of future-proofing is nearly free if you do it while you are designing anyway. When you are already shaping the process, leaving room for a coming market, or building a step so it can handle more volume, or choosing a structure that can extend, often costs little or nothing extra in the moment. The cost of building it in now is small because you are already there, with the design open in front of you. The cost of adding it later, after the process is built and running, is large, because you have to reopen, rework, and re-test something that was finished. So where future-proofing is cheap now and expensive later, you build it in. That is simply good economics.

But not all future-proofing is cheap. Some of it costs real money now, or needs resources you do not have, or adds complexity that slows the present design. Here the discipline is different: you weigh it. You do not build in the future by reflex, because reflexive future-proofing produces bloated, expensive designs that carry the weight of futures that may never arrive. You make the economic judgement: what does building this in cost now, what does it save later, how likely is the future it serves, and do you have the resources. Where the sum is favourable, you build it in. Where it is not, you leave the door open if you can, and you let the future pay for itself when it comes.

So future-proofing is not a virtue to maximise. It is a cost to manage. Take the future-proofing that is nearly free, because not taking it is waste. Weigh the future-proofing that is costly, because taking it blindly is also waste. The skill is telling the two apart, and spending on the future only where the economics earn it.

The highest possible standard is to build in the future-proofing that is cheap now and costly later without hesitation, and to weigh the future-proofing that is expensive against its cost, its likelihood and your resources, rather than building for the future by reflex.

Key Takeaway: How much of the future to build in is an economic decision. Future-proofing that is nearly free while you are designing anyway, and expensive to add later, you build in. Future-proofing that costs real money, resources or complexity now, you weigh against its likelihood and value rather than adding by reflex. Take the cheap future, judge the costly future, and spend only where the economics earn it.

Future-proofing is not a virtue to maximise. It is a cost to manage.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Build in the future where it is cheap

MarvinPro | June 2026

marvinpro.com

Scope to the level, then check it holds

A process can be designed at different depths. You can describe it in broad strokes, or you can specify every action in detail. The discipline is to choose the right depth for the thing you are designing, and to check the design holds at that depth before you go further down.

This is what process levels are for. A design can sit at L1 (Process Level 1), the highest and broadest view, or descend to L2 (Process Level 2), or to L3 (Process Level 3), where it becomes detailed and specific. The right level is set by complexity. A simple process does not need to be driven down to fine detail; designing it at a high level is enough, and detailing it further only adds effort without adding clarity. A complex process needs to go deeper, because the difficulty lives in the detail, and a high-level design would hide exactly the parts that matter. So you match the depth of the design to the complexity of the process, neither over-specifying the simple nor under-specifying the complex.

But here is the move that saves the most pain: before you drive a design down into detail, you check that it holds at the level you have scoped. It is far cheaper to find a flaw in the shape of a process while it is still a high-level design than after you have specified every step. So you cross-check the design at its level first. Does the overall shape work? Do the major pieces connect? Does it meet the must-haves at this level of view? Only when the shape holds do you descend into the detail, because detailing a design that does not hold is building carefully on a cracked foundation. You will only have to tear it up and start again.

This order, scope the level, check it holds, then detail, is what stops you from doing expensive, detailed work on a design that was never going to work. The check at the higher level is quick and cheap. The rework avoided by doing it is slow and expensive. So you validate the shape before you commit to the detail, every time.

The highest possible standard is to scope the design to the level its complexity requires, and to cross-check that it holds at that level before you drive it down into detail, so you never specify carefully a design whose shape does not work.

Key Takeaway: Match the depth of the design to the complexity of the process, scoping it to L1, L2 or L3 rather than over-specifying the simple or under-specifying the complex. Then cross-check that the design holds at that level before descending into detail, because finding a flaw in the shape is cheap and finding it after full specification is expensive. Validate the shape, then commit to the detail.

Detailing a design that does not hold is building carefully on a cracked foundation.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Scope to the level, then check it holds

MarvinPro | June 2026

marvinpro.com

Design across the partner boundary

Many processes do not run inside one organisation. They cross a boundary into a partner, a provider, an outside party who does part of the work. When they do, the design cannot stop at your edge. It has to cross the boundary too.

This means the partner is not someone you design for, but someone you design with. They have requirements of their own, must-haves and nice-to-haves, shaped by their systems, their staffing, their constraints, just as you have yours. A design that meets your requirements and ignores theirs will fail at the boundary, because the part of the process they run will not fit the part you run. So you consult the partner as you design, you learn their requirements, and you shape a design that works for both sides, not one side handing the other a finished plan to absorb.

The boundary itself is where the real design work concentrates, and the two things to get right there are integration and duplication. Integration means the two sides join cleanly: the output of your part is exactly the input the partner's part needs, and the same in return, the handoffs across the boundary working as well as the handoffs inside your own walls. Duplication is the waste that hides at every boundary: work done on your side that is then done again on theirs, a check both sides perform, a record both sides keep, a step that exists twice because each side built it without seeing the other. Designing across the boundary means finding that duplication and removing it, on either side, so the joined process does each thing once. The boundary is where processes are most wasteful, because no one owns both sides, so it is where the most can be saved by someone who designs across it.

So a design that crosses into a partner is a design of two halves made to work as one. You gather their requirements alongside yours, you make the integration at the boundary as clean as the integration within, and you cut the work that both sides were doing twice. Done well, the partner boundary stops being the weakest seam in the process and becomes just another join.

The highest possible standard is to design across the partner boundary with the partner, gathering their requirements alongside yours, making the integration at the boundary clean, and removing the duplication on either side so the joined process does each thing once.

Key Takeaway: When a process crosses into a partner, design with them, not for them, because they have their own requirements shaped by their systems and constraints. Concentrate on the boundary, where integration must be as clean as it is inside your own walls, and where duplication hides, work done on both sides that should be done once. Designing across the boundary turns the weakest seam into just another join.

The boundary is where processes are most wasteful, because no one owns both sides. So it is where the most can be saved.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Design across the partner boundary

MarvinPro | June 2026

marvinpro.com

Getting the design accepted

A design on paper changes nothing. It has to be accepted by the people it affects before it can become real, and those people do not always agree. So the last discipline of design is the hardest, because it is not about the process at all. It is about people.

It begins with pushback, and the first thing to do with pushback is to judge it. Is it valid? Sometimes it is. Someone raises an objection that is right, that points to a real constraint or a real requirement you did not consider. When the pushback is valid, you adopt it. You change the design, regardless of who raised it, because a valid objection is a gift, it has caught something the design was missing, and a designer too proud to take it will ship a worse design to protect their ego. Adopting valid pushback, even when it is inconvenient, even when it comes from someone junior, is not weakness. It is the design getting better.

But sometimes the pushback is not valid, and then you have to bring people along, and this is where the real work lies. Your first tool is to convince, to win the argument on its merits. And convincing is the tool you reach for at every level, not only where you must. With a peer or someone senior to you, you have no authority over them, so persuasion is your only option: they do not have to agree, and you cannot make them. But even with someone below you, where you could simply decide, convincing is usually the wiser move. Authority is not free to spend. Overrule someone and they can escalate above you, and you have only so many escalations before your judgement itself starts to be questioned, and then everything you do becomes slower and more contested. So you persuade where you could command, because command spends a credibility you will need again, and persuasion builds the trust that makes the next design easier.

If convincing does not carry it, you negotiate. Sometimes the merits alone will not move someone, and you find a settlement instead, giving a nice-to-have to secure a must-have, accepting a smaller version now, getting even the raw idea signed off so it can proceed. A design agreed in part and moving beats a perfect design that is stuck. And if negotiation fails too, and the matter is large enough to justify it, you escalate, taking it up to a higher level to get the decision you could not get at your own. But escalation is the last resort, used sparingly, because it spends your own standing and strains the relationships you went around. You climb to it only when everything below has failed and the project is too important to leave stuck.

Underneath all of this is the thing that makes any of it work: relationships and trust, built over time. People adopt your valid points, accept your arguments, and negotiate in good faith because they trust you, and that trust is not made in the moment of disagreement. It is made earlier, including back when you went to see the work and arrived to understand rather than to judge. The connections you built then are the capital you spend now. This is why the whole of design rests on something that started two disciplines ago: you cannot get a design accepted on its merits alone, you get it accepted on its merits and the trust you have earned, and the trust takes longer to build than any design takes to draw.

The highest possible standard is to judge pushback honestly and adopt what is valid from anyone, to convince rather than command at every level because authority is finite, to negotiate when convincing stalls, to escalate only as a last resort on what is large enough to justify it, and to build the relationships and trust that make all of it possible long before you need them.

Key Takeaway: A design must be accepted by the people it affects, and acceptance is a discipline of its own. Judge pushback and adopt what is valid, from anyone. Where it is not valid, convince, at every level, because authority is finite and command invites escalation that spends your credibility. If convincing stalls, negotiate to get even the raw idea signed off; if that fails and the matter is large enough, escalate as a last resort. All of it rests on relationships and trust built long before, including in the seeing that earned them.

You get a design accepted on its merits and the trust you have earned. The trust takes longer to build than the design takes to draw.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Section: Getting the design accepted

MarvinPro | June 2026

marvinpro.com

A real example

A process leader designed a change to save cost, part of the end-to-end process the leader owned. It was the leader's first large design, and no one had asked for it. The leader saw the saving, and proposed it.

The design routed a particular kind of customer directly to the partner who would serve them. To the leader, and to almost everyone consulted, this looked like a gain on two fronts at once. It removed cost, and it improved the experience, because that kind of customer had to be transferred to the partner anyway, and the design simply removed the transfer. Every stakeholder agreed, with one exception. The most senior person involved, well above the leader, did not see it that way. Where the others saw the customer experience improved, this person saw a risk to it. It was a genuine difference of judgement, looking at the same change and reaching the opposite conclusion about what it would do to the customer.

The design was shelved. Not because it was wrong, and not because the leader had failed to make the case, but because the one person who saw it differently held the most authority, and authority is not a vote. Broad agreement among the others did not outweigh a single senior judgement, and the leader could neither convince that person nor overrule them. The design, sound and complete, went onto the shelf.

Several months later, an organisational change shifted the pressures, and the calculation changed. The saving that had not been worth the perceived risk before was now wanted, and wanted urgently. The design came off the shelf needing to be live almost immediately. It was never altered. What had changed was not the design but the conditions around it, and the window that had been closed was now open. Implementation was substantial, drawing on the partner's staffing and systems and on third-party systems, and it took four months, made possible because the partner was willing to do it under the existing contract. After those four months, it was implemented, and it worked.

The argument over the customer experience was never settled on its merits. The leader never won it, and never needed to. The design waited, complete, until the conditions weighted its trade-offs differently, and then it was simply there, ready, because it had been designed well and kept whole.

A good design that is shelved is not a design that is lost. It is a design that is waiting for its window.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · A real example

MarvinPro | June 2026

marvinpro.com

Design

Design is the discipline of shaping the process on purpose, and it begins where seeing ends. From the true picture you saw, you draw the requirements, separating the must-haves, which the design fails without, from the nice-to-haves, which it could live without. That separation is the ground of every choice that follows, because design is always a set of choices under constraint, and you cannot choose well until you know what is load-bearing and what is not.

You design with the future in view, not only the present, because a process built for today alone is one you will rebuild tomorrow. You bring the foreseeable future into the design, and then you let economics decide how much of it to build in now: the future-proofing that is nearly free while you are designing anyway you build in, and the future-proofing that is costly you weigh against its likelihood and your resources, rather than building for the future by reflex. You scope the design to the level its complexity requires, L1, L2 or L3, and you check that it holds at that level before you drive it into detail, because a flaw in the shape is cheap to find early and expensive to find late. And where the process crosses into a partner, you design with them and not for them, making the integration at the boundary clean and removing the duplication on either side, so the joined process does each thing once.

Then comes the hardest part, which is not about the process but about people. A design must be accepted to become real. You judge pushback and adopt what is valid from anyone, because a valid objection makes the design better. Where it is not valid, you convince rather than command, at every level, because authority is finite and spending it invites the escalation that erodes your credibility. Where convincing stalls you negotiate, and only as a true last resort, on what is large enough to justify it, do you escalate. And all of it rests on relationships and trust that were built long before the disagreement, including in the seeing that earned them. You get a design accepted on its merits and the trust you have earned, and sometimes, as the shelved design that waited shows, you do not win the argument at all, you simply design well, keep the work whole, and let the window open.

You can now design a process on purpose. You draw requirements from the true picture and separate must-haves from nice-to-haves, you design for the foreseeable future and let economics govern how much to build in, you scope to the right level and check the shape holds before detailing, you design across partner boundaries to integrate and remove duplication, and you get the design accepted by judging pushback, adopting the valid, convincing rather than commanding, negotiating, and escalating only as a last resort, all on a foundation of relationships and trust. You have seen the process, and now you have designed it. Next, it must be agreed by the people it affects before it can run.

You cannot run what has not been agreed. Design it well, get it accepted honestly, and it is ready to be signed.

MarvinPro · PROCESS · Here is How to Build · Design · Principles · Discipline 3: Design · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.