Capability template for design and user experience
Component specification
When an approved reusable component needs documenting, the design-system owner gets one specification of its variants, states, usage rules and accessibility notes, set beside the existing patterns, with every gap or clash written as a choice for the owner.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
A component that has been approved in a design is not yet a pattern anyone can use. Engineers need to know which variants exist, which states each one has, when to reach for it and when not to, and what it must do for people using a keyboard or a screen reader. If that lives in a designer's head or a comment thread, each team builds its own reading of it.
This capability turns the approved design into one specification. Every variant is listed with the states the design actually shows and the tokens it names. Usage rules and accessibility notes come only from what the design owner's team has written down. The specification then compares the component with the patterns already in your library and says where it overlaps and how it differs.
Anything missing is a numbered choice: a state your standard requires that the design does not show, a usage or accessibility topic nobody has written about, a clash with an existing pattern. The owner makes each choice. The capability invents no state, writes no rule of its own and creates or alters no component.
Who starts the work, and when
The design-system owner, or a designer working for them, starts it when an approved component design is ready to be documented or an existing pattern is to be extended. The owner approves the finished specification together with the engineer who will implement it. Run it again when the design or the choices change.
What they supply
- The approved design of the component as a list: one row per variant in one state, with a plain description of what the design shows and the tokens it names.
- The existing patterns in your library: name, purpose, contexts, variants, states, usage rule and reference.
- Usage and accessibility notes already written for the component, each filed under a topic.
- Engineering constraints, if any.
- A few settings: the component and library, its intended contexts and purpose, the states your standard requires, and who the owner and engineer are.
What comes out
One specification in a fixed order: the component's purpose and contexts, its variants and states, usage rules, accessibility notes, engineering constraints, a comparison with each existing pattern, the numbered choices for the owner, anything set aside, and a sign-off block for the owner and the engineer. If a section has nothing in it, it says None.
It does not recommend which choice to make. A person makes it.
An invented example
Illustrative example with invented data. The library, the product, the component, the patterns and every token and note below are invented. Library R belongs to an invented invoicing product. The design operations lead ran the capability after the design-system owner approved a design for an inline alert. First come the inputs the lead supplied, in full, then the specification the capability returned.
The inputs
1. Settings
Library: Library R (an invented design library)
Component: Inline alert
Design reference: Inline alert design, version 2
Purpose: Shows a message next to the content it concerns
Intended contexts: form field group; settings panel; page top
Required states: default; focus; hover
Design-system owner: Design-system owner
Engineer: Implementing engineer
Operator: Design operations lead
Today: 2026-11-10
2. Approved design (design.csv)
variant,state,description,tokens
info,default,Blue bar with an information icon and one line of text,color.alert-info-bg; color.alert-info-text; space.alert-pad
info,focus,Dismiss button shows a 2 px outline,color.focus-ring
info,hover,Dismiss button darkens,color.alert-info-hover
warning,default,Amber bar with a warning icon and one line of text,color.alert-warn-bg; color.alert-warn-text; space.alert-pad
warning,focus,Dismiss button shows a 2 px outline,color.focus-ring
error,default,Red bar with an error icon and up to two lines of text,color.alert-error-bg; color.alert-error-text; space.alert-pad
error,focus,Dismiss button shows a 2 px outline,color.focus-ring
error,hover,Dismiss button darkens,color.alert-error-hover
3. Existing patterns (patterns.csv)
pattern,purpose,contexts,variants,states,usage_rule,reference
Banner,Shows a message about the whole page,page top; site header,info; warning,default; focus,One message per page,D-07
Toast,Brief message after an action,after save; after send,info; success; error,default,Disappears on its own,D-31
4. Notes (notes.csv)
note_id,topic,applies_to,note
N1,use,all,Use beside the content the message concerns
N2,placement,all,Directly above the field group it refers to
N3,content,error,Up to two lines of text
N4,name,all,The dismiss button is labelled Dismiss message
N5,keyboard,all,The dismiss button is reached with Tab and activated with Enter or Space
N6,focus,all,The dismiss button shows a 2 px outline when focused
N7,colour,all,Every message starts with an icon and the word Information; Warning or Error
5. Constraints (constraints.csv)
constraint_id,applies_to,constraint
K1,all,Must display on the legacy settings page without scripted animation
K2,success,Message text is limited to 160 characters
The specification
COMPONENT SPECIFICATION: Inline alert, Library R (an invented design library)
For: Design-system owner and Implementing engineer. Prepared 2026-11-10 by Design operations lead, from 8 design rows, 2 existing patterns, 7 notes, 2 constraints and the settings.
Column check: all headers matched.
Variants: 3. Required states: 9, of which 8 shown and 1 not shown. Distinct tokens: 10. Choices: 5. Set aside: 1.
PURPOSE AND CONTEXTS
Purpose: Shows a message next to the content it concerns.
Intended contexts: form field group; settings panel; page top.
Design reference: Inline alert design, version 2.
VARIANTS AND STATES
Required states: default; focus; hover.
info
default: shown, "Blue bar with an information icon and one line of text".
focus: shown, "Dismiss button shows a 2 px outline".
hover: shown, "Dismiss button darkens".
Also shown: none.
Tokens: color.alert-info-bg; color.alert-info-text; space.alert-pad; color.focus-ring; color.alert-info-hover.
warning
default: shown, "Amber bar with a warning icon and one line of text".
focus: shown, "Dismiss button shows a 2 px outline".
hover: not shown in the approved design. C1.
Also shown: none.
Tokens: color.alert-warn-bg; color.alert-warn-text; space.alert-pad; color.focus-ring.
error
default: shown, "Red bar with an error icon and up to two lines of text".
focus: shown, "Dismiss button shows a 2 px outline".
hover: shown, "Dismiss button darkens".
Also shown: none.
Tokens: color.alert-error-bg; color.alert-error-text; space.alert-pad; color.focus-ring; color.alert-error-hover.
Tokens are printed as supplied. No token list was given, so none was checked.
USAGE RULES
use: N1 (all): Use beside the content the message concerns.
avoid: not supplied. C2.
placement: N2 (all): Directly above the field group it refers to.
content: N3 (error): Up to two lines of text.
ACCESSIBILITY NOTES
name: N4 (all): The dismiss button is labelled Dismiss message.
keyboard: N5 (all): The dismiss button is reached with Tab and activated with Enter or Space.
focus: N6 (all): The dismiss button shows a 2 px outline when focused.
announcement: not supplied. C3.
colour: N7 (all): Every message starts with an icon and the word Information; Warning or Error.
target: not supplied. C4.
ENGINEERING CONSTRAINTS
K1 (all): Must display on the legacy settings page without scripted animation.
EXISTING PATTERNS
Banner (D-07): purpose "Shows a message about the whole page"; contexts page top, site header; variants info, warning; states default, focus; usage rule "One message per page".
Overlap: shares the context "page top" with Inline alert. C5.
Variants only in Inline alert: error. Variants only in Banner: none.
States only in Inline alert: hover. States only in Banner: none.
Toast (D-31): no overlap found on name, purpose or context.
CHOICES FOR THE DESIGN OWNER
C1 warning, hover: The approved design shows no hover state for warning, and the required states include it. Add it to the design, or mark it not applicable for warning.
Status: Open. Choice: ______ Chosen by: ______ Date: ______
C2 usage, avoid: No note supplied on when not to use Inline alert. What should the rule say?
Status: Open. Choice: ______ Chosen by: ______ Date: ______
C3 accessibility, announcement: No note supplied on how a change appearing is made known to assistive technology. What should the note say?
Status: Open. Choice: ______ Chosen by: ______ Date: ______
C4 accessibility, target: No note supplied on the size of anything a person presses. What should the note say?
Status: Open. Choice: ______ Chosen by: ______ Date: ______
C5 existing pattern, Banner: Inline alert and Banner share the context "page top". Extend Banner, keep both with a rule that separates them, or retire one.
Status: Open. Choice: ______ Chosen by: ______ Date: ______
SET ASIDE
K2: names the variant "success", which the approved design does not contain. Which variant is meant?
SIGN-OFF
Design-system owner: has made every choice and approves this specification: ______ Date: ______
Implementing engineer: confirms all 5 choices are made and every set-aside line is dealt with: ______ Date: ______
Draft for the Design-system owner. No component has been created or changed, no state or rule has been invented, and nothing has been sent.
Where it fits
- Design and user experience, where a reusable component is only reusable once it is written down.
- Software engineering, where the implementing engineer needs variants, states and rules in one place.
- Software technology, where product teams add components faster than anyone documents them.
- E-commerce and retail, where storefront and checkout teams often need their own variant of a shared pattern.
- Marketing and advertising, where agencies maintain brand libraries and need each pattern spelled out for the next team.
- Startups & new ventures, where the first design system is written down for the first time.
- Growth & scaling, where more teams build on the library and unwritten rules stop travelling.
It documents one approved component. It is a different piece of work from Design handoff record, which records every state, token and breakpoint of a whole approved design before the build, and from Component inventory audit, which lists every component in a library and its gaps. Once the choices are made, Acceptance criteria sheet can turn the specification into checks for a story.
What has to change for your company
Fix the column headers of your design list and your pattern list once, and decide who exports them. Write the states your standard requires for a component. Decide whether the four usage topics and six accessibility topics match how your library documents patterns. Agree who the design-system owner is for each product, who answers when they are away, and where the approved specification is kept for the engineer.
What has been checked
Fully Powered AI wrote this capability template. It was editorially reviewed on 10 November 2026. It was tried once on its invented example, in Claude on 10 November 2026, and the record is published with it. It has not been tested in a client environment or as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on a component that is already documented, with cases written in advance: a required state the design does not show, a topic with no note, a pattern that shares a context with the new component, a constraint that names a variant that does not exist. The owner checks every line against the design and the library before anyone relies on the specification.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: