How I work, and why. Six things, each with a reason attached.

The problem comes first, and it gets its own document

Designing against a problem nobody agreed on is the most expensive mistake available. It is also the easiest one to make, because solutions are more interesting to discuss than problems.

So every engagement starts with a brief that contains no screens, no architecture, and no charts. Only the problem, who has it, what it costs, and how we would know it was solved. It gets reviewed by the people who live with the problem before anything else begins.

Doing this properly means real analysis, and the analysis tends to turn things up. On one engagement it surfaced that staging and production were serving two different dashboards. That was a byproduct, not the goal. The goal was an executive team aligned on the problem, which is what makes the scoping and the specification that follow worth doing.

The model gets written down once

Most drift starts small. A chart computes its own version of a metric. The documentation describes last quarter's schema. Two teams use the same word for different things. Nobody decides to let a system fall out of sync. It happens between decisions.

So I work from a rulebook. The rules of a domain get written down once, in plain language the person who owns the business meaning can read, and the technical pieces are derived from that rather than maintained by hand. Consistency comes from derivation rather than discipline.

What matters here is not the method but what it changed. My responsibility used to end at design and project management, with development handed to someone else. Working this way, I can carry a project from concept through delivery.

The interface performs no business calculation

Every number on screen traces back to a declared field. A chart that computes its own version of a metric is a defect, not a shortcut.

This sounds like an engineering rule. It is really a trust rule. The moment two surfaces can disagree about the same number, every surface becomes a thing to verify rather than a thing to use.

It is faster to argue with a wrong sketch than a blank page

I build working prototypes early, with real structure and real copy, specifically so people can tell me what is wrong. A prototype is an alignment device, not a deliverable. It exists to be knocked down.

Open questions belong in the room, visible, not resolved quietly and presented as settled. If a review tells me the problem statement was materially wrong, that is the process working, not failing.

The stages are named, and each one is done when its artifact exists

A stage is complete when its artifact exists and its exit criteria are met. Not when the conversation feels finished.

1. 1Problem brief. The problem, agreed, with no solution in it.
2. 2Experience design. What it feels like to use, before what it costs to build.
3. 3Rulebook. The domain written down once, confirmed by the person who owns the meaning.
4. 4Scope and specification. Every component tied back to something named in the rulebook.
5. 5Build. Derived where it can be, written where it cannot.
6. 6Validate and hand off. Tested against the rulebook, handed to a team that owns it.

Not every engagement runs all six. Every engagement runs them in this order.

I own the decisions. The team owns the work.

I work between executives, operating partners, and delivery teams, and I take ownership of the calls I make. If I set a direction and it turns out to be wrong, that is mine to say and mine to help fix. Putting open questions in the room is not hedging. It is how you get to a decision you can stand behind.

Handing the work back is not stepping away from it. The measure of whether the work was any good is whether it still runs after I am gone. So it gets written in language the people who own it can read, and what gets handed over is whatever that team needs to carry it forward. That is a judgment call each time, not a package.