Why Figma governance is execution partnership made visible
I sent an email a while back that was, in retrospect, the most politely urgent three sentences I’ve written in a long time. The gist: “Are the rounded corners we’ve been working on the right shape? I’m looking at the proof of concept in our component library, and I want to confirm the border-radius value matches what design intended. If it doesn’t, we need a revision path.”
Three sentences that encapsulate an entire philosophy about how design and development should work together.
At Johns & Taylor, one of our core values is Execution Partnership — the belief that great digital experiences get built when design and development work as genuine collaborators, not as sequential handoff points. And the single most important tool for making that partnership real is a shared source of truth.
On many of our projects, that source of truth lives in a collaborative design tool called Figma. Specifically, a set of golden reference boards that represent the canonical design intent for every component in the system. When a developer implements a component, they validate against these boards. When a design review happens, the boards are the benchmark. And when someone discovers a discrepancy between implementation and design — as happens on any living platform — the response isn’t to improvise. It’s to route the discrepancy back to the design team through a formal revision path.
That last part is crucial, and it’s where most organizations fall down. Having a design file isn’t the same as having a governance process. Figma files are easy to create. What’s hard is the discipline to treat them as contracts — documents that can be amended, but only through a defined process, not through ad hoc interpretation on the development side.
Here’s what this looks like in practice. A developer is building a component and notices that the Figma comp shows rounded corners on certain elements — specifically on floating elements like side recirculation cards — but sharp edges everywhere else. The developer’s instinct might be to apply rounding more broadly because it “looks better.” But the Figma comp is specific about where rounding applies and where it doesn’t. If the developer thinks the design should be different, the path isn’t to change the implementation. It’s to bring it back to the designer and ask: “Was this intentional? Should we reconsider?”
That conversation might result in a change to the design. It might result in a “yes, that’s intentional, here’s why.” Either way, the design file gets updated to reflect the decision, and the golden reference boards remain the single source of truth. No orphaned decisions living only in someone’s memory or a Slack thread from three months ago.
We require every component in our documentation framework to include visual examples showing every major variation — active states, hover states, responsive behavior at each breakpoint, edge cases with long text or missing images. These examples aren’t decorative. They’re the contract. When a developer looks at the documentation and sees that a component has four variations, they know they need to build four variations. When a QA tester checks the implementation, they have a visual benchmark that doesn’t depend on subjective judgment.
The reason I use the word “contract” deliberately is that contracts imply mutual obligation. Design has an obligation to keep the reference boards current and comprehensive. Development has an obligation to build to spec and flag discrepancies rather than interpreting around them. Product has an obligation to resolve conflicts promptly rather than letting ambiguity fester. When any party stops holding up their end, the contract breaks down and you’re back to ad hoc decision-making — which is where most design system erosion begins.
I’ve worked with teams that had beautiful Figma files and terrible execution, because nobody treated the files as authoritative. I’ve worked with teams that had minimal documentation but rock-solid execution, because everyone understood and respected the governance process. The tool matters less than the agreement. Figma is our tool, but the principle is universal: pick a source of truth, treat it as a contract, and route every discrepancy through a revision path.
Execution partnership means nobody improvises alone. The design file is where the partnership lives.
