Component Spec Template for Product Managers

Even a simple button has more states than most teams realize: default, hover, focus, active, disabled, loading, and icon-only variants. A button spec should be shorter than this multi-select example, but it still needs to cover every state, size variant, and keyboard behavior. For common components, reference the [design system documentation template](/templates/design-system-documentation-template) and keep individual specs lightweight by inheriting global conventions.

Usually the designer writes it, with input from the PM (on use cases and edge cases) and the engineer (on technical constraints). The PM should review the spec to confirm it covers the product requirements and user scenarios they care about. The engineer should review to confirm it is implementable within technical constraints.

Write a spec when the component has complex interaction behavior (keyboard shortcuts, multi-step flows, async loading), multiple states, or will be reused across the product. Simple, one-off UI elements (a static card, a text block) usually do not need a formal spec. Figma inspection is sufficient for visual properties but cannot communicate behavior.

Define breakpoints in the Responsive Behavior section. For each breakpoint, describe what changes: does the component switch from inline to full-width? Do touch targets increase? Does the layout stack vertically? If the component is not usable below a certain width, say so explicitly and define the minimum supported width. ---