Design that ships, not just impresses.
Research-grounded UX and token-driven UI systems — built by designers who sit inside engineering teams, so what’s designed is what ships.
- Discover
- Structure
- System
- Embed
Every component ships with its states designed.
Enterprise software fails quietly through friction: the extra click repeated over and over, the form that loses work. Our designers work embedded with engineers — flows are validated against real constraints, and the design system is code, not a PDF.
The usual failure is not ugliness. It is a beautiful prototype that assumed six fields where the API returns forty, a table designed with eight rows that has to hold eighty thousand, and a handover document that describes an interface nobody can build in the time available. We avoid it by refusing the handover: the same people who draw the screens sit in the delivery team, review the pull requests that implement them, and design the states that only appear once real data arrives. What ships is what was designed, because design and build are one conversation rather than two departments.
Every component ships with its states designed — default, hover, focus-visible, loading, error, empty. The edge states are where trust is won.
Four things, done properly.
Research to know what to build, a system so it can be built repeatedly, accessibility decided while it is still cheap, and the craft that data-dense screens actually demand.
Research & flows
Stakeholder and user interviews, journey mapping, and prototypes tested before engineering spends a sprint on them. We watch people do the work in their own environment, with their own data and their own workarounds, because the spreadsheet beside the application is usually the most honest requirements document in the building. Findings are written down with the evidence attached, not summarised as opinion.
Design systems in code
Tokens, components and usage docs delivered as a living library — the same one engineering imports. Colour, type, spacing and elevation are defined once as tokens and consumed by both the design files and the front-end build, so a change to a token changes the product rather than starting a migration. Components are documented in Storybook with their props, states and accessibility notes.
Accessibility by design
Contrast, focus order, target sizes and screen-reader semantics decided at design time, when they’re cheap. Retrofitting accessibility into a finished interface means reopening layout, colour and markup at once; deciding it in the component means it is inherited by every screen after. We annotate designs with roles, labels and keyboard behaviour, and check the result against WCAG 2.1 AA.
Data-dense UI craft
Dashboards, tables and workflow screens — the hard, unglamorous surfaces enterprise users live in all day. Column priority, sticky context, sensible empty and truncation behaviour, bulk actions that survive a mistake, filters that persist in the URL. These screens are judged by how they feel in the eighth hour, not in the first screenshot.
How the work runs, day to day.
The design system is a package, not a picture.
A design system that lives only in a design file is a description of an interface. Ours is published as a versioned package that the application imports: tokens as CSS custom properties, components in React and TypeScript, documented in Storybook with every state visible. Brand decisions become token values, so a rebrand is a pull request rather than a project. Engineering does not translate the design; it installs it — which is why there is no handover document in the deliverables list.
- Tokens for colour, type, spacing, radius, elevation and motion, generated once and consumed by both design and code
- Components with documented props, states and accessibility behaviour, versioned and released like any other dependency
- Visual regression tests in CI so a token change cannot quietly break a screen nobody opened this sprint
The states nobody designs are the ones users meet.
Most interfaces are designed in their best hour: data present, network fast, permissions correct, nothing pending. Real users arrive on the first day with nothing to look at, on a slow connection, halfway through an approval, or without the rights to do the thing the button offers. Every component we deliver carries its full set of states, drawn and implemented: default, hover, focus-visible, active, loading, empty, partial, error, disabled and read-only. The empty state carries the next action. The error says what to do, not that something went wrong.
- Loading behaviour designed per surface — skeletons where layout is known, progress where it is not
- Empty states that teach the first action instead of apologising for the absence of data
- Error and permission states written with the words the user needs, reviewed with support and operations
Accessibility as a rule set, not a final audit.
An accessibility audit at the end of a project produces a list of defects and a difficult conversation about the budget to fix them. We move the decisions forward. Contrast ratios, focus order, target sizes, motion preferences and screen-reader semantics are properties of the component, checked automatically when it is built and annotated when it is designed. Because every screen is assembled from the same components, the product inherits the behaviour rather than re-earning it. Public-sector and regulated clients get the evidence trail that procurement asks for.
- WCAG 2.1 AA as the working standard, with the specific criteria annotated on the designs
- Automated checks in CI plus keyboard and screen-reader passes on each core flow before release
- Motion, contrast and density preferences respected as system settings, not as a separate accessible mode
Five users a round, often — not fifty users once.
Usability testing fails when it is a ceremony: a big round, a long report, and a team that has moved on by the time it lands. We run it small and often. Five participants per round, at a rhythm agreed with you, one page of findings ranked by how much time the friction costs. The prototype under test is the same component library the product is built from, so a fix is applied in the system rather than redrawn. Task times are measured before and after.
- Rounds scheduled to the delivery cadence, so findings arrive while the code is still warm
- Task-time and completion-rate baselines captured before redesign, measured again after
- Recordings and findings kept in your workspace, so the evidence outlives the engagement
What each side of the table gets out of it.
Decisions with evidence attached.
You get a flow that has been in front of real users before it is in a sprint, a written record of what was tested and what changed as a result, and a prioritisation argument based on task time and completion rate rather than on who spoke last in the meeting. Where the research says the feature is not the problem, we bring that back too — see Product Discovery for the version of this that runs before a build is funded.
- Journey maps that mark the moments where work is actually lost
- Prototypes tested with the people who do the job, not with proxies
- Findings ranked by cost in time, so the backlog can be argued with numbers
A library to install, not a file to interpret.
Designers sit in the delivery team, attend the same standup and review the implementation pull requests. Components arrive as typed packages with their states and accessibility behaviour already decided, so a screen is assembly rather than translation. Ambiguity is resolved in a short conversation instead of a comment thread on a design file, which is what keeps the design-to-implementation lag short.
- Typed components, documented props and Storybook as the shared reference
- Design review on pull requests, so drift is caught at the diff
- Tokens consumed directly by the build — no measuring pixels from a screenshot
The eighth hour, not the first screenshot.
The people who live in the product all day judge it on different things: whether keyboard flow beats the mouse, whether a filter survives a page reload, whether a mistake in a bulk action can be undone, whether the table remembers the columns they chose. We design for the operator who processes two hundred records before lunch, and we test with them rather than with a stakeholder demonstrating the happy path.
- Keyboard paths for the high-frequency flows, documented and tested
- State that persists — filters, sort, columns and drafts survive navigation and reload
- Bulk actions with a preview and a way back, because the fastest interface still needs an undo
What is in every engagement, and what is shaped per product.
Four phases, and the last one never really ends.
Discover
Users, jobs, constraints. We watch real work happen before proposing how it should. That means sitting with the people who use the current system, collecting the spreadsheets and side tools they built to survive it, and reading the support tickets — the three sources that between them describe the product as it is actually operated rather than as it was specified.
Structure
Information architecture and key flows as clickable prototypes, tested with the people who’ll use them. Navigation, terminology and the shape of the core objects are settled here, against real data volumes and the real API. It is much cheaper to discover that a screen needs a different primary object now than after a sprint has been spent building it.
System
Tokens and components built in code alongside high-fidelity screens — design and build converge instead of diverging. The library is published early, with a handful of components and the states that matter, so the first delivery sprint already assembles from it rather than waiting for a complete set.
Embed
Designers ride with delivery sprints: reviewing implementation, designing edge states, tuning from usage data. Regular test rounds continue, at a rhythm agreed with you, the library grows with the product, and your own designers pair with ours so the system has an owner on your side well before the engagement ends.
What you have at the end.
- Journey maps and validated interactive prototypes
- Token-driven component library, in code, with docs
- High-fidelity screens for every core flow, states included
- Accessibility annotations and review results
- Usability test recordings and findings
- A measured baseline — task time and completion rate before and after
- Contribution guidelines so your team can extend the system without forking it
When this is the right call.
Choose this when the product is used all day by people whose time has a price — operations consoles, back offices, dealer and partner portals, clinical or logistics workflow screens. Choose it when several teams are building surfaces that must look and behave like one product, when accessibility is a procurement requirement rather than a preference, or when a redesign has been attempted once already and did not survive contact with engineering. It also pairs naturally with a web application or MVP build, where the system is established while the first screens are being written.
It is not the right call when what you need is a brand identity or a marketing site — that is a different craft, and specialist studios do it better than an embedded product team. It is not the right call for a single screen with no reuse ahead of it; a component system earns its cost across surfaces. And if the underlying problem is that the workflow itself is wrong, design will only make the wrong process faster — start with discovery instead.
Frequently asked questions
Where this service usually sits.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it.