The Handoff Is A Contract
A design-to-engineering protocol built for a distributed team across 10 time zones.
GE Vernova | UX interaction designer | 2017-Present
The Problem
Handoff has a basic problem: the person who designed something and the person who has to build it rarely share the same mental model of it. Without a structured way to communicate intent – anatomy, behavior, states, variants – every handoff turns into a game of telephone. Details get lost, assumptions get made, and engineers build what they think was meant, not what was designed.
Geography made it worse. UX is based in the US; the engineering team building DEX is mostly in Bangalore, at least nine hours away. No hallway conversations, no over-the-shoulder reviews. A misunderstanding doesn't surface until the next working day at the earliest. Ambiguity isn't an inconvenience here. it's a sprint-level risk.
Component complexity made it worse again. The Data Grid alone has twelve distinct behavioral dimensions: anatomy, content, grid actions, column manipulation, filters, grouping, pagination, and more. No informal walkthrough or comment thread was going to communicate that reliably across continents.
There was also no formal acceptance step. Work could be handed off and immediately reinterpreted, with no moment where design and engineering actually agreed on what they'd agreed to.
My Role
I invented the sticker sheet format from scratch – the structure, sections, the visual language, every convention that governs how a DEX component gets documented. I refined it with the UX Director and a UX Manager from a separate GE Vernova business vertical, who helped me cut the variants section down to what engineers actually needed with the addition of a "How It Works" section. I authored 38–40 of the 44 sticker sheets myself. Other designers built the rest, but nothing shipped without my or the UX Director's review.
A blank template for sticker sheets: a change log, space for explaining the functional properties of a component, a sticker sheet of all the variants and states, and a space for illustrated specifications, which I generated with "Specs", a Figma plugin.
What I Did and Why
Built a format for how engineers actually read, not how designers explain
Every sticker sheet has three parts:
"How It Works" explains anatomy, behavior, and rules in plain language with annotated wireframes: One frame for something simple, twelve for something complex like the Data Grid or a Date and Time Picker.
A full visual inventory of every variant and state, laid out like parts in a model kit – nothing implied, nothing to guess at.
Spec output, generated by a Figma plugin instead of built by hand – no manual annotation step anymore, and no risk of it drifting out of sync with the design. That only works because the UI kit itself is pixel-perfect; the plugin reads directly from those instances, so if the kit is wrong, everything downstream is wrong too.
Working with the Bangalore team taught me that engineers can be highly literal – whatever's on the page, they build, including anything approximate or wrong. So nothing in a sticker sheet is approximate. And since color, spacing, and layout are already defined at the DEX foundation-level, sticker sheets never repeat that. They only cover what's specific to the component.
How It Works: DEX-Application Header. In this a great example of the basics: anatomy, behavior, and how it plays with other components like, DEX-Panel.
Sticker sheets include example of theme switching, states on the component-level, and how focus rings should fit around these parts of the UI.
Turned delivery into a formal, one-shot conversation
When a sticker sheet is ready, I schedule a dedicated walkthrough, usually an hour, with the Bangalore engineering team. Across a nine-hour gap, that meeting has to count; there's no dropping by someone's desk afterward. I walk through the whole document, explain the behavioral decisions, and surface technical blockers before they become implementation problems. It's part negotiation, part presentation. The predictable structure means engineers already know where to look before the meeting starts. Once both sides are satisfied, I detach the sticker sheet from live files and place it in a dedicated file for engineers: a locked, stable "snapshot" they can consult any hour without touching work that might still be in progress.
Anatomy of a component: DEX-Tree APM Analysis variant. Each sticker sheet starts by stripping back the UI to its essentials – teams focus on the total number of item slots and the required and optional items.
Closing the loop after delivery, not before it
After engineering builds a component, I review the implementation against the sticker sheet in a structured check-in, the UX Sign-Off, to confirm what got built matches what was agreed to. The contract isn't just signed, so to speak, at a UX delivery; it's honored at code completion. Because engineers read literally and often skip annotations, feedback at this stage has to be precise. I've started using Amp, GE Vernova's internal AI tool, to translate my UX feedback into language engineers respond to faster – I'm in a bit of disbelief here – it's cut the number of rounds needed to reach final approval.
Wrote the rules down so the standard holds without me
The full sticker sheet process, from opening a ticket in Aha! through delivery to the developer file, follows a decision tree I designed with design and engineering leadership, now the standard process organization-wide. I also wrote the Read Me that's the first thing any designer sees when they open the template: the intent of the system, a caution against working from in-progress files, and a ten-step process covering everything from variant selection to version archiving. One rule anchors the whole system: "It's not enough to say WHAT. You must also say WHY and provide WHERE." Developers don't just learn what a component does — they learn why it works that way and where the foundation is. The Read Me states the contract framing explicitly, too: moving a file between stages "signifies acceptance and completion of the intended deliverable" between UX, development, and management. That's not informal shorthand. It's the documented standard, applied the same way across all 44 components in the DEX library.
A decision tree tracing a sticker sheet from ticket to delivery: is the request new or a change? Are the changes simple enough to add directly, or complex enough to need a new sticker sheet? Each branch ends the same way — the file lands in the developer folder, accepted and ready to build.
Guardrails for UX designers include this Read Me file, placed next to the Figma template, that walks designers step-by-step through the process of creating sticker sheets for components and UI patterns in DEX.
The Scope
A full design-to-engineering handoff system: a pixel-perfect UI kit as the source of truth, a three-part documentation format, a formal delivery protocol with structured walkthroughs and detached delivery copies, UX Sign-Off checks against the agreed sticker sheet, AI-assisted feedback translation, and a process flowchart governing the whole thing from ticket to delivery. 44 components covered; 38–40 authored personally, all 44 approved to standard.
Where It Stands
The sticker sheet system is the active handoff protocol for DEX. Every component that goes to engineering goes through it. The format keeps evolving – the Data Grid alone has been through eight versions since its first draft, each one tracked in a change log. That's not instability. That's a living document doing its job. Every new sticker sheet can reference components and tokens that are already defined, so new ones only have to cover what's actually new. That compounding is what makes a system more than the sum of its parts.
