Working with your development team
Design work for B2B software goes better when developers see it early and can question it.
Handoff works best as a series of reviews during the project.
Table of Contents
Summarize with:
Key facts
- Developers review flows before visual detail.
- The component library and its limits are agreed before design.
- States, totals and edge cases are documented alongside screens.
- The built version is compared with the design early.
- A module built from a specification that showed only screens often behaves differently in totals, nesting and line-item behaviour.
Before design
- Agree on the component library and its limits
- Review the data model for the workflows in scope
Implementation review
Review the implemented interface against the approved designs.
During design
- Review flows with developers before visual detail
- Document states, totals and edge cases alongside screens
After handoff
- Compare the built version with the design early
- Keep a list of decisions made during implementation
Design review
Review the implemented interface
At Redbrix, handoff runs through Figma Dev Mode, with design tokens for the development stack where the project uses them, and the implemented interface is reviewed against the approved design.
What goes wrong without it
| When developers see the design late | Result |
|---|---|
| Build constraints arrive in review | Designs are simplified during implementation |
| The specification shows screens only | Totals, states and edge cases are settled in code |
| Development runs in parallel with design | Details are decided in code before design decides them |
| The built version is reviewed at the end | The bug list reads like a redesign |
Common mistakes
- Handing off a finished design as a single package
- Leaving acceptance criteria out of the specification
- Reviewing the built version only before release
- Letting decisions made during implementation go unrecorded