01 · How we work
Most products do not need a designer. They need a design layer.
We have walked into products where slides went straight from the founder to the development team, and the interface showed it. A design layer is not a person who makes things pretty later. It is the step where somebody decides what the screen is for before anyone builds it.
“I won’t act as a User Interface designer. I’ll serve as a product designer aiming to reduce churn.”
That sentence is in every product proposal we send, and it is the whole philosophy: a beautiful screen that people abandon is a failed screen. Or, as we put it less formally in one audit email: make it stupidly easy to use, then make it pretty.
How we open every product engagement
Three phases, in an order most people get backwards.
Months 1 to 2
01Usability
Audit every screen, report weekly. The early findings are always unglamorous and structural: how a table lays out, how you add and edit a record. Fix those and half the complaints disappear.
Month 3
02Brand
Colour, typography, button language, the emotional register. Deliberately second, so the personality lands on a product that already works rather than decorating one that does not.
Months 4 to 7
03Interface
The screens themselves, plus a component set your developers keep using long after we hand a screen over. The set outlives the engagement. That is the point of it.
02 · Where we start
The first screen you redesign decides how the rest is received.
We start with the ugliest thing in the product, on the CRM that was the “New Task” pop-up, because a visible win buys patience for the slower structural work behind it.
Then the header, and that is the strategic one. It appears on every screen, it depends on nothing else, and changing it early makes existing users part of the change rather than victims of it. Start anywhere else and the new work looks bolted onto an old product for months, which is exactly how redesigns lose the room.
Surfaces we take on
One screen at a time, against a live release schedule. From the CRM, in the order we shipped them.
- 01 Global search across contacts, opportunities, quotes and orders
- 02 List view with filters, column editing and bulk actions
- 03 Detail view, its tab system and left sidebar
- 04 Activities: task, call, event and email forms
- 05 Opportunities, including a board view and a stage progress bar
- 06 Settings and field organisation
- 07 Notifications and in-app messaging
- 08 Login, web and mobile, plus app store assets
- 09 Charts and the reporting screen
- 10 The AI panel and the global controls beside it
- 11 Email builder for the campaign module
- 12 Breadcrumb and collapsible sidebar, also built in HTML and CSS
03 · The rules underneath
Nobody asks for the rules. Nothing survives without them.
Screens are the visible output. What decides whether a product still looks like itself in two years is the set of rules underneath, written down and handed to your engineers as variables, not as pictures. Three of ours, and why each exists.
Spacing scale, actual size
Five values, no others. Written the day a single screen drifted: spacing gets a standard the same way font size and colour do, and it ships as variables so consistency is not a matter of memory.
Status colour, fixed meaning
Three states, three colours, never reused for anything decorative. Specified in HSL so every tint and shade stays on the same hue.
Weight, and why 660
Bold was shouting inside a dense interface. Dropping to 660 keeps the emphasis and loses the heaviness. Second-level navigation is not bold at all.
Alongside those: an 8px corner radius on every button with defined hover states in both directions, one shadow value for elevation, a namespaced token set, Inter as the interface face, and a heading convention that separates the HTML level from the visual style, so a heading can be an h2 for structure while wearing h3’s type.
The reason we push this is not tidiness. Without written standards, dozens of near-identical styles appear, and the developer is left guessing which one is correct.
04 · Working with your team
We design it. Your engineers ship it.
On product work we are usually not the development team, and that changes what a deliverable has to be. A picture of a screen is not a spec. Behaviour is.
Our side
- ›Audit, flows and screen design in the shared Figma file
- ›Interaction specs written as behaviour, not as pictures: what happens when the panel is too narrow, when the list is empty, when the arrow has nothing left to scroll to
- ›Feedback itemised and tracked on a shared board, never buried in a thread
- ›Review of each beta before it ships, and sign-off
Your side
- ›Implementation inside the product
- ›Release planning, including design freezes we respect
- ›The estimate. We ask for one on late changes so a design opinion always carries its real cost, on one release that was two days to build and half a day to recheck
- ›The invitation to test the beta before it goes out
The last line is the one we work towards. When a team stops shipping a release until the designer has looked at it, the design layer is real.
05 · How we take feedback
Two messages that show how the work actually moves.
“I like it mostly. I would like to see a more defined card.”
Then: “The card still does not pop out.” Then: “If you can’t see the cards clearly defined, it defeats the purpose of having cards.” Three rounds on one component in a single afternoon, and he was right every time. We do not defend a draft. If a card does not read as a card, it is not finished, however many hours are in it.
“Why don’t we have a global search in the CRM?”
Our own message, unprompted: to find a company you had to open contacts, search, then click through to detail. Nobody had asked us to fix it. On a standing engagement the highest-value work is almost always the thing nobody put on the list, noticing it is the job.
06 · What we will not claim
We will not sell you a churn number.
Product screens live behind a login, so this page describes them rather than displaying them. And although this work was sold on reducing churn, we have no churn figure to put here, because measuring it was never handed to us. We would rather say that than imply otherwise.
When a design studio quotes you a churn improvement, ask who measured it and against what baseline. We would rather show you the spacing scale.
