Design to Development Handoff Checklist

Every design handoff checklist asks the same four state questions per screen. Empty, loading, error, disabled. The trouble is that error is a category rather than a state, and how many members it has is decided by your API contract. At the fictional Warminster, thirty-four screens produced 278 required states against a checklist's 136 questions. One screen could fail eleven distinct ways on its own, and a single tick cannot carry eleven different sentences.

So this pack generates the register instead of handing you one to fill in. The screen inventory is multiplied against the failures each endpoint contract already lists, the collections the data model lets a screen show empty, whether those can also be filtered to nothing, and the roles the permission model can refuse. Warminster's file covered 73 of the resulting 278 cells. Read by class that is loading 24 of 32, empty 38 of 40, error 9 of 128, and permission denied 2 of 78.

The design team had covered everything visible from inside the design and none of what the contracts enumerate, because nobody had ever shown them either. A cell counts as resolved when it is drawn, written, or deferred to a named default, and the pack ships that rule alongside the register. Deferring is a real answer rather than an escape hatch: it names the fallback the build will use, so an engineer knows the omission was a decision. It sits beside the design system's own documentation and the acceptance criteria these screens are answering to.