UI/UX & experience design
Design that survives contact with engineering
Research, interface design and design systems built to be implemented — with the states, edge cases and accessibility already thought through.
We'll review your current product free of charge in the first session.
What experience design covers
Experience design is the work of deciding what a product should do and how it should feel to use, before anyone writes the code that makes it real. It spans research into what users actually struggle with, the flows that resolve it, the interface that expresses it, and the system that keeps it consistent as the product grows.
The failure mode we're most often called in to fix is design that was never designed to be built: beautiful screens showing only the happy path, with no empty states, no error states, no loading behaviour and no answer for what happens on a narrow screen. Engineering then invents those decisions under deadline pressure, and the product drifts from the design within a release or two.
So we design the unglamorous states as deliberately as the hero screen, and we hand over a system rather than a picture.
UX and UI are not the same purchase
Being clear about which you need saves both money and a frustrating engagement.
| UX — experience design | UI — interface design | |
|---|---|---|
| Answers | What should this do, and in what order? | What should it look and feel like? |
| Core activities | Research, journey mapping, flows, wireframes, testing | Layout, typography, colour, iconography, motion, states |
| Output | Flows, wireframes, a validated prototype, findings | High-fidelity screens, a design system, assets |
| You need it when | Users drop off and you don't know why | The product works but looks dated or inconsistent |
| Skipping it costs | Building the wrong thing beautifully | A capable product that feels untrustworthy |
Most engagements need both, weighted differently. A rebuild leans UX; a refresh of a product that already works leans UI.
What we do
Six services, bought individually or as one engagement.
User research
Interviews, usability testing and a hard look at your analytics and support tickets — usually the cheapest source of truth already sitting in your business.
Product & interface design
Flows, wireframes and high-fidelity screens covering the real states: empty, loading, error, permission-denied, and the awkward middle sizes.
Design systems
A component library with tokens, usage rules and behaviour specified — handed over in Figma and, where we're building, implemented in code to match.
Prototyping
Clickable prototypes to test a flow with real users before committing engineering budget. The cheapest place to be wrong.
Accessibility audits
WCAG 2.2 AA review with a prioritised remediation list — separated into what's a legal exposure, what's a usability problem, and what's cosmetic.
Design-to-code handover
Specs engineers can build from without guessing: spacing, breakpoints, interaction states and the rules for what happens when content is longer than the mockup.
What we mean by a design system
Four layers. A file full of components is only the third one.
Tokens
Colour, type scale, spacing, radii, shadow and motion as named values — so a rebrand is a variable change rather than a redraw.
Primitives
Buttons, inputs, selects and surfaces with every state defined: hover, focus, active, disabled, invalid, loading. Focus states included, not an afterthought.
Patterns
Composite pieces — forms, tables, navigation, empty states, dialogs — with rules for when to use each and, importantly, when not to.
Governance
How a new component gets added, who decides, and how the code and the design file stay in sync. Without this layer every design system decays within a year.
If we're also building, the system ships as real code alongside the Figma library — the two are versioned together rather than drifting apart.
Accessibility is designed in, not audited on
Cheaper, and it produces a better product for everyone.
Contrast and type at design time
Colour pairs are checked against WCAG contrast ratios as the palette is chosen, not flagged in an audit six months later when the brand is locked.
Keyboard paths
Every flow is walked with the keyboard alone. If it can't be completed without a mouse, it isn't finished.
Content structure
Heading hierarchy, labels and error messages designed as content, so screen readers get a coherent document rather than a soup of divs.
Motion and preference
Animation designed with a reduced-motion alternative, because vestibular disorders are more common than most teams assume.
How to engage us
Three shapes, depending on where you are.
Design sprint
A focused burst on one problem: research, flows, a prototype and a test with real users. Ends with a decision and evidence for it, not a deck.
Product design engagement
End-to-end design for a product or a major area of one — research through to a build-ready design system and specs.
Embedded designer
A designer working inside your team on your roadmap, monthly. Suits products shipping continuously where design can't be a project.
FAQ
Design questions
Do you design without building?
Yes. Plenty of our design work is handed to a client's in-house engineers or another agency, and we specify it accordingly — with states, breakpoints and behaviour documented so it doesn't need us to interpret it. If we are also building, the handover is tighter, but the deliverable is the same standard either way.
How is this different from the design included in a web build?
A web project includes the design needed to build that site. This practice is for when design is the engagement — research to understand a problem, a system to keep a growing product coherent, or an accessibility programme. If you just need a good-looking site built, web development covers it and costs less.
Will you work with our existing brand guidelines?
Yes, and we'll flag where they conflict with usability — most brand palettes have at least one colour pair that fails contrast at small sizes. We'll propose accessible alternatives that stay within the brand rather than quietly shipping something that fails.
What do we actually receive?
A Figma file with the screens and components, specs for the states and interactions, and a written summary of research findings and the decisions they drove. Where we build, the implemented component library too. Files are in your Figma organisation, not ours.
Can you test with real users?
Yes, and we'd push for it. Usability testing with five to eight participants surfaces the majority of serious problems and costs far less than discovering them post-launch. We can recruit participants or work with your existing customers.
Do you design for Indian users specifically?
Where it matters, yes — device mix skews to mid-range Android, screens are smaller, connections drop, and multi-script content changes how type and layout behave. We design and test on representative devices rather than a designer's laptop.
Related services
Show us what people struggle with
A link to the product and a sentence about where users get stuck is enough. We'll tell you whether it's a research problem, an interface problem, or neither.