Design
Interfaces that survive
the second week of use
Most enterprise software is not ugly; it is slow to finish a task in. We design against the real workflow — the 42-field form, the 300-row grid, the operator with 90 seconds — and hand engineering components they can build without guessing.
Overview
Research, interaction design and design systems for software people use every day.
The screens that cause the most damage are rarely the ones a demo shows. They are the exception paths: the rejected invoice, the part-filled application resumed on a phone, the shift supervisor amending a batch at 03:00. We start there, because that is where staff invent spreadsheets to route around the product you already paid for.
Our work runs on the same clock as engineering, not ahead of it. Flows are prototyped in Figma, tested with eight to twelve real users, then converted into a component library with tokens, states and accessibility behaviour already specified. Developers receive Storybook entries, not a flat PNG and a hopeful note.
We measure a redesign the way you would measure a release: task completion, time on task, error rate, and the volume of support tickets that begin with the words how do I. If those numbers do not move after launch, the engagement is not finished, and that is written into the statement of work before anyone signs it.
- 4.2 min to 1.6 min
- Median time to raise a purchase requisition after redesign, Orbit Supply
- 62 components
- Shipped library covering 88 per cent of screens across three products
- 27 per cent fewer
- Support tickets tagged as usage questions in the quarter after launch, Cordage Bank
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Contextual enquiry and workflow mapping
We watch people do the job on their own kit, in their own noise. Twelve to twenty sessions produce a task inventory, a frequency-versus-pain matrix and the exception paths nobody documented.
Information architecture
Navigation, taxonomy and permissions modelled together, so that a regional manager and a plant operator each see a structure matching their mental model rather than your database schema.
Interaction design and prototyping
Clickable Figma prototypes wired to realistic data volumes. A grid demo with 12 rows hides every problem that appears at 3,000 rows, so we prototype at the size you actually run in production.
Design systems and tokens
A component library with tokens exported through Style Dictionary to web and mobile, versioned in Storybook, so a change to focus-ring contrast ships once instead of eleven times across your products.
Accessibility to WCAG 2.2 AA
Contrast, focus order, keyboard traps and screen-reader labelling handled during design, then verified with Axe and NVDA. Retrofitting accessibility after build typically costs three to five times more.
Usability testing and design QA
Moderated tests before build and a screen-by-screen review after it. Design defects are filed in your tracker using the same severity language your engineering team already argues about.
Deliverables
What you get
- Research report with task inventory, journey maps and ranked friction points
- Interactive Figma prototype covering the happy path and the top eight exception flows
- Component library with tokens, full state coverage, and dark-mode and RTL variants
- Storybook implementation of the core components, handed to your front-end team
- WCAG 2.2 AA audit with per-component remediation notes and retest evidence
- Usability findings with recorded sessions and a severity-ranked fix list
Stack
What we build it with
- Figma
- FigJam
- Storybook
- Tokens Studio
- Style Dictionary
- Radix UI
- Tailwind CSS
- Axe DevTools
- NVDA
- Maze
- Dovetail
- Optimal Workshop
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Frame
Two weeks of interviews, analytics review and support-ticket mining to agree what the redesign is for and which three metrics will be used to judge it.
Structure
Task flows, information architecture and low-fidelity wireframes, reviewed with the people who do the work every day rather than only with the sponsors.
Prototype and test
A high-fidelity prototype tested with eight to twelve participants over two rounds. Findings are ranked by frequency and severity before anything gets styled.
Systematise
Approved patterns become tokens and components in Figma and Storybook, with usage rules, states and accessibility behaviour written into every entry.
Ship and verify
We sit with engineering through build, run design QA on staging, then re-measure task time and error rate four to six weeks after the release lands.
When this is the wrong engagement
If the underlying process is broken or the data model cannot answer the question being asked, a redesign only makes the wrong answer faster to reach, and the process work has to come first.
FAQ
Questions we get asked
- Can you work within our existing brand guidelines?
Yes, and it usually improves them. Brand guidelines cover logo, colour and type; they rarely define focus states, error density or table behaviour. We extend what exists into an interface layer and flag the places where a brand colour fails contrast at small sizes.
- How many people do you test with?
Eight to twelve per round for qualitative work. Five participants find most severe issues but miss role-specific ones, which matters when an admin, an approver and a field user share the same screen. For comprehension questions needing numbers, we run 60 to 120 unmoderated sessions.
- Do you write front-end code?
We implement the component library itself in Storybook, typically React with Radix primitives and Tailwind, and hand it to your team. We do not build the application screens unless the engagement includes our front-end engineers, which is scoped and priced separately.
- What happens to the design system after handover?
We run a contribution model: your team owns the repository, we review pull requests for three months, and each component carries usage rules so additions do not fork the system. Without a named owner on your side, most design systems drift within two release cycles.