Insights

When to bring in a product design studio

Most teams do not need one. Here is how to tell when outside experience pays for itself, and what you should own when it ends.

Updated

Plenty of software teams ship good products with the designers they have, or with none. A studio is not a step every product needs. It earns its fee in a few specific situations, and the useful question is whether you are in one of them.

Signs it is time

  • Customers keep calling the product rough, and nobody on the team can say why.
  • Every new screen restarts the same argument, because there is no system to settle it.
  • The first version was built fast, by hand or with AI, and now a procurement team has to approve it.
  • The people who design the product are not the people who sell it, and the demo and the product tell different stories.
  • Your designers are good but stretched, and the next six months need more experience than headcount.

What experience adds to a first version

A first version answers whether the thing can work. A product customers rely on has to answer harder questions on every screen: what matters most here, what happens when there is no data, an error or four hundred rows, and whether the hundredth screen still looks like the first.

Those are judgment calls more than effort. They come from having made them before, on other products, with real users watching. That is most of what an experienced studio brings, and it is the part that is hardest to hire for one project at a time.

Experience also keeps research the right size. Sometimes the question needs six interviews. Sometimes it needs an afternoon with your support tickets. The point is to answer the decision in front of you, not to fill a template.

When your own team is enough

If you have a design team with capacity and a system they trust, keep the work in house. Bring a studio in when you lack experience rather than headcount, or when one decision is big enough that you want a practiced second opinion before you build it.

What you should own at the end

The deliverable is not a set of pictures. Before you start, ask for:

  • A design system: tokens, components and the rules that hold them together, documented well enough that an engineer can build a screen nobody drew.
  • Prototypes tested with real people, and what they taught you.
  • Front-end code, if handoff is where your quality slips.
  • The decisions written down, so the next person knows why each one was made.

A system that only works while the studio is in the room fails the first sprint after it leaves. Ask any studio how they will make sure that does not happen.

How a first engagement usually runs

Weeks rather than months. A short discovery to find what hurts, then design and prototypes for the screens that matter most, then the system and front end your engineers extend. Most product work continues after that 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.

What it costs

Our product projects start at $5,000, and the range from there is wide. A focused round on a few key screens sits near the start. A full design system with front-end code for a large product is a different order of project. Where yours lands depends on how much of the product is in scope, how much research it needs and how much of the front end you want us to build, so we quote each one after a short call.

The product and the pitch

One more reason teams bring us in: the same team that designs the product can build the interactive presentation that sells it. The demo then matches the product, and nobody has to explain the gap.

Perfect your pitch

We start by learning your business, your goals and finding the opportunities.