The reason your handovers hurt is because you ship prototypes instead of furniture instructions.
You might argue:
- "But there's not enough time!"
- "But that's what the design system is for!"
- "But that's what the PRD is for!"
But the only real answer is: that's what the designer is for.
Designers are idealists.
We start with the optimal path and reduce its parts until it fits within our constraints.
Ideally, we're working with:
- Plenty of bandwidth
- A well-documented design system
- Thorough product requirements
For some of us, that's a fortunate reality. But the rest of us are trying to design an airplane while in-flight and are desperately searching for parts to reduce.
Those reductions start to look like:
- No annotations
- No redlining
- No flow diagrams
And instead we try to dual-purpose our prototypes as the single source of truth.
We tighten up the Figma interactions or upload artboards to InvisionApp, and then throw it over the wall to our engineers.
Sometimes we'll add something cheeky like:
- "Just copy Feature A's styling."
- "Let me know if you have any questions!"
And then we curse our craft when the implementation falls short of the intended design.
Designers are... furniture instructors?
Your design artifact is not the product.
Your design artifact is the intent of the product. But the intent of the product only translates as well you communicate.
For example, consider the last time you constructed a piece of store-bought furniture:
- You were the product builder.
- You were provided instructions to guide your build.
- Were you a happy or frustrated product builder?
The end result, and the process to get there, is directly tied to the quality of the instructions. Our handovers are no different.
Anatomy of the Optimal Handover
Design artifacts are uniquely shaped by the tooling, processes and production line.
But whatever the shape, the Optimal Handover includes:
- Changelog
- Directory of Links
- Style Guide
- Flow Diagrams
- Component Library
- Redlining
- Annotations
1. Changelog
Keeping your eng team informed of noteworthy changes made to handover assets is critical. This document should be able to speak to changes in your absence (but you'll also want to introduce changes via Slack or a tap on the shoulder).
Use: Word/Docs, Figma/Sketch, Confluence, Notion, etc.
2. Directory of Links
Since we're not just throwing a prototype URL over the wall (right?), you'll need a jump-off point to direct engineers where to find specific assets. The reference below includes more detail than I'd recommend, but the idea is to provide the "here's what's included" of your furniture build.
Use: Word/Docs, Figma/Sketch, Confluence, Notion, etc.
3. Style Guide
If you have a Design System, this can simply exist as a link in your directory. If this is your first build, some concept of base and atomic styles (colors, type, spacing, grid) needs to be available.
Use: Figma/Sketch, InvisionApp, Zeplin, zeroheight/Storybook, etc.
3. Flow Diagrams
Every engineer in the room might have been present during weekly discussions about the macro workflow, but a birds-eye-view of the expected experience is a necessary piece of context to capture.
Use: Figma/Sketch, Whimsical, Miro, etc.
4. Component Library
The biggest "fall through the cracks" of handovers comes from misunderstood micro-interactions. For new components, especially those with high-complexity, it's imperative that you capture each micro-interaction state-by-state.
Use: Figma/Sketch
5. Redlining
One of the biggest culprits of finished products failing the eye test comes from miscommunicated box models and vertical rhythms. Redlining - the act of highlighting spatial measurements between elements - becomes less necessary with a mature design system, but is an absolute must in its absence. While tooling can automate this for engineers, I prefer manual redlining for new components.
Use: Figma/Sketch, Zeplin, InvisionApp
6. Annotations
Designers really should write more. Like, a lot more. Documenting the step-by-step workflow of your handover is one of the strongest ways to ensure accuracy of intent. Plus, annotations often evolve to become design system documentation, a nice one-two punch for you efficiency junkies.
Use: Word/Docs, Figma/Sketch, Confluence, Notion, etc.
I recognize that this anatomy skews heavily in-house and might scare those of you working in a feature factory where time is of the essence and you're losing every well-meaning battle.
But if there's one thing I want you to take away from this post, it's this:
Your prototype should not be the single source of truth.
