Loading
Research · Flows · Interface design · Design systems
Design that survives contact with real data, real permissions and a real browser. We work in the same repository conversation as the engineers, so what gets approved is what can be built.
The problem
A great deal of design work fails at the same point: it looks excellent in the presentation and falls apart during the build. Cards designed with three-word titles meet a product name that runs to seven. A table designed with eight rows meets four thousand and needs pagination, sorting, a filter and an empty state that nobody drew. A form designed as one clean column turns out to have twenty-three fields, half of which only appear for one user role.
The gap is not skill. It is that the design was made against imaginary content and a single happy path. Real interfaces spend most of their life in the states nobody presents: loading, empty, partial, permission-denied, too-long, error, and the awkward one where the user is halfway through something and leaves.
There is a second failure that is quieter. An interface can be attractive and still be slow to use, because it optimises for a first impression rather than for the person who is in it for six hours a day. Operational software is judged on how few keystrokes the hundredth repetition takes, and that is a different design problem from a landing page.
So we design against real content wherever it exists, specify the unglamorous states explicitly, and hand over something an engineer can build without inventing the missing half.
What is included
7 areas of work. Most engagements start with one or two and widen once the first release is in use.
Interviews with the people who will use the thing, watching them do the current task, and a review of support tickets and existing analytics. Modest in scale and specific in output: the three things that waste the most time and the assumptions that turned out to be wrong.
Navigation structure, naming that matches your users' vocabulary rather than the database schema, and flows drawn end to end including the branches for each role, the failure paths and the point where a person hands off to a colleague.
Structure and priority resolved in grey before colour is discussed, then a clickable prototype for the two or three flows that carry the product, tested with real users on a real device so the expensive questions get answered before engineering starts.
Type scale, colour with contrast checked at the token level, spacing rhythm, iconography and imagery direction. Applied consistently rather than composed per screen, which is what makes a product feel like one product rather than eleven pages.
A Figma library and a coded component set built from shared tokens, with documented usage rules and states. Sized to the product: a fifteen-screen internal tool does not need the system a public product with four squads needs.
WCAG 2.2 AA as the working standard. Contrast verified on the actual tokens, touch targets at 44px, focus visible everywhere, forms with real labels and errors that name the field, and interactions that work without a mouse or without colour as the only signal.
Moderated sessions on the flows that matter, or a heuristic audit of an existing product where the priority is finding what to fix first. Output is a ranked list with the evidence attached, not a slide deck of general observations.
How we work
Handover is a working relationship rather than a file drop. Designers and engineers share the same tokens: colour, type scale, spacing, radius and motion defined once as variables that both the Figma library and the code read from, so a change to a value does not become a hunt through screens.
Every component is specified with its states, not only its default: hover, focus visible, active, disabled, loading, error, empty and the responsive behaviour at each breakpoint. Focus order and keyboard interaction are part of the specification, because if they are not written down they will be improvised in the last week of the build.
We stay involved during implementation with design review on pull requests, which catches drift while it costs an hour rather than after launch when it costs a sprint. The final artefact is a component library that exists in both places and agrees with itself.
In practice
Handover is a working relationship rather than a file drop. Designers and engineers share the same tokens: colour, type scale, spacing, radius and motion defined once as variables that both the Figma library and the code read from, so a change to a value does not become a hunt through screens.
Where it comes up
Stack
We pick from a stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
Yes, and we deliver in a form another team can implement: a component library with documented states, tokens exported in a usable format, flows including edge cases, and a walkthrough session with the engineers who will build it. We will also review their implementation if you want that, which usually costs less than the rework it prevents.
Less than a research agency will propose and more than none. For most business software, five to eight conversations with actual users plus an hour watching them do the current task changes the design more than a large study would. The exception is a product entering a domain nobody on either side knows, where cutting research short simply moves the cost into building the wrong thing.
It depends on how much product there is and how many people are building it. A fifteen-screen internal tool needs consistent tokens and a handful of shared components, and calling that a design system oversells it. A product with several squads shipping in parallel genuinely needs the documented library, because otherwise the divergence compounds. We size it to the situation rather than defaulting to the largest version.
Yes. Most engagements start with brand assets that were made for print or for a website and do not extend cleanly into an interface, so the work is translating them into a usable product palette and type scale. Where the brand colour fails contrast requirements as text, we keep it as the brand and define an accessible variant for interface use rather than either ignoring the standard or discarding the identity.
A Figma file organised so someone can find things, a component library with states and usage notes, exported tokens, flow documentation covering edge cases, and any research findings with the raw notes attached. Everything is in your Figma organisation, not ours, which matters the day you work with somebody else.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether ui/ux & product design is even the right place to spend the budget.
What happens next
