Spec Anatomy

Spec anatomy is the consistent seven-section structure that turns a loose document into something both humans and AI can reliably build from. The order matters. Intent first explains why the feature exists. Scope draws hard boundaries. Behavior walks through the user journey. The rest follows logically down to concrete copy strings and aria labels. This template emerged from watching hundreds of fast-shipping teams in 2025 and 2026.

It is not a random list of headings. It is not optional. Teams that drop sections produce specs that create rework. The most common mistake is treating edge cases as an afterthought instead of the unglamorous but critical section four that prevents production fires.

Many confuse spec anatomy with rigid bureaucracy. It is the opposite. The structure frees you from reinventing format every time so you can focus on content. It also creates predictability across the organization. Every engineer knows exactly where to find success criteria.

Concrete example. The annotated mini-spec for save-to-collection follows the anatomy perfectly. Its intent paragraph is three tight sentences about bookmarking and churn. Scope lists four things in and five things explicitly out. Behavior uses numbered plain-English steps without component jargon. Edge cases cover signed-out users, network failure, and tier limits. Success criteria give three measurable numbers instead of vibes. Evals define automated checks. The final section lists every string and keyboard behavior. Forty lines, zero ambiguity, instant execution by AI.

Another case is the design system team that applied the same anatomy to their own component docs. Each component page now reads like a miniature spec with intent, behavior, edge cases, and code examples. When a feature spec references the Card component with elevation level 2, the AI has actual contracts to follow instead of guessing from a screenshot.

Use this exact anatomy on every product feature spec. The template forces completeness. The out list in scope prevents feature creep. The success criteria section kills fuzzy goals. It earns its keep on anything that will be built by more than one person or consumed by AI.

Skip rigid adherence only when documenting brand moments or highly experimental prototypes where the artifact is intentionally looser. Even then you will probably return to the seven sections once the exploration settles. The tradeoff is that writing all seven sections feels exhaustive at first. After two weeks it feels like the only sane way to work.

The anatomy makes specs boring on purpose. Boring survives contact with reality. Exciting specs full of vision language usually fall apart the moment they hit code.

Teams that standardize on this structure see faster onboarding, fewer clarification questions, and cleaner handoffs. New designers can read three specs and immediately understand how the company thinks.

The image in the original article labeled every section for a reason. That diagram became the most screenshot internal wiki page at several scale-ups.

Master the anatomy. Your specs stop being suggestions and start being contracts.

Good spec anatomy turns subjective design opinions into objective, executable requirements.