In a design system, what should a shared component's release-readiness checklist require beyond working code, and what does each item protect?
answer
- more than 'it renders'
- every theme, locale and width
- keyboard and screen reader too
- docs and tests are deliverables
- two sign-offs, backed by evidence
basics
~20 sBeyond working code: accessibility conformance, responsive and localisation readiness, support for every theme, usage docs, automated tests, parity with the design asset, and design and engineering sign-off - each backed by evidence, so consumers meet no surprises in any supported context.
solid answer
~40 sI would group it into eight items. **Accessibility**: keyboard operable, correct role, name and state, WCAG 2.2 AA contrast (4.5:1 text, 3:1 for non-text parts), visible focus and adequate target size, checked by a scan plus a manual keyboard and screen-reader pass. **Responsive**: works from narrow panels to wide screens and with enlarged text. **Localisation**: survives long translations, right-to-left layout and locale formats. **Theming**: every supported theme and mode, using semantic tokens only. **Docs**: when to use it, when not to, examples and accessibility notes. **Tests**: automated coverage that guards the behaviour. **Design parity**: code matches the design asset's variants, states and names. **Sign-off**: design and engineering each attest against evidence. Each item protects a consumer from finding a gap in production.
go deeper
Recall the eight items - accessibility, responsive, localisation, theming, docs, tests, design parity, sign-off - and be able to say in one line what each protects.
Explain what evidence satisfies each item, which accessibility criteria a component typically owns, and why a scanner alone cannot close the accessibility item.
Show how you keep the checklist enforceable across many contributors: evidence links, automation of repeatable checks, depth scaled to complexity, and pruning after escaped defects.
Weigh the bar's strictness against contribution throughput: a bar too heavy drives teams to build locally, one too light erodes the trust that makes consumers adopt the system.
## Why a checklist at all A **release-readiness checklist** is the explicit list of conditions a shared component must meet before a design system publishes it. Without one, 'done' silently means 'done for the context the author tried', usually one theme, one language, one width and a mouse. The checklist turns every context the system promises to support into an item someone has to verify on purpose. Take a date-range picker built for a B2B analytics dashboard. It will also be used in a reporting tool, an admin console and a native mobile app. The checklist is what makes it work in those places on day one. ## The items and what each protects | Item | What it checks | Protects consumers from | |---|---|---| | Accessibility conformance | keyboard operation, role, name and state, contrast, visible focus, target size, screen-reader output | shipping a control some users cannot operate | | Responsive readiness | narrow containers, large screens, text enlarged by the user | layouts that break outside the design's one width | | Localisation readiness | long translated strings, right-to-left layout, locale date and number formats | truncation, mirrored-layout bugs, wrong formats | | Theme support | every supported theme and mode; semantic tokens only, no hard-coded values | a component that looks right only in the default theme | | Documentation | purpose, when not to use, examples, content rules, accessibility notes, known limits | misuse and repeated support questions | | Tests | automated coverage of behaviour, states and visuals | regressions in the next release | | Design parity | code matches the design asset's variants, states, names and spacing | designers specifying one thing and engineers shipping another | | Sign-off | design and engineering (often an accessibility reviewer) attest the above | items ticked by nobody in particular | ### The accessibility item in more detail The accessibility item is usually anchored to **WCAG 2.2 level AA**, the level most organisations target. Criteria a component typically owns include: - **2.1.1 Keyboard** (A) - every function works from a keyboard. - **4.1.2 Name, Role, Value** (A) - assistive technology can read what the control is, what it is called and what state it is in. - **1.4.3 Contrast (Minimum)** (AA) - 4.5:1 for normal text, 3:1 for large text. - **1.4.11 Non-text Contrast** (AA) - 3:1 for the visual parts that identify controls and their states. - **2.4.7 Focus Visible** (AA) - keyboard focus can be seen. - **2.5.8 Target Size (Minimum)** (AA) - pointer targets at least 24 by 24 pixels, with a spacing exception. An automated scanner checks only machine-detectable rules, so the item also needs a manual keyboard pass and a screen-reader pass on each platform the component ships to. ## Evidence, not ticks A tick records an intention; **evidence** lets someone verify the claim later. Useful evidence per item: 1. A rendered example of the component in each supported theme, density and locale, including a long-string and a right-to-left case. 2. A link to the automated test run and the accessibility scan result. 3. Short notes from the manual keyboard and screen-reader pass. 4. A side-by-side of the design asset and the coded component for each variant and state. Items that genuinely do not apply are marked **not applicable with a reason**, never skipped silently. ## Sign-offs **Design sign-off** attests that the component matches the intended design and behaves as the spec describes in every variant and state. **Engineering sign-off** attests that the code is sound, tested, themeable and documented. Many systems add an **accessibility sign-off** for interactive components. Two different people signing off catch different classes of problem; one person approving both is a common shortcut that loses that. ## Keeping it usable A checklist nobody can complete gets bypassed. Practical rules: - Phrase each item as a **verifiable statement** ('renders without truncation with 40 percent longer strings'), not an aspiration ('localisation-friendly'). - **Automate** what is repeatable - token usage, contrast of token pairs, rendering in each theme - so reviewers spend time on judgement items. - **Scale depth, not items**: an icon button and a data grid face the same items, but the grid's keyboard and localisation checks are far deeper. - **Prune** items that never catch anything, and add one after every escaped defect that no item would have caught. ## What the checklist is not It is not the product team's general definition of done, and it is not the test strategy itself; it references both. It is the component-specific promise a design system makes to its consumers about what 'released' means.
- How do you stop a component release checklist from turning into box-ticking?Require evidence per item - a rendered example per theme and locale, a test-run link, notes from the keyboard and screen-reader pass - so a tick can be verified. Phrase items as checkable statements, automate the repeatable checks so humans focus on judgement, and review which items ever catch defects, pruning or adding accordingly.
- Should the checklist differ for a small icon button versus a complex data grid?The items should stay the same so nothing is forgotten, but the depth scales. For an icon button, localisation readiness is mostly a translatable accessible name; for a data grid it means long headers, right-to-left column order and locale number formats, plus a full keyboard model. Items that truly do not apply are marked not applicable with a reason.
- Why do design and engineering sign off separately rather than one reviewer approving everything?They catch different problems. A designer sees wrong spacing, a missing state or behaviour that departs from the spec; an engineer sees untested paths, hard-coded values and theming leaks. One person approving both tends to check their own discipline thoroughly and the other superficially.
saying these in an interview costs you the question
- If the automated accessibility scanner passes, the accessibility item is done.
- Docs can follow a release or two after the component ships.
- Supporting the default theme is enough; other themes are the consumers' job.
- Design sign-off is a formality once engineering has approved the code.
- Localisation readiness just means the strings have been translated.