Pillar 04
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.
FirstUmpire designs product flows, interface states, design systems, prototypes, motion, and agent or voice interactions alongside the engineering architecture. The work covers loading, empty, error, permission, and handoff states—not only polished screens—so developers receive implementable components and behavior rules that remain consistent as the product grows.
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.
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.
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.
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.
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
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
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