Product & UX design
From zero-to-one flows to mature SaaS surfaces — research, prototyping and design systems that survive contact with engineering.
Product design is not the screens. The screens are what is left over after someone has decided what the product does, who it is for, and what happens when things go wrong. Most of the value is in those decisions, and most of the budget usually is not.
Who this is for
Founders at zero to one. You have a hypothesis and no product. The job is to find the smallest version that tests it honestly, and design that — not the version you will want in year three.
Teams with a product that has grown sideways. Every feature made sense when it was added, and collectively the thing has become hard to explain. New users churn in the first session. Support answers the same question all day. This is usually an information architecture problem wearing a UI costume.
Teams without a designer. Engineering has been making design decisions by default because someone has to, and it shows. We are often brought in to build the system that lets them stop doing that.
What we do
Discovery. We talk to the people who use the thing, and to the people who support them — support tickets and sales calls are the cheapest research available and almost nobody reads them systematically. We look at whatever analytics exist. Then we write down what we think the problem is, in a sentence you can disagree with. If you disagree, better now than in month three.
Flows before screens. The order things happen in, what state the system is in at each step, and what happens on the unhappy paths — the payment that half-completes, the user who abandons midway, the record that arrives malformed. Designing the happy path is the easy eighty percent that produces twenty percent of the value.
Prototypes people can use. Clickable where clickable is enough, coded where it is not. Anything involving real data, real latency or real volume gets built rather than mocked, because a prototype that is always instant and always full of perfect content teaches you the wrong lesson.
Design systems. Tokens, components, states, and the rules for combining them. Documented in Figma and mirrored in code, so the two do not drift apart the moment we leave.
Why we design and build
Design that has never met an engineer tends to contain expensive assumptions — an interaction that needs a library nobody wants to maintain, a layout that breaks at the third-longest product name, an empty state nobody specified.
Because the people designing your product sit next to the people building it, those get caught on the day rather than in a handoff document. It also means we can say “that will take three days, this will take three weeks” while the decision is still open, which changes which decision gets made.
The student dashboard for Magnus Academy is the clean example: the design question and the data question were the same question, and answering them separately would have produced a worse product.
Working with us
We are not a deck studio. You will get artefacts — flows, prototypes, a system — but the deliverable is a product that works, not a research readout. Discovery is proportionate: enough to be confident, not enough to fill a quarter.
Expect us to push on your success criteria, because that is where briefs are softest. “A better user experience” is not something anyone can be held to. “New users reach their first useful moment without contacting support” is. If you are putting a brief together, our COO wrote the guide to briefing a studio, including a template.
Expect the scope we propose to differ from the one you send. If a studio agrees with every line of your brief, they have read it as an order form.
What you get
A design system in Figma that an engineer can implement without interpreting. Flows covering the unhappy paths, not just the demo. Prototypes at whatever fidelity the question needs. And, if we are building it too, the implemented components in code with the same names as in the file — which is the only version of “single source of truth” that survives a year.
When we are the wrong choice
If you need a UI dressed onto a spec that is already fixed, you are paying for the small half of what we do. If you want a large research engagement with no build at the end, a dedicated research consultancy will go deeper than we will.
And if the honest answer is that you do not yet know what you are building, say so — that is a good place to start a conversation, not a reason to avoid one.