UX Glossary | P
Prototype specification
Also: Prototype annotation, Redline
Notes beside a prototype recording sizes, spacing, click effects and element states so developers can build it as designed.
A prototype specification is the layer of written detail that sits beside a prototype and says exactly how it should be built. Sizes and spacing, colours, what happens on click, hover or error, how an element looks when disabled or loading. The older name “redline” comes from drawing red measurement lines over a static design.
What it is for
A prototype shows what the product does but not always how precisely. A developer looking at a clickable file can see that a card expands, not whether it takes 150 milliseconds or 400, which easing it uses, or what the layout does at a narrower width. The specification is the hand-off that closes that gap and prevents a week of “that is not quite what I designed” in review.
Less is more, if you have a system
If the product has a design system, most of this should not be written out at all. Spacing and colour come from design tokens, and a component already has documented states. Specify only what departs from the system. Redlining every margin on a screen built from standard components is effort spent restating what the code already knows.
What goes wrong
Specifications drift. The design changes, the annotations do not, and the developer builds from the stale note. Keep them attached to the design file rather than in a separate document, and record the behaviour that is easy to forget: empty, loading, error and long-text cases. Those are the states that usually reach users unplanned.