Design that is accountable to an outcome

Research does not have to mean a twelve-week ethnographic study. It has to mean not designing from assumption. For a marketing site the right research may be four customer interviews, a review of the sales team's most-repeated objections, and a session-recording analysis of the current site. For a plant-floor application it means standing on the plant floor, watching someone use the existing system with gloves on in poor light, and understanding why they keep a paper notebook alongside it.

We calibrate depth to consequence. Redesigning a checkout that processes ₹4 crore a year justifies a serious study. Refreshing an about page does not. What we refuse to do is skip the step entirely and then present opinions as findings.

Everything we learn goes into a short, readable insight document — usually eight to twelve pages — that becomes the shared reference for the project. It is the artefact that settles arguments later, because "the users told us" is only useful when there is a record of what they said.

Every page we design has a narrative structure before it has a layout. We storyboard the sequence a visitor moves through: the tension they arrive with, the insight that reframes it, the plan we propose, the proof that we can execute it, and the invitation to act. This is not decoration — it determines what appears at which scroll depth and what gets cut.

Storyboarding early is also the cheapest place to discover that a page has no argument. A great many websites fail not because the design is poor but because the page never makes a case; it lists features and hopes. Working the narrative out in low fidelity, with a client in the room, exposes that in an afternoon rather than in month three.

From storyboard we go to mobile-width wireframes, then to visual direction on two or three key templates. The rest of the site is composed from the resulting system, which is what keeps a sixty-page estate coherent and affordable.

A design system is not a colour palette in a Figma file. It is a set of decisions with enough rigour that a designer who joins next year, or an engineer who never spoke to the original designer, makes the same choice you would have made.

Ours are built in layers. Foundation tokens — colour, type scale, spacing, radius, shadow, motion durations — defined once and referenced everywhere, with semantic aliases so that "surface-raised" and "text-muted" mean something rather than a hex code being pasted around. Then primitives: button, field, card, tag, table, dialog, each with every state drawn and named. Then patterns: forms, empty states, data-dense layouts, pricing tables, navigation. Then page templates assembled from patterns.

Critically, the same names exist in the code. When a designer says "use the raised card with the brand accent bar", an engineer knows exactly which component that is because it is called the same thing in the repository. That single alignment eliminates most of the friction people describe as "handoff problems".

We prototype the interactions that carry risk, not the ones that are fun to animate. If a multi-step form is the crux of the product, that gets a working prototype with real validation behaviour and error handling. If a data table needs to support filtering, sorting and bulk selection on a 13-inch laptop, that gets built and tested with plausible data volumes, because tables that look elegant with six rows fall apart with six hundred.

For consumer-facing work we test prototypes with five to eight participants from the actual audience. Five is enough to find the majority of severe usability problems, and severe problems are what we are hunting. Findings come back as a ranked list with video clips attached, which is far more persuasive in a stakeholder meeting than a written summary.

Motion earns its place when it explains something: where a panel came from, that a list is being filtered rather than replaced, that a long operation is progressing, that an action succeeded. Motion that exists to be noticed is a cost — it delays interaction, it distracts, and it disproportionately affects people with vestibular sensitivities.

We specify motion as part of the system: durations on a scale, easing curves chosen for the kind of movement, and a documented rule that anything above 200 milliseconds must be interruptible. Every animation respects the reduced-motion preference, which is a two-line implementation detail that a surprising number of otherwise-good sites get wrong.

A large part of our work is not consumer-facing at all. It is a plant supervisor entering shift data at 6 AM, a dispatch clerk allocating trucks, a credit officer reviewing forty applications. These interfaces have different rules: density beats whitespace, keyboard beats mouse, the fastest path beats the prettiest one, and the screen must remain readable on a five-year-old monitor in a bright room.

We design these with the operator in the room. We time the current process, design to reduce that time, and measure again after rollout. On one dispatch system the redesign reduced average allocation time from 3 minutes 40 seconds to 1 minute 5 seconds, which across a shift is close to two hours of recovered capacity — a result no visual refresh alone would have produced.