The process
02 / 04
Design.
Diagnosis gives us a problem worth solving. Design decides what the solution should become before time and budget are committed to building it.
Define before building
Design is the interpretation layer between a diagnosis and a build.
I take what we learned about the work, the people doing it, the systems already in place, and the constraints around them. Then I reduce that complexity into a form you can see, understand, and challenge. A technically possible idea is not ready for construction until it also makes sense inside your business.
01 · Give the solution a shape
Give the solution a shape
Every design begins with behavior. I define what happens when a request arrives, which information is available, where human judgment belongs, what can happen automatically, what requires review, and how the system responds when information is missing, contradictory, or sensitive.
Answering those questions turns a broad recommendation into an operating concept. Depending on the engagement, I represent it through a workflow, a data map, an interface sketch, a small prototype, a technical specification, or some combination of them. The artifact changes. Its job remains the same: make the proposed solution concrete enough for you to understand how it will work.
I favor the simplest design that can solve the identified problem reliably. Simplicity here is earned through careful decisions. It means fewer unnecessary dependencies, clear paths for information, understandable controls, and a defined role for the person using the tool. It also means resisting features that sound impressive but do not help the work.
Editorial image
the proposed system made visible
Decisions before dependencies
BEHAVIOR
What the tool must do
DATA
Where information lives
REVIEW
Where judgment belongs
FAILURE
How exceptions are handled
02 · Decide while change is inexpensive
Make the important decisions before the build
I use this phase to surface the choices that affect cost, trust, and daily use. We consider where data will live, which systems need to exchange information, who should have access, how failures will be handled, and how the tool will fit the workflow your team already knows. If an AI model belongs in the solution, I define what it is responsible for and where deterministic rules or human review provide the safer answer.
Tradeoffs become visible here as well. Greater automation can require stronger safeguards. A local model can improve control while creating maintenance responsibilities. A deeper integration removes more manual work while increasing the consequences of a failure. I will explain those choices in plain language so you can decide with a clear view of what each one asks of the business.
A sketch is easy to revise. A completed integration is not.
Design is a gate between diagnosis and construction. Before I build, you should be able to look at the proposed solution and recognize both the problem and the reasoning behind its shape. You do not need to speak the language of software architecture. You do need enough clarity to say whether the design fits the operation you know.
If it does not, this is where we adjust it. We can narrow the scope, change the workflow, test another interface, replace a technical dependency, or reconsider the approach. That conversation protects your budget and improves the eventual build. Agreement at this stage matters because it rests on something visible.
The result is a shared definition of what I am building and why. Its level of detail will match the work ahead. Once you understand the proposed shape and approve the direction, construction can begin without asking code to settle decisions that belong to you.
03 · Create a usable gate
A gate you can use
Image placeholder · 02
A shared definition of the build
Replace with Garrett’s supplied system map or design artifact.
