A design ticket that engineers don't trust slows down delivery, generates back-and-forth, and erodes the relationship between design and engineering. A design ticket that engineers do trust gets built correctly the first time. The difference usually comes down to a handful of consistent habits.

Start with intent, not appearance

Engineers need to understand what the component or flow is trying to achieve before they can make good implementation decisions. A ticket that starts with 'the button should be blue and 16px' gives engineers no room to make intelligent trade-offs. A ticket that starts with 'users need to be able to confirm their selection before data is committed' gives engineers context to catch edge cases you didn't anticipate.

State all the states

The most common source of rework is undocumented states. Default, hover, active, focus, disabled, loading, empty, error — each interactive element has multiple states and engineers will ask about every one of them. Spec them all in the ticket, with design references for each. If you haven't designed a state, name that explicitly rather than leaving it to the engineer to invent.

Include the edge cases you know about

What happens when the list is empty? What happens when the title is 200 characters long? What happens when the user has no permissions for this action? If you've thought about these while designing, write them down. Engineers find out about edge cases during implementation and need to make a call quickly — a note in the ticket that says 'if the user has no permissions, show the disabled state with tooltip X' saves a Slack thread and a delay.

Link to the source of truth

A design ticket should have one clear link to the definitive Figma frame or component. Not a screenshot. Not a PDF. A link to the live Figma file with a note about which frame is the final version. If there are multiple explorations in the file, mark the approved direction clearly — engineers should never have to guess which version to build.

Define done

Every design ticket should include acceptance criteria — a short list of conditions that, when met, mean the ticket is complete. 'The component matches the Figma spec' is not an acceptance criterion. 'The modal closes when the user clicks outside it, presses Escape, or clicks the close button, and focus returns to the triggering element' is an acceptance criterion. Specific, testable, unambiguous.

The meta-habit

The most trusted design tickets come from designers who ask engineers what they need before they write them. Spend ten minutes with an engineer at the start of a new project type and ask: 'What information would make this easiest for you to build?' The answer varies by team, codebase, and individual. The question alone builds trust.