What if the design doesn’t fit our timeline or budget?

Then it isn’t finished. Cutting scope early is cheaper than having it cut later by whoever is closest to the deadline, and it’s a decision you get to make instead of inherit. That includes telling you when something is better bought than built, and when a proposal is larger than the problem needs.

Can you design it if someone else is building it?

Yes. Some clients bring us for the design phases and build with their own engineers, and it’s a normal way to work with us. What changes is the handover: instead of a specification your team has to re-derive, you get components and states defined where your engineers can pick them up.

We already have a brand. Do you work inside it?

Yes, and it’s the only way we work. We don’t take on brand or identity projects on their own. This work starts from an identity that already exists and a product that already has users, where the job is structure, hierarchy and clarity rather than a new visual language.

Do you do accessibility audits on their own?

Yes. TGI Fridays engaged one as its own piece of work, separate from a redesign. An audit tells you what to fix and in what order; it doesn’t fix it, and the two are usually worth scoping separately.

What if the research says we shouldn’t build it?

Then that’s the finding, and it’s the cheapest one you’ll ever get. mEMR tested a product concept before development rather than after, which is the point of doing it in that order.

Design | Onetree

What we do

Six shapes this work usually takes. Most projects are several of them.

Research with the people involved
Interviews and workflow analysis with the roles that will use it, and with the ones who decide what it has to do.
Prototypes that test a concept
High-fidelity enough to put in front of someone and learn whether it holds, before it becomes a build.
Product and interface design
Navigation, structure and visual system for the thing itself, screen by screen and state by state.
Design in the codebase
Screens and components built in the repository your engineers work in, with every state defined instead of described.
Accessibility work
Audits against WCAG, and interfaces designed for it from the first sprint rather than corrected afterwards.
Design systems
Component libraries built in code, so what was designed is what ships and keeps shipping.

When design happens

Three moments, and the work is different in each one. The question worth settling early is which of them you’re in.

Before the build
Finding out whether it should exist
mEMR came to us with a physician-led product concept. We ran the research and built high-fidelity prototypes to test it before a line of code was written, clarifying the clinical and patient workflows the product depended on.
It’s a smaller engagement than a build, and the right one when the workflows aren’t settled yet.
During the build
Making a complicated model usable
Teach to One Roadmap adapts to each student’s path through K-12 maths. The model had grown stronger and the experience hadn’t kept up: navigation wasn’t obvious, options had multiplied, and students and teachers couldn’t always tell what to work on next or why. We redesigned the navigation, the visual system and the way progress is shown.
The pedagogy didn’t change. What changed is that you can see it.
After it ships
Keeping it consistent as it grows
VisualVault’s platform serves education, healthcare and public sector clients from one component library built in code. Design decisions survive because they live where the product is built, not in a file beside it.
Governed and documented in Storybook, alongside the team shipping the product.

We design in the code

The design team works in the codebase the engineers will build on, with AI tools doing the typing. What developers receive isn’t a file to interpret: it’s the thing itself, in the repository, with the components already named. That changes five things.

There’s no translation step to lose things in
The gap between what was designed and what shipped is where products quietly lose their shape: a spacing rule dropped here, a state improvised there, a component forked because the original didn’t quite fit. Working in the code closes that gap instead of policing it. The design lead decides which components are canonical and approves each screen before it goes to construction.
States, not screens
A screen is a happy path. A product is also empty, loading, in error, without permission and offline. We design that matrix from the start, because in code the missing state isn’t an omission you discover in QA. It’s a branch somebody has to write anyway, and it’s cheaper to decide it than to inherit it.
Interface text is part of the design
A result still processing. A prescription that expired. A value the system hasn’t published yet. In products that carry consequential information, those sentences decide whether someone understands their situation, so they’re written with the screen and not added to it afterwards.
We know what it costs before you commit to it
An estimate from outside a codebase is a guess. From inside one it isn’t. When a screen turns out to be expensive to build, that’s known while it’s still a decision, not after it’s approved and sitting in a sprint.
And when your team builds it
Some clients bring us for the design phases and build with their own engineers. The output is the same kind of thing: components and states defined where your team can pick them up, rather than a specification they have to re-derive.

Designing when a rule decides part of it

Accessibility, clinical compliance and role-based access aren’t finishing steps. They change what the interface can be, so they arrive at the start.

An interface someone uses while they’re unwell
The University of Michigan’s clinical pharmacy department needed to measure gait, balance and finger coordination in patients on chemotherapy. The app had to be accessible and legible to someone tired, uncomfortable and unsupervised, and the readings had to come out in a form a clinician could act on.
Designed for accessibility from the first sprint, on iOS with Apple ResearchKit and Medable.
Auditing what already shipped
For TGI Fridays we ran an accessibility audit across the ordering and corporate platforms, while the same architecture had to host several virtual brands and ghost kitchens under one identity. An audit tells you what to fix and in what order. Fixing it is a separate piece of work.
Commissioned as its own engagement, not as part of a redesign.
When different roles see different things
At the IDB, each role has its own view of the same loan data. That was decided with the stakeholders before the indicators were designed, because reversing it afterwards means redesigning them.
Stakeholder interviews and workflow analysis first, then iterative validation as it was built.

Questions we get before the first call

What if the design doesn’t fit our timeline or budget?
Then it isn’t finished. Cutting scope early is cheaper than having it cut later by whoever is closest to the deadline, and it’s a decision you get to make instead of inherit. That includes telling you when something is better bought than built, and when a proposal is larger than the problem needs.
Can you design it if someone else is building it?
Yes. Some clients bring us for the design phases and build with their own engineers, and it’s a normal way to work with us. What changes is the handover: instead of a specification your team has to re-derive, you get components and states defined where your engineers can pick them up.
We already have a brand. Do you work inside it?
Yes, and it’s the only way we work. We don’t take on brand or identity projects on their own. This work starts from an identity that already exists and a product that already has users, where the job is structure, hierarchy and clarity rather than a new visual language.
Do you do accessibility audits on their own?
Yes. TGI Fridays engaged one as its own piece of work, separate from a redesign. An audit tells you what to fix and in what order; it doesn’t fix it, and the two are usually worth scoping separately.
What if the research says we shouldn’t build it?
Then that’s the finding, and it’s the cheapest one you’ll ever get. mEMR tested a product concept before development rather than after, which is the point of doing it in that order.

Research, product design, and code written into your repo.

What we do

Research with the people involved

Prototypes that test a concept

Product and interface design

Design in the codebase

Accessibility work

Design systems

When design happens

Finding out whether it should exist

Making a complicated model usable

Keeping it consistent as it grows

We design in the code

There’s no translation step to lose things in

States, not screens

Interface text is part of the design

We know what it costs before you commit to it

And when your team builds it

Designing when a rule decides part of it

An interface someone uses while they’re unwell

Auditing what already shipped

When different roles see different things