What Does a Product Design Engagement Actually Produce?
The first question a client asks is almost always some version of “what do I get?” They are expecting a list of files. A Figma link, a prototype, maybe a component library.
That list is real, and it is also the least valuable part of the work.
What you are actually 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 happens when there is no data yet, what happens when the network drops, and which of the twelve things on the dashboard is the one people 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 at 6pm on a Friday. That is not a criticism of engineers. It is just where the decision lands when nobody else picked it up.
A product design engagement is the thing that moves those decisions earlier, into a room where they are cheap to change.
So what shows up in the folder
Here is the honest list, roughly in the order it arrives.
A map of how someone moves through the product. Not a sitemap. The actual path, including the parts where they leave. Most products have one or two places where people quietly give up, and nobody has ever drawn them.
The flows that matter, at full fidelity. Sign up, the first real use, the moment you ask for money, the moment something goes wrong. Four flows done properly beat forty screens done at 80 percent.
A prototype you can put in front of somebody. Clickable, on a phone if it is a phone product. The point is not to look impressive in a review. The point is that opinions in a meeting are cheap and watching one person fail to find the button is not.
The empty, loading and error states. These are 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 startup does not need a design system. It needs about nine components and a rule about spacing. A hundred person company needs something a new hire can read on their first day.
The part that is hard to put in a folder
The most useful thing I hand over is usually an argument. Something like: you think the problem is that people do not understand the pricing page, but they never reach the pricing page, because the third step of onboarding asks for a company size and half of them do not have a company.
That is one sentence. It is also worth more than the pricing page redesign somebody was about to commission.
This is why I do not sell hours of screen production. Screen production is the visible part, and it is the part that is easiest to buy badly.
How you know it worked
Not by whether the team likes the look. Teams like new looks. They like them for about three weeks.
Retention moves first. Then activation, meaning the share of new people who actually reach the point where the product does its job. Revenue moves last and it moves for reasons that are harder to attribute, which is why anyone promising you a revenue number from a redesign is guessing.
I ask clients to pick two numbers before we start and write them down. Not because design is a science. Because writing them down stops the conversation at the end from being about taste.
A thing worth saying out loud
Sixteen years in, the projects that went well and the projects that went badly did not differ much in the quality of the files. They differed in whether the decisions got made by someone who had seen the users, or by nobody in particular, late, under pressure.
That is the deliverable. The files are just where it is written down.