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.
State the purpose before the specification
Start with the user, task and expected result. That context helps engineering make sensible decisions when the implementation cannot match the artboard literally.
A short purpose statement often prevents more confusion than another measurement annotation.
Document behavior by state
List default, hover, focus, loading, empty, error, success, disabled and permission behavior where relevant. For complex components, explain the transition between those states.
Static frames should not force developers to infer product logic.
Write responsive rules in plain language
Describe what wraps, reorders, hides, becomes sticky or moves into a drawer. Explain which content is more important when the layout cannot preserve everything.
Use breakpoint examples, but do not make the rule depend entirely on one device width.
Call out content and accessibility constraints
Mention long labels, empty values, keyboard behavior, focus order, accessible names and any interaction that must not rely on hover alone.
These notes turn edge cases into shared product requirements rather than QA surprises.
End with acceptance criteria
Give QA and engineering a short list of outcomes: the action remains reachable, errors preserve input, no horizontal page overflow, focus returns after closing a modal, and the mobile target meets the agreed minimum.
Acceptance criteria make handoff testable instead of ceremonial.