What Actually Gets Delivered When You Outsource Product Design

The most common question I get while a quote is being considered is some version of this. What exactly gets delivered?

I can answer with a list of files. A Figma link, a prototype, a component library. It is also the part that is easiest to write into an internal approval document.

Honestly, it is the least valuable part.

What you are buying is a set of decisions

By the time a product ships, somebody has decided who it is for, what it does first, what it refuses to do, what appears on screen when there is no data yet, what happens when the connection drops, and which of the twelve things on the dashboard is the one people actually came for.

Those decisions get made whether or not anyone is paid to make them. If no designer is in the room, they get made by whoever is closest to the code on Friday evening. That is not a criticism of engineers. It is simply where a decision lands when nobody else picked it up.

Commissioning product design is the act of moving those decisions earlier, to a point where changing them is still cheap.

What is in the folder

In roughly the order it arrives.

A map of how someone moves through the product. Not a sitemap. The real path, including the places where people leave. Almost every product has one or two points where users quietly give up, and usually nobody has ever drawn them.

The flows that matter, done properly. Sign up, the first real use, the moment you ask for money, and the moment something fails. Four flows built well beats forty screens built at 80 percent.

A prototype you can put in front of a person. On a phone if it is a phone product. The point is not to look good in an internal review. Opinions in a meeting room are cheap. Watching one person fail to find the button is not.

Empty, loading and error states. The screens that get skipped and then improvised in code. They are also the screens people see on their worst day with your product.

A system sized to the company. A five person company does not need a design system. It needs nine components and one rule about spacing. A hundred person company needs something a new hire can read on day one.

The part that is hard to put in a document

The most useful deliverable is usually a single observation.

Something like: you believe the problem is that the pricing page is confusing, but almost nobody reaches the pricing page, because step three of onboarding asks for company size and half of your signups do not have a company.

That is one sentence. It is worth more than the pricing page redesign that was about to be commissioned.

Where this bites in Japan specifically

Working with Japanese companies, the recurring constraint is that internal approval requires the deliverable to be defined before the budget is released. So requirements get fixed first, and design is placed afterwards as a decoration step.

That is the wrong order, and the cost of the wrong order usually arrives late in development, invoiced under the name of specification changes.

There is a practical compromise. Make the first two to four weeks a separate, small engagement called a diagnosis. The amount is small enough to approve easily, and the map and the observations that come out of it become the substance of the larger approval request. You keep the process and still move the decisions forward.

How you know it worked

Not by whether the team likes the look. Teams like new looks, reliably, for about three weeks.

Retention moves first. Then activation, meaning the share of new users who actually reach the point where the product does what it promises. Revenue moves last, and attribution is genuinely hard. Anyone promising you a revenue percentage from a redesign is guessing.

So I ask for two numbers, written down before we start. Not because design is a science, but because it stops the conversation at the end from being about taste.

Sixteen years in, what separated the projects that went well from the ones that did not was never the quality of the files. It was whether the decisions were made early by someone who had watched users, or late and under pressure by nobody in particular.

That is the deliverable. The files are just where it is written down.