A date field appears on three screens with different error messages, leaving developers unsure which version governs. Screen images do not always answer the shared-component question: what are its rules and states, and who updates it when product needs change?
If a UI/UX proposal includes a “design system,” request the deliverable behind the name. Will you receive a design-tool library, code components too, or usage guidance? These related outputs differ, and responsibility may be split across teams.
Start with a component the product needs
Imagine a fictional room-setup request system. Request staff and room managers use two forms containing recurring date and notes fields. Developers should not repeatedly infer help, error and disabled behavior from separate pictures. No such system or user study was created here; the example defines procurement scope.
Select one field and trace it through design, guidance and an implemented example if development is included. Exercise short and long content, empty and invalid states. The objective is reusable decisions, rather than a large library containing components nobody uses.
A component card for designers and developers
- Purpose: What problem does the component solve, and when should another pattern be used? Include an example from the intended journey.
- States: Normal, focused, invalid and disabled presentation with corresponding messages and behavior; color alone should not explain the meaning.
- Content: Label, help and long-text limits, including Arabic and English differences, with examples suitable for product data.
- Design values: Named colors, spacing and typography mapped to implementation values, rather than scattered settings that resist consistent updates.
- Delivery references: Editable component, version and usage guide, plus code example and interface if contracted, explicitly identifying design-only work.
- Ownership: Who approves changes and updates design, code and documentation? How do users learn that a new version requires review?
This proposed card does not mandate a tool or frontend framework. Scope can remain small, such as recurring form components in the initial journey. The proposal should identify component counts, types and states, together with separately commissioned development, without turning every content difference into another component.
Why do named shared values matter?
USWDS documentation explains tokens as discrete color, spacing and typography options supporting design-to-development communication. Buyers can request an understandable mapping of names, values and usage without adopting that system's terminology or tooling. A token file does not establish accessibility.
For the fictional date field, ask what happens when help spacing or border color changes. Does it reach every intended usage, or are hidden independent copies present? Request a limited change in a suitable environment, identifying affected locations and documented, intentional differences.
A library needs evidence and boundaries
GOV.UK contribution criteria include usability, consistency and versatility when reviewing components. Use those questions without importing its procedures or support deadlines into a private agreement. Ask what was tested, on which devices and contexts, and what still requires post-implementation verification.
A working design-tool prototype cannot independently prove keyboard or screen-reader behavior in a browser. Short English content does not cover mixed Arabic text. Assign each check to its appropriate owner and stage, documenting outcomes and limits instead of labeling the entire library automatically accessible or compatible.
Agree the component's life after handover
What should a developer do when a required state is absent? Request a proposal-and-review channel deciding between extending the shared component and creating an exception. Preserve reasons, affected versions and usage-update steps when components change; otherwise design and code may match only on handover day.
The UI/UX deliverables guide addresses broader scope, while Arabic design acceptance covers direction checks. When requesting UI/UX design from Nextwave, attach a recurring-component card to clarify the purchase and its development-team follow-up.
Sources behind the approach
GOV.UK contribution criteria and USWDS token documentation were opened on 4 November 2026. The original card and example involve no created library, usability study or accessibility certification. AI assisted preparation, with information and translation review.