Product design for teams shipping software
We design the product and the story that sells it. Most studios do one. Doing both changes the work: an interface drawn by the people who will have to explain it to a buyer tends to be one that can be explained.
The short answer
We design products for teams whose software has outgrown the version that got them here. Research, interface, design system, prototype, and the front end when the handoff is the risk.
Increasingly that version was built with AI, and it works. What it is missing is not features. It is the craft that turns a working prototype into something a customer trusts with their day.
We also run a product of our own. Bridger builds, runs and maintains Admittee, which is school facility scheduling, ticketing and payments in one calendar—so the trade-offs we recommend are ones we have had to live with on a product that has real users and a support inbox.
It works. That is not the same as finished.
A first version built with AI gets you to real users faster than any process before it, and the feedback that comes back is rarely about features. It is that the product feels unfinished in ways nobody can name precisely.
There are usually four reasons, and they are the same four every time.
- It does not look like you. The type, the spacing and the color are whatever the tool reached for, so the product reads as generic at the moment it should read as yours
- Nothing on the screen establishes what matters most, so every reader has to work it out themselves
- The empty and error states were never drawn, and a new customer meets the empty one first
- There is no system underneath, so every new screen is a fresh negotiation
None of these is a hard problem. They are the work that gets skipped when the drafting is fast, and they are what stands between a working prototype and something a customer trusts with their day. We keep what is working and do the rest beside your team, on the real thing, rather than taking it away and handing back a document.
What we do
Research, sized to the decision
Enough to answer the question in front of you, not enough to fill a template. Sometimes that is six interviews and sometimes it is reading your support tickets.
UX and UI for web and mobile
The screens, and everything around them that decides whether the screens work: hierarchy, states, transitions, the empty case, the error case, the case with four hundred rows.
Design systems your team can extend
Tokens, components and the rules that hold them together, documented so an engineer can build a screen we never drew and have it look like we did.
Prototypes real enough to test
Real enough to put in front of someone outside the building and learn something you did not already believe.
Front end when the handoff is the risk
We build it ourselves when the gap between the design and the shipped thing is where the quality has been going.
The story that sells it
The same team that designed the product builds the interactive presentation your sales team sends. The product and the pitch stop contradicting each other.
You do not always need us
If you have a design team with capacity and a system they trust, you do not need a studio. Bring one in when the constraint is judgment rather than hands.
A studio is the right call when
- The product works and customers keep describing it as rough without being able to say why
- Every new screen restarts an argument because there is no system to settle it
- You shipped fast with AI and now need the version a procurement team will approve
- The people who design it and the people who have to sell it are not the same people, and it shows
Questions we get
We built our first version with AI. Do you start over?
Almost never. The thing you shipped is the most valuable research you have, because real people have used it and told you where it hurts. We keep what is working and fix what is not, which is usually how it looks, how it reads and how it flows rather than the feature set. And we do it beside your team rather than taking the project away and handing back a document.
Do you use AI in your own work?
Throughout, and we are specific about where. It explores twenty directions in the time three used to take and it scaffolds the code underneath a build. It does not decide. It has no taste of its own and no stake in whether the work lands, so a person makes every call that matters and the work is finished by hand. If the output reads as generated, it is not done.
Have you designed an AI product, not just used AI to design?
Yes. Irvin is an AI supervisor for clinical sessions—AI product design, not AI used to design. In a product like that the design problem is trust: a clinician has to understand what the thing is doing before they will rely on it, and no amount of interface polish substitutes for that.
Can our engineers build against what you hand over?
That is the test we design for. A system that only works while we are in the room is a system that fails the first sprint after we leave, so the deliverable is tokens, components and the rules that hold them together, documented well enough that a screen we never drew still looks like ours.
Do you do product design and the sales presentation?
Yes, and it is the reason clients bring us both. One senior team designs the product and builds the interactive presentation that sells it, so the demo matches the thing and neither has to be re-explained.
What does it cost?
Engagements start at $5,000. That is our floor for any project rather than the price of a product engagement—a first one is usually a multiple of it. What you get before you commit is a fixed number, not an hourly rate that discovers itself along the way.
How long does it take?
Weeks rather than months for a first engagement, and the range depends on how much of the product is in scope. Most product work then continues as an ongoing relationship, because a design system needs maintaining as the product grows and the team that built it is cheaper to keep than to re-brief.
Product work
Before you decide
Tell us what you are building.
Send us the thing you have shipped, however rough. We will tell you what is actually in the way of it feeling finished.