Service
A brand and a product built in the same room.
UI/UX and brand work for teams who have to ship the result. Research, flows, a token set engineering builds against, and an identity that still reads correctly on the fourth screen down, where the working day is actually spent.
The Problem
Where design and product come apart.
Most design trouble on a build is not a taste problem. It is a handover problem — decisions made in a file nobody carried into the codebase, and a brand drawn before anyone knew what the screens were.
- 01
The brand was finished first
Identity signed off against a poster and a homepage mock, then handed to a product of forms, tables and error messages the palette was never tested against.
- 02
Handover by screenshot
Layouts arrive as flat frames with one happy path drawn. Engineers invent everything else on deadline, and the built product drifts from the file inside the first sprint.
- 03
A system nobody maintains
The component library exists, is out of date, and half the team designs around it. Every new screen becomes a negotiation about which version of the button is real.
The Approach
The deliverable is a system, not a file.
Design and identity run as one engagement, against the actual data, devices and people who will keep the thing alive. What we draw has to survive being built, so it gets built early.
- 01
Flows before frames
We map the decisions a person actually makes, including the ones that go wrong, before anyone picks a typeface. A wrong flow costs almost nothing to fix as a diagram.
- 02
Tokens, not swatches
Colour, type, spacing, radius and motion ship as named tokens wired into the codebase, so changing the scale moves the product rather than the presentation.
- 03
Identity proved on hard screens
Wordmark, palette and type have to hold in a dense table, a long error message and a mobile form before they earn a landing page. An identity that only works large is not finished.
Capabilities
What the work covers.
Product design and brand under one engagement, scoped to what the build needs. We would rather leave a small system that gets used than a large one that gets ignored.
-
Product UX
Information architecture, journeys, and the states that decide whether software is usable at all: empty, loading, partial, permission-denied and recovery.
-
Design systems
A component set with documented behaviour, variants and rules for when not to use something — versioned in the same repository as the code that consumes it.
-
Design tokens
One definition exported to every platform in use, so web, mobile and marketing surfaces stay in agreement as they change, themes and dark mode included.
-
Accessibility
Contrast, focus order, keyboard paths, target sizes and labelling designed in from the first frame. WCAG criteria act as a constraint on the design, not an audit bolted on at the end.
-
Brand identity
Wordmark, palette, typography, imagery direction and written voice, assembled as a working kit with usage rules — including what to do when the layout has no room for the full lockup.
-
Motion and interaction
Transitions that explain what just changed, with duration, easing and reduced-motion behaviour specified so the build does not have to guess at them.
Technologies
What we design and build with.
Tools picked so the output is consumable by engineers, not only by designers. The exact set follows the platforms you already run and who has to maintain the work afterwards.
Design and prototyping
Systems and tokens
Implementation
Testing and accessibility
How we work
How a design engagement runs.
- Step 01
Audit and interviews
We go through the current product, whatever support and sales notes exist, and the people who use it daily, then write down where it breaks. Assumptions get labelled as assumptions.
- Step 02
Structure and flows
Architecture and journeys agreed in low fidelity, with the awkward cases drawn on purpose. Nothing gets styled until the shape of the thing is settled.
- Step 03
Direction on real screens
Two or three visual directions applied to genuine screens from the flow, never to a mood board. The choice is made against the product that has to carry it.
- Step 04
System build
The chosen direction becomes tokens and components, documented with states and behaviour, then implemented in the front end by the same team, so file and product cannot quietly disagree.
- Step 05
Handover and upkeep
Engineers receive the system inside their own tooling, with the rules for extending it. We stay close through the first screens built on top, because that is when a system either takes or is abandoned.
Design it once, properly.
Tell us what you are building and who has to use it. We will say whether the work needs a full system or a smaller, sharper intervention — and which one we would do first.