Product UX
Flows, states, and the unglamorous screens. Empty states, error states, the twelfth edge case — the parts that decide whether people keep using a thing after the demo.
Pillar 04
Design from the first call.
Bolting design on after the architecture is fixed is how products end up technically correct and unpleasant to use.
Every build we ship includes design thinking from day one, whether that build is a company-wide platform or a single booking agent. It is also available on its own — where you have engineers and no designer, this is usually the highest-leverage thing you can buy.
Design systems
Tokens, components, and documentation your engineers will actually use, sized to the team you have rather than the one you might have in three years.
Agent & voice personality
Designing the conversation and the character behind it: how your agent sounds, what it does while it is thinking, how it admits uncertainty, how a human takes over cleanly. Most agent products fail here rather than at the model — and the personality is yours, matched to your customers rather than to a default.
Motion
Movement that answers a question the user is already asking — where am I, what changed, what can I click. Motion that answers nothing is the first thing that reads as cheap.
Interface writing
Labels, empty states, and error messages. A button that says what happens next converts better than one that says Submit, and it costs nothing.
Why it sits at the front
The same decision costs three different amounts.
Design is not a stage that follows architecture. It is a set of decisions that get more expensive to change the later they are made — which is why they happen during Discover and Design rather than after Build.
In Discover
An afternoon
Changing the navigation model is a conversation and a redrawn diagram. Nothing has been built around it yet.
In Build
A sprint
The routing, state shape and permissions now assume it. Changing it means refactoring data flow to accommodate a menu.
After launch
A quarter
Everything above, plus migrating users who learned the old model and a backlog of bugs in places nobody associates with navigation.
It looks different per build
Designing an agent is not designing an app.
- For an agent
- Conversational flow, how it sounds, what it does while thinking, and how it admits uncertainty. Most of the design work is the escalation moment — how a human takes over without the customer starting again.
- For a CRM
- Removing data-entry friction. Every required field nobody fills is a field that corrupts the pipeline, so the design job is deciding what to stop asking for.
- For a web app
- Onboarding, empty states, and the motion that tells someone what changed. The first session decides retention, and it is almost entirely an interface problem.
The test we use
“Can a new user do the main thing without being told how?”
If the answer needs an onboarding tour, the interface is the problem and the tour is a patch over it.
Design only