How we think,
shown rather
than described
An inside look at how the work gets decided. 8 disciplines, 18 pieces, and the method behind each one written out in full.
What we design
- 2 pieces
Color Palettes
Whether a confirmation gets noticed by somebody who was not looking for it.
- 1 piece
Logo Design
Whether your tab is findable among the nineteen others they have open.
- 3 pieces
UI Design
Whether a first run teaches somebody what to do, or leaves them guessing.
- 2 pieces
App Design
Whether it can be finished one handed, walking, with a coffee in the other.
- 4 pieces
Pattern Design
Whether a background stays behind the words instead of competing with them.
- 2 pieces
Landing Page Design
Whether a stranger works out what this is before they decide to leave.
- 3 pieces
Dashboard Design
Whether the number is read correctly from wherever it is actually read.
- 1 piece
Typography
Whether four thousand words get finished or abandoned in the second column.
The short version
Interface work is the job, not the paint on top of it
Code decides whether a thing runs. Interface work decides whether anybody can use it. Those are two different jobs, and the second one is the one your customer actually meets.
It is measurable, which surprises people. Baymard has spent 200,000 hours watching people check out and found the average checkout asks for 11.3 pieces of information when 8 would do. Those three extra fields are not a styling problem. They are the reason a cart gets abandoned.
Why a system
What consistency actually buys you
A design system is not about everything matching. It is about deciding something once, writing it down, and never spending that decision again.
A system removes decisions. Fewer decisions means fewer chances to get it wrong. That is why the fortieth screen in a build still looks like the first.
The alternative is settling the same question on every screen, by whoever is building that screen, on the afternoon they build it. That is how a product ends up with nine button styles and four ways of showing a date. Nobody chose it. It accumulated.
So every page in this section ends at the same place: decide it once, write down why, and the thing stays coherent while it grows. That is the difference between software that was built and software that was designed.
How the work is made
Every piece is code, not a drawing
Each one is a React component rendered straight to an image. Type, color and spacing come from tokens, the same way they would in a build. A layout that works here still works when somebody has to ship it, because it already is the thing rather than a picture of it.
That rules a few things out on purpose. Nothing here is a screenshot of this site. Nothing here is generated art. Where a photograph sits inside a mockup it is a source asset, the way a stock shot would be. The piece around it is still drawn.
On a real project
Where these decisions land in a build
The order matters more than people expect. Settle the cheap things first, and the expensive things stop being arguments.
Week one, before anything is designed
We agree what the product is for and who is holding the phone. Every decision after this points back to that sentence, which is what stops a build drifting.
The system, before the screens
Color by job, type by role, spacing on one scale. Two days of work that pays for itself by about the sixth screen, because nothing is decided twice.
The hardest screen first
Not the home page. The screen with the most data, the most states, and the most ways to go wrong. If the system holds there it holds everywhere.
States, then polish
Empty, loading, error and far too much data, drawn before anything is made to look good. These are most of what people actually see, and they are usually drawn last.
Built by the people who designed it
The handoff is where most of the care leaks out. We build the software too, so there is nothing to hand off and no second team reinterpreting a drawing.
In the section
What is in here
Where to start
If one of these is close
Working on something and unsure which way to take it? Tell us which pieces you keep coming back to and we will work them up against your actual brief. Most projects start as somebody pointing at two directions. That is a good way to start.