UI/UX Design

UX is how it works: what the screens are, what order they come in, what happens when something fails. UI is how it looks and feels — type, colour, spacing, motion. A product can have good UI and unusable UX; that's most enterprise software. In practice the same people do both, because separating them creates a handoff nobody owns.

A Figma file with the screens, their states and the components they're built from; a clickable prototype; and the specs an engineer needs — spacing, breakpoints, behaviour. Not a slide deck. If we're building it too, the file is the working reference, not a document to interpret.

A design system is the set of components, tokens and rules that screens get assembled from, kept in one place so design and code agree. You need one once the product has more than a handful of screens, or more than one person touching it. Below that it's overhead.

It depends on how many flows, how many user roles, and whether research is part of it — a single feature is a different order from a full product. We scope after the first call and give a fixed number for a defined set of screens, so the estimate doesn't move because a flow turned out bigger.

You'll have something clickable within the first weeks — that's deliberate, so you react early. A full product design usually runs one to three months depending on the number of flows. Redesigns of an existing product are often faster, because the questions are already known.

Yes, and it's common. We design, your developers build, and we stay available during implementation to review the built screens and answer what the file doesn't cover. What changes is that we ask about your stack early, so we don't design something expensive to build in it.

Then we usually take the parts they don't have time for — a design system, an audit, a specific flow — or work alongside them on a bigger release. We don't require replacing anyone. If the existing design is good, saying so is cheaper for you than redoing it.

Both, and redesigns are more common. Those start with an audit rather than a blank canvas: what's actually broken, where users drop out, and which changes are worth the disruption. Rebuilding everything is rarely the right answer.

By making it answerable. If it's about a preference, we present options and you decide. If it's about whether something works, we test it on five people rather than argue — that's faster than a second round of opinions.

Both, in proportion to the stakes. For a familiar pattern, established practice is faster and just as good. Where the flow is specific to your business, or your users aren't like anyone else's, we talk to them first. We don't run research to justify a budget.

This is where most design projects lose value. We review the built screens against the design and fix the gap while it's cheap. When we're building it too, the gap is small — the same people made both decisions.