This article is written as a working review tool rather than a universal formula. Apply the parts that match the product, evidence and constraints in front of you.
Explain the screen purpose
Give engineering the job the screen is solving, the primary user and the important action. This prevents implementation decisions from being made from visual proximity alone.
A sentence of product context can be more useful than a page of spacing measurements.
List the states that change behavior
Document loading, empty, error, success, disabled, permission and partial states. For forms, include validation timing, error placement and what data should survive a failed submission.
If the implementation needs to invent these states, the design is not finished enough to hand off.
Describe responsive rules
State what wraps, reorders, collapses, becomes a drawer or disappears as space changes. Explain the content priority behind the decision, not only the breakpoint.
This makes the rule easier to preserve when the codebase uses different layout primitives than the design file.
Call out interaction and content constraints
Document keyboard behavior, focus, modal dismissal, destructive confirmation, content limits and any values that can become unexpectedly long.
Real product content has a habit of ignoring the dimensions of the perfect mockup.
Stay available for UI QA
Review the implemented flow in the browser or app, including narrow widths and failure states. Handoff notes reduce ambiguity; they do not replace seeing the real product.
The fastest way to improve future handoff is to notice what still had to be explained during the build.