The handoff is the interface around the prototype

For years, I treated a prototype link like a finished object. I would send the URL in a team chat with a few paragraphs of context and some version of: lmk what you think. The person on the other end would click around for a few minutes, maybe send back a nice work!, maybe ask one polite question, maybe say nothing at all. Then the prototype would slowly disappear.

I thought the problem was the message. Maybe I needed a better headline. Maybe I needed to explain the flow more clearly. Maybe I needed to ask a sharper question. Really, I was handing someone a doorway and calling it a house.

A prototype URL gets someone into the work. It does not tell them what they are looking at, how it relates to their world, where it would live in their workflow, what parts are real, what parts are provisional, or what kind of feedback would actually help. A prototype without a handoff is a suitcase left on someone's porch. They can open it. They can see what is inside. But they do not know what trip it was packed for.

The handoff is the interface around the prototype.

I now think about prototype handoffs as having four surfaces: the message, the schema, the integration map, and the living workspace. Each one answers a different question. Each one prevents a different kind of silence.

The message is the part most designers already do. It matters, but it cannot carry the whole handoff by itself. A good handoff message has five jobs:

The right link. Not the root URL. Not the homepage. The specific starting state you want them to see first. If the prototype supports query parameters, use them. Set the persona, the demo state, the starting view. Do not make the recipient assemble the scene before they can understand the play.

The words that might trip them. Three lines of glossary. Not the whole product dictionary. Just the terms that do not mean exactly what they sound like. This prevents the recipient from spending the first five minutes wondering whether they are missing something obvious.

The demo rules. How to reset it. What personas exist. Which one to try first. What is safe to break. People are oddly polite inside prototypes. Tell them where they have permission to be messy.

The view they will not find on their own. The toggle two clicks deep. The state that makes the whole thing make sense. The little corner of the product that shows the actual idea. Point them there.

The one question you want answered. "Any feedback welcome" sounds generous, but it makes the recipient do strategy work before they can respond. Ask one question, and make it small enough that the answer can fit in one sentence.

The message gets them through the front door. It does not tell them how the house is wired.

The hardest thing for a stakeholder to do with a prototype is figure out how the objects in the prototype relate to the objects in their actual life. The prototype is full of nouns: requests, queues, reviewers, statuses, versions, comments, templates, rules. Whatever they are. The stakeholder is also full of nouns: the artifacts their team already uses, the tools they already maintain, the meetings they already run, the spreadsheets they already quietly depend on.

The handoff needs to show how the prototype's nouns map onto the recipient's nouns.

I now include a one-page schema with every serious prototype handoff. It lists the core objects in the product, their fields, their relationships, and the nearest equivalent in the world the recipient already lives in.

For example, in a generic intake workflow:

A request is the item someone submits because they need action from another team. You might call this a ticket, intake item, submission, case, or ask.

A queue is the organized list of requests waiting for attention. You might call this an inbox, backlog, triage list, worklist, or pipeline.

A decision note is the short record of why something moved forward, changed, or stopped. You might call this a comment, rationale, review note, approval note, or summary.

The schema lets the recipient stop translating in their head and start evaluating the product. Without it, the first part of the demo is spent decoding vocabulary. With it, they can spend that time deciding whether the model is right.

The schema also produces the best feedback.

When someone says, "I don't think of it that way. For us, a request is not owned by one person. It moves between teams," I have learned more in one sentence than I would have learned from an hour of polite clicking.

The UI shows whether the experience is legible. The schema shows whether the mental model is true, which is usually the deeper question.

The second-hardest thing for a stakeholder to do with a prototype is figure out where it would go. No product enters an empty room. It enters a room already crowded with team chat, ticket trackers, shared docs, design files, project plans, email threads, spreadsheets, rituals, habits, permissions, workarounds, and people who are tired of adopting new tools.

Throughout the demo, the recipient is quietly asking: Where does this fit? What does it replace? What does it sit beside? What happens to the tools we already use? How much behavior change are you asking for? If the handoff does not answer those questions, the recipient will answer them alone. Usually badly.

They may decide the product is a chat replacement when it is not. Or a ticketing replacement when it is not. Or another destination their team has to remember to visit, when the real idea is to feed the places they already work. The wrong assumption made privately is much harder to correct than the right framing offered early.

So I include a simple integration map: what they already use, what stays the same, and where this fits.

Team communication stays. Important activity from this product can post into the channel, thread, or inbox where the team already works. We do not replace communication. We make the useful parts easier to surface.

The delivery system stays. Work items can link back to the system the team already uses to manage delivery. We do not replace the tracker. We add context around it.

The documentation space stays. Summaries, decisions, or handoff notes can move into the place where the team already keeps durable context. We do not replace docs. We make the boring parts easier to maintain.

The integration map does a job no demo can do. It positions the prototype inside the stakeholder's existing world before they have to invent that placement themselves. It also reveals what they actually care about.

A stakeholder may nod politely through the product tour, then light up at one line in the integration map: "Wait, could this fit into the review process we already run every week?"

That kind of side comment often tells you where the product wants to attach.

The most underrated part of the handoff is the part that lives after the conversation. A prototype that changes daily needs somewhere the recipient can find the current truth. Not just the current URL. The current truth.

What does the product do this week? What changed since the last version? Which parts are real? Which parts are fake? Which flows are ready for critique? Which flows are there only to make the demo coherent? What is the team working on next?

I now give serious prototypes a workspace outside the prototype itself. It has a simple structure: Start here. Prototype link and demo instructions. Schema. Integration map. Glossary. Design critique log. Evaluation results. Known gaps. Open questions. Changelog.

The workspace needs to be returnable.

A lot of product work is easy to visit once and hard to find again. The chat thread disappears. The URL changes. The prototype gets updated. The notes live in someone else's doc. The feedback is scattered across a meeting recording, a DM, and a comment no one can find.

The workspace is the prototype's memory. It is also the prototype's query surface.

The workspace should be structured so someone can search it, skim it, feed it into their own AI tools, or ask questions against it without needing me in the room. Context only helps if people can use it.

A PM should be able to ask the handoff: What changed since the last version? Which flows are ready for customer feedback? What decisions are still unresolved? What assumptions does this prototype depend on? Where does this diverge from what we learned in research?

An engineer should be able to ask: What are the core objects and relationships? Which states are fake demo states versus intended product behavior? What edge cases have already been identified? Which parts of the prototype imply new data requirements? What implementation questions should we answer before building?

The alternative is hidden labor. Without a structured handoff, the next person has to click through every page, infer the product model, reconstruct the edge cases, guess which flows are real, and translate all of that into tickets, acceptance criteria, technical questions, implementation notes, or customer-facing explanations. That is too much parsing, and intent gets lost there.

The workspace gives the work a stable place to accumulate context. The recipient can come back weeks later and understand what changed without asking me to re-explain the whole thing.

The best version of this is partly automated. A script or workflow pulls the latest docs into the workspace on a schedule, so the workspace is never very stale. The recipient does not have to ask, "Is this current?" The answer is yes by construction.

This piece can feel least like design work because it looks like documentation, operations, or process. But the workspace determines whether the prototype has an afterlife.

Without one, the prototype gets a few days of attention and then falls out of orbit. With one, it stays available. It can be re-entered, forwarded, challenged, queried, compared, and improved.

The prototype becomes less like a performance and more like a place.

AI makes this kind of handoff more important. When prototypes were slower to make, the artifact itself carried more proof of effort. If someone received a detailed prototype, they could assume a meaningful amount of thinking had already happened around it. That assumption is weaker now.

AI-assisted tools can produce convincing screens quickly. They can generate flows, copy, components, dashboards, empty states, sample data, and code. Useful, and risky, because a prototype can look more resolved than it is. The interface can become fluent before the thinking is finished.

A handoff is how you prevent that fluency from becoming false confidence. The schema says: here is the model underneath the screens. The integration map says: here is where this would live in the real workflow. The workspace says: here is what is real, what is provisional, what changed, and what still needs to be tested. The message says: here is the exact conversation we need this artifact to produce.

In an AI-assisted workflow, the handoff becomes a calibration layer. It helps humans understand what the prototype means. It also gives PMs and engineers something structured enough to use inside their own AI tools.

They should not have to manually parse each page of the prototype before they can do useful work with it. They should not have to reverse-engineer the product model from screens. They should be able to connect the handoff docs to the tools they already use for planning, implementation, research synthesis, critique, writing, or technical review.

A strong handoff turns the prototype from something someone has to inspect into something they can work with. It also gives AI tools the context they need.

If a coding agent, writing assistant, research synthesizer, or evaluation workflow is going to operate around the product, it needs more than screens. It needs names, relationships, constraints, integration assumptions, open questions, known gaps, source links, and a current version of the truth.

Otherwise the agent is just as likely as the stakeholder to misunderstand the object. It may generate copy for the wrong user posture. It may treat a fake demo state as production logic. It may preserve a concept that was supposed to be challenged. It may confidently extend a data model no one has agreed is correct.

A prototype is visual. A handoff makes it legible. A queryable handoff makes it usable by the whole team, including the AI tools now sitting inside their workflows.

If the only artifact is a prototype link, the next person has to become the parser. If the handoff includes the model, the assumptions, the open questions, and the current truth, the next person can spend less time reverse-engineering the work and more time improving it.

The faster prototypes get, the more the handoff has to slow the right things down. Not the making. The meaning.

Each part of the handoff does a different job. The message gets the recipient oriented. The schema maps the product to their world. The integration map shows where it fits. The workspace gives them somewhere to return.

None of these parts substitute for the others. A great message with no schema produces a recipient who can open the prototype but not evaluate the model. A great schema with no integration map produces a recipient who understands the product but cannot see how to adopt it. A great integration map with no workspace produces a recipient who agrees in the moment and forgets by next Tuesday. A great workspace with no clear message produces a beautiful pile of context no one knows how to enter.

When all four surfaces are in place, the quality of feedback changes.

People stop saying "nice work" and start saying useful things.

They send annotated screenshots. They forward the prototype to colleagues. They challenge the object model. They ask whether a specific integration is possible. They point to the part of the schema that does not match their world. They tell you which workflow would make adoption easier.

They can also query the handoff instead of asking me to re-narrate it. That changes the shape of collaboration. The prototype is no longer a fragile artifact that only makes sense when the designer is in the room. It becomes a shared object with enough context around it for other people, and their tools, to participate.

The prototype starts producing the conversation it was built to produce.

Handing off a prototype is a UX problem. The recipient is a user. The handoff is their experience. The prototype is only one surface in that experience.

The message is onboarding. The schema is the data dictionary. The integration map is positioning. The workspace is the home screen they come back to. And the workspace is the layer their AI tools can query when they need to understand what the prototype means.

This is more work than designers are usually taught to do because it crosses into territory that looks like product management, engineering, documentation, and operations. It crosses on purpose.

A prototype handoff fails because the surfaces around the prototype were missing. The person receiving it could not tell what mattered, how to evaluate it, where it fit, what changed, or what to do next.

A handoff should make the work usable, durable, queryable, and integrated into the recipient's existing world.

A prototype that disappears into team chat gets dropped at the door, never opened.

Build the interface around the prototype. Most of the value is in the parts that do not look like design.