How the work happens

The three stages

Understand

Before anything is designed, I want to know who the work is for and what they are trying to do. That usually means a conversation, some reading, and looking at what already exists: the current site, the spreadsheet, the process, the support tickets.

The output is a written summary of what I understand: the problem, the people involved, the constraints, and what a good outcome would look like. It is deliberately simple to argue with, because arguing with it early is cheap.

Make

Then the work starts. The guiding rule is to build the smallest version that genuinely solves the problem, and to put the care into the details that people actually notice: the words, the states nobody thought about, the loading, the empty case.

You see work as it takes shape, not only at the end. A design that looks right on a screen can still be wrong in use, and the only way to find that out is to react to it while it can still change.

Learn

After launch, the interesting part starts. The work tells you things no plan could have: which pages people read, which questions they still have, which steps they work around.

That learning goes back into the work. Some of it is a small fix, some of it is a bigger structural change, and some of it is a decision to stop doing something that was never worth doing.

What I need from you

Four things, none of which is a formal brief:

• The problem, in your words. What is hard, what is slow, what confuses people, or what you wish existed.
• Who it affects. The people who will use it, and the people who will decide whether it worked.
• Access to reality. The current site, the data, the process, and ideally the people doing the work today.
• Honesty about constraints. Budget, deadlines, approvals, and the parts you already know are difficult.

What you do not need: a feature list, a wireframe, a brand guide, or a decided answer about which technology to use. Those are outputs of the work, and choosing them early usually narrows the solution before the problem is understood.

What you can expect

• Plain language. No jargon used to sound impressive, and an explanation when a technical decision actually matters.
• Written summaries. Decisions and progress in writing, so nothing depends on remembering a call.
• Honest estimates. If something is going to take longer than I first thought, you hear it early rather than at the end.
• One point of contact. You work with me, not with a layer of account management.
• Work you own. Files, code, accounts, and documentation are yours, and I explain how they work.
• No lock-in. Where a third-party platform does the work, the alternative is documented so leaving stays a choice.

What this is not

It is worth being clear about the edges.

• It is not a fixed process with named phases. It is a rhythm that adapts to the project.
• It is not a guarantee of results. I can promise careful work and honest measurement, not a particular number.
• It is not a subscription relationship by default. Some work continues because it is useful, not because of an agreement.
• It is not a place for work that nobody has decided is worth doing yet.

Questions about the approach

Read every question