Topic 3.2 — Design Systems & Prototyping

A design system turns good design decisions into shared, reusable infrastructure — so that accessibility, clinical safety, and consistency are built in once and inherited everywhere, instead of being re-argued and re-broken on every screen.

Why this matters in health and care#

In health and care, the interface is often the last few centimeters between a clinical decision and a patient. A confusing medication field, an inaccessible date picker, a button that means "cancel appointment" in one service and "cancel and lose your data" in another — these are not cosmetic problems. They are patient-safety problems, equity problems, and trust problems. When every team designs its own components from scratch, defects multiply and safety guarantees become impossible to reason about across a portfolio.

A design system is how you stop paying for the same mistakes repeatedly. When an accessible, well-tested component is built once and reused across dozens of services, you fix an accessibility defect or a safety ambiguity in one place and every service inherits the fix. The alternative — bespoke front-ends everywhere — means unknown, uneven quality: some services meet the Web Content Accessibility Guidelines (WCAG) and some quietly exclude the very people who most depend on public health services.

Consistency is also a comprehension issue. Patients and staff move between services — a National Health Service (NHS) app, a trust's outpatient portal, a general practice booking tool — and every unfamiliar pattern imposes cognitive load. In a population that includes people who are unwell, anxious, older, digitally excluded, or using assistive technology, that load is not evenly distributed. Shared patterns lower it for everyone. This topic is about the machinery — components, patterns, tokens, prototypes, and design operations — that makes safe, accessible, consistent design the path of least resistance rather than an act of heroism.

Core concepts#

A design system is a single source of truth for the reusable components, patterns, styles, and guidance used to build a set of digital services. It is more than a style guide: it pairs working, coded components with the design rationale, accessibility notes, and usage guidance that tell you when and how to use each one. The two most relevant public examples are the NHS design system (maintained by NHS England, built on NHS.UK front-end) and the GOV.UK Design System, maintained by the Government Digital Service (GDS). Both are open, freely available, and battle-tested across millions of interactions.

A component library holds the discrete building blocks — buttons, form inputs, headers, error summaries — while a pattern library holds the higher-order solutions to recurring problems: how to ask for a date of birth, how to structure a page of questions, how to report an error, how to ask a user their NHS number. Components are the vocabulary; patterns are the sentences. Both draw on component-based software engineering, where systems are assembled from loosely coupled, independently testable, reusable parts.

Design tokens are the smallest shared decisions expressed as named variables — a color, a spacing unit, a font size, a focus-state outline. Because tokens are referenced by name rather than hard-coded, a change to a token (say, increasing minimum touch-target size or contrast) propagates consistently to every component that uses it. Tokens are the mechanism that keeps a system coherent as it scales, and that makes it possible to theme a shared system for local use without forking it.

A single source of truth is the governing idea: each design decision is mastered in exactly one place, so it cannot drift out of sync across services. When the design and the code and the guidance for a component all live in one authoritative library, you eliminate the class of bugs where the picture and the product disagree.

Software prototyping is the practice of building deliberately incomplete versions of a service to learn something before you commit to building the real thing. Prototypes range from low-fidelity (paper sketches, grayscale wireframes) to high-fidelity (interactive, realistic, often built in code). The GDS principle is prototype to learn, not to keep: a prototype's job is to answer a question through usability testing with real users, after which it is thrown away — this is throwaway (or "rapid") prototyping, distinct from an evolutionary prototype you intend to harden into production.

DesignOps (design operations) is the discipline of running design at scale — the people, workflows, governance, contribution model, and tooling that keep a shared design system healthy, funded, and trustworthy across an organization or integrated care system (ICS). It is to design what platform engineering is to code: mostly invisible when it works, painfully obvious when it does not. Prototyping is done in design tools such as Figma or directly in code using the front-end of a design system, which brings us to front-end web development — the HTML, CSS, and JavaScript layer where reuse actually reduces duplication, cost, and risk.

This topic deliberately does not re-cover what users need (see Topic 3.0 — User Research & Service Design) or how words are written (see Topic 3.1 — Content Design & Health Literacy). Those disciplines feed the design system; this topic is about the reusable machinery that carries their conclusions safely into production.

Best practices#

1. Adopt before you build. Start from the NHS design system and the GOV.UK Design System rather than inventing your own. They already encode years of accessibility testing, content design, and real-world use across health and government services. Reinventing a date picker or an error summary is not a good use of scarce, expensive design and engineering capacity, and a home-grown version will almost always be less accessible. Extend and theme these systems for local needs; do not fork them without a deliberate, documented reason.

2. Build accessibility and clinical safety into the shared components, not the individual screens. The whole economic and safety case for a design system is that you fix something once and inherit it everywhere. An accessible, keyboard-navigable, screen-reader-tested date-of-birth component, built and assured once, protects every service that uses it. Bake WCAG conformance, sensible error handling, and safety-relevant behaviors (clear confirmation of destructive actions, unambiguous units for doses and measurements) into the component itself, so teams cannot easily get them wrong (see Topic 1.9 — Digital Inclusion & Accessibility, and Topic 1.6 — Clinical Safety & Risk Management).

3. Prototype to learn, not to keep. Treat prototypes as disposable experiments that answer a specific question — "can a patient with low health literacy complete this referral?" — cheaply and fast. Match fidelity to the question: use low-fidelity sketches to test flow and comprehension early, and high-fidelity coded prototypes to test realistic interaction, accessibility, and edge cases later. Resist the pull to promote a prototype straight into production; prototype code optimized for speed of learning is rarely safe, secure, or maintainable enough for a live clinical service.

4. Prototype in the real front-end when interaction and accessibility are the question. Design-tool prototypes (Figma and similar) are excellent for exploring layout, flow, and content quickly and collaboratively. But they cannot faithfully test keyboard navigation, screen-reader behavior, focus management, or performance on old NHS estate hardware. When those are the risks, prototype in code using the design system's front-end, so you are testing something close to what real users will actually experience with real assistive technology.

5. Test prototypes with real users before you build. A prototype that is never put in front of representative users is just an expensive opinion. Test with people who reflect your actual population — including older people, people with disabilities, people with low digital confidence, and staff working under time pressure. Even five participants will surface most of the serious usability and comprehension problems, and finding them in a prototype is orders of magnitude cheaper than finding them in production (see Topic 3.7 — Testing & Quality Assurance).

6. Manage tokens as the contract for consistency. Express colors, spacing, typography, and interaction states as named design tokens, and treat changes to them with the seriousness of a shared dependency change. Tokens let you enforce minimum contrast, touch-target size, and focus visibility system-wide, and let a local team re-theme for their brand without breaking the underlying accessibility guarantees. When a national standard shifts, you want to change one token, not audit ten thousand screens.

7. Run a contribution model, not a walled garden. A design system that only accepts input from a central team will always lag behind real service needs and will be resented by delivery teams. Publish a clear route for teams to propose new components and patterns, with criteria for what gets accepted, who reviews it, and how accessibility and safety are assured before anything is promoted to the shared library. This is core DesignOps work: it balances the tension between local flexibility and shared consistency without letting the system rot or fragment.

8. Version, document, and communicate changes. Treat the design system as a product with users (your delivery teams), a roadmap, release notes, and a support channel. Semantic versioning, changelogs, and clear deprecation notices let teams adopt improvements safely and on their own schedule. Undocumented breaking changes destroy the trust that makes teams choose the shared system over rolling their own.

9. Measure adoption and quality, not just existence. A design system delivers value only when it is used. Track which services use the shared components, where teams have had to build bespoke alternatives (and why), and whether accessibility conformance improves as adoption rises. High rates of local workarounds are a signal that the system is missing something real — treat them as backlog, not as disobedience.

Questions to discuss with your team#

1. Where should the line sit between shared consistency and local flexibility, and who gets to decide? This is the central governance tension of any design system. Too rigid, and delivery teams feel blocked, build shadow components, and route around the system — fragmenting the very consistency you were trying to protect. Too loose, and the "system" becomes a loosely related pile of one-offs with no shared safety or accessibility guarantees. In a health and care context the stakes are specific: some variation is legitimate (a mental-health crisis service has genuinely different needs from a routine appointment booker), while some variation is dangerous (inconsistent ways of confirming a destructive clinical action). A good answer names which decisions are non-negotiable (accessibility, safety-critical patterns, core interaction behaviors) and which are open to local theming, and it defines an explicit, humane process for a team to request an exception or contribute a new pattern rather than just forbidding divergence.

2. How will accessibility and clinical safety actually be assured inside our components — and who signs it off? It is easy to claim that accessibility and safety are "baked in"; it is hard to guarantee it. This question forces you to be concrete about the assurance pipeline: who tests each component against WCAG, with which assistive technologies, and with which disabled users; how safety-relevant behaviors are reviewed against your clinical safety process (DCB0129/DCB0160); and what evidence is attached to a component before it is published as "safe to reuse". The debate should surface honest gaps — perhaps you have automated contrast checks but have never tested with a real screen-reader user, or your Clinical Safety Officer has never reviewed the shared component library. A strong answer produces a named owner, a defined test regime, and a rule that no component enters the shared library without documented accessibility and safety evidence, because a defect inherited by fifty services is fifty times the harm.

3. Who funds, staffs, and maintains the design system once the initial enthusiasm fades? Design systems are frequently created in a burst of energy and then quietly abandoned when the founding team moves on, leaving a stale library that teams no longer trust. This is fundamentally a DesignOps and funding question, not a design question. Debate honestly whether you have a standing, funded team responsible for the system as an ongoing product — with capacity for support, contribution review, versioning, and keeping pace with the upstream NHS and GOV.UK systems — or whether you are relying on goodwill that will evaporate. In an ICS this is sharper still: is the system owned by one dominant organization, jointly governed, or orphaned between them? A good answer treats the design system as long-lived infrastructure with a named owner, a running budget, and a clear relationship to the national systems it builds on, rather than a project that "finishes".

4. What is our relationship to the upstream NHS and GOV.UK systems — and how will we stay in step with them as they change? Adopting a national design system is not a one-off download; it is an ongoing dependency on infrastructure you do not control. This question forces you to decide, deliberately, where you sit on the spectrum from "theme lightly and track upstream closely" to "fork and diverge". Each choice has a cost: staying close means absorbing upstream changes (a new accessibility fix, a revised pattern) on someone else's schedule and occasionally reworking local customizations; forking means you own every future accessibility and safety fix the national team would otherwise have given you for free. In health and care the pull to diverge is real — clinical workflows and local branding create genuine pressure — but every divergence is a standing liability. A good answer names who watches the upstream release notes, how local extensions are structured so they survive an upstream update, and the explicit test a proposed divergence must pass before it is allowed, so that "we needed it to look different" never quietly becomes "we now maintain a stale, less-accessible fork of the NHS date picker".

5. How will we actually hold the line between "prototype to learn" and "build to keep"? Everyone agrees in principle that throwaway prototypes should not become production services; the failure happens under deadline pressure, when a convincing high-fidelity prototype is sitting right there and shipping it looks like a shortcut. This question makes the boundary concrete rather than aspirational. Debate what practically stops prototype code — optimized for speed of learning, not for security, resilience, or maintainability — from being promoted into a live clinical service: is it a technical separation (prototypes built in a sandbox that cannot reach production), a governance gate (no clinical safety sign-off, no go-live), or merely a shared good intention that evaporates the first time a delivery date slips? The health and care stakes are specific, because unassured code in a clinical pathway is a patient-safety exposure, not just technical debt. An honest answer admits where the pressure will come from, names who is empowered to say no, and defines what "rebuild for production from assured components" actually requires so the boundary holds when it is tested.

6. How will we know whether the design system is actually working — and what will we do when the metrics are uncomfortable? A design system can exist, be beautifully documented, and still deliver little value if teams quietly route around it. This question pushes past "we have a design system" to "is it earning its keep". Decide what you will measure: adoption across services, the rate and reasons for bespoke workarounds, whether accessibility conformance actually improves as adoption rises, and how much time teams save by reusing rather than rebuilding. The hard part is not collecting the numbers but agreeing in advance how you will read them — because a high rate of local workarounds is a signal that the shared system is missing something real, not evidence that delivery teams are being disobedient. A good answer commits to treating uncomfortable adoption data as backlog and roadmap input, defines who reviews it and how often, and resists the temptation to measure only the flattering thing (existence, download counts) instead of the thing that matters (safer, more accessible, more consistent services actually shipped).

In practice: a health & care example#

An integrated care system covering three acute trusts, a mental-health trust, and a community provider decides to consolidate its patient-facing digital estate. Today each organization runs its own outpatient portal; between them they have four incompatible date pickers, three different ways of asking for an NHS number, and wildly varying accessibility conformance. An internal audit finds that only one of the four portals passes a basic screen-reader test of its appointment-booking flow — a clear equity and clinical-safety exposure.

The ICS stands up a small, jointly funded design system team. Rather than build from scratch, they adopt the NHS design system as their foundation and define a thin local layer of design tokens for ICS-specific branding, plus a handful of genuinely local patterns (for example, a shared pattern for booking interpreter support, which none of the national systems cover). Every shared component carries documented WCAG evidence and a sign-off from the ICS Clinical Safety Officer under the DCB0129 process before it is published.

Before rebuilding the outpatient booking flow, the team prototypes. They start low-fidelity, testing a paper-and-grayscale version of the new flow with twelve participants recruited to reflect the local population — including two screen-reader users, three people over 75, and several with low digital confidence. The prototype exposes a serious comprehension problem: patients cannot tell a "reschedule" action from a "cancel" action. The team fixes the pattern, then builds a high-fidelity coded prototype using the design system front-end and retests, this time confirming keyboard and screen-reader behavior on the actual hardware used in a partner trust's outpatient clinics.

Only then do they build for real, assembling the production service largely from assured, reusable components. Eighteen months later, a WCAG update tightens focus-visibility requirements. Because focus styling lives in a single design token, the team ships one change and every ICS service inherits it in the next release — a fix that, under the old fragmented estate, would have meant five separate remediation projects and, realistically, at least one service left broken.

Sector lenses#

Startup#

A small digital-health startup should almost never build its own design system from zero — it cannot afford the accessibility testing overhead, and investors are paying for clinical validation, not bespoke buttons. Adopt the NHS or GOV.UK front-end where you are building for NHS users, and treat prototyping as your core competitive advantage: cheap, fast, throwaway prototypes tested with real patients let you learn faster than better-funded incumbents. The risk is the opposite one — promoting a slick high-fidelity prototype straight into production to hit an investor demo, carrying unassured, insecure code into a live clinical service. Keep a hard line between "prototype to learn" and "build to keep", even under funding pressure.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, or a single-site clinic commissioning a patient-facing tool — has live patients but no dedicated design or front-end capability, and cannot absorb the cost of bespoke components. Its most powerful move is to insist any supplier build on the NHS or GOV.UK front-end, so the accessibility and safety guarantees come inherited rather than promised, and to make that a written condition of the contract rather than a hope. It rarely needs to run a design system of its own; it needs to consume one well, and to recognize that a supplier's slick demo is not evidence of an accessible, assured live service. Where it does prototype — testing a new online booking flow with its actual, often older or less digitally confident patients — a few sessions with real users will catch far more than a polished mock-up ever reveals. The same statutory accessibility and clinical-safety duties apply as to a large trust, so the honest question is not whether to comply but how to get inherited compliance cheaply from shared national infrastructure.

Enterprise#

A large NHS trust or health-tech firm already has multiple teams building overlapping interfaces, so its problem is fragmentation and duplicated cost. The value case is a funded, standing design system team running a real contribution model, with adoption metrics reported to leadership and a clear governance line to clinical safety and accessibility assurance. The central tension is political: powerful delivery teams resist ceding control, and a heavy-handed central team breeds shadow components. Enterprises succeed by making the shared system the genuinely easier choice — well documented, well supported, and demonstrably higher quality — rather than mandating it and hoping.

Government#

A national body such as NHS England or GDS operates the design system as public infrastructure used by organizations it does not control, so openness, stability, and backward compatibility matter enormously. Its obligations are the strongest: statutory accessibility regulations, equality duties, and the reality that a defect in a shared national component propagates to millions of citizens. The work is less about invention and more about stewardship — clear versioning, deprecation policy, exhaustive accessibility evidence, and responsiveness to the hundreds of teams downstream. The NHS design system and GOV.UK Design System are the reference examples precisely because they treat the system as a long-lived public good, not a project.

Common failure modes#

• The abandoned system. A design system is built with fanfare, then left unmaintained when the founding team disperses; teams lose trust and drift back to bespoke work. Avoid it by funding a standing product team, not a one-off project.
• The picture that lies. Design files and production code disagree because there is no single source of truth, so "the design system" describes something the product no longer does. Keep coded components and their documentation authoritative and versioned together.
• Accessibility as afterthought. Components are shipped without real assistive-technology testing, so an inaccessible pattern is inherited everywhere — multiplying, not reducing, harm. Require documented WCAG and screen-reader evidence before any component is published.
• Prototype-to-production. A high-fidelity prototype is promoted straight into a live service to save time, carrying insecure, unmaintainable, unassured code into a clinical setting. Enforce the throwaway boundary; rebuild for production from assured components.
• The walled garden. A central team refuses all contributions, so the system never meets real service needs and delivery teams route around it. Publish a contribution and exception process and treat local workarounds as backlog signal.
• Consistency theater. Rigid uniformity is enforced where genuine local variation is warranted (crisis services, pediatrics), degrading safety and usability in the name of tidiness. Distinguish non-negotiable decisions from legitimately local ones.
• Testing the wrong fidelity. Interaction and accessibility risks are "tested" only in a static design tool that cannot exercise keyboard or screen-reader behavior, giving false confidence. Prototype in code when interaction is the question.

Maturity model#

Checklist#

• You have adopted the NHS design system and/or GOV.UK Design System as your foundation rather than building from scratch.
• Shared components carry documented WCAG conformance evidence, tested with real assistive technology and disabled users.
• Safety-relevant components have been reviewed under your clinical safety process before being published for reuse.
• Design tokens govern color, spacing, typography, and interaction states, enabling system-wide changes from one place.
• There is a single source of truth where coded components and their guidance live and are versioned together.
• Prototypes are matched in fidelity to the question, tested with a representative user sample, and treated as disposable.
• Interaction- and accessibility-critical flows are prototyped in code, not only in a design tool.
• A funded, named team owns the design system as an ongoing product, with a roadmap and support channel.
• A published contribution and exception process lets delivery teams propose new components and patterns.
• Adoption and quality are measured, and high rates of local workaround are treated as backlog, not disobedience.

Key sources#

• NHS design system — NHS England: components, patterns, styles, and accessibility guidance for NHS digital services.
• GOV.UK Design System — Government Digital Service: styles, components, and patterns for UK government services.
• GOV.UK Service Manual — prototyping and "make a prototype" — Government Digital Service: guidance on prototyping to learn and testing with users.
• NHS Digital Service Standard — NHS England: the standard shared and consistent services are assessed against.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: the accessibility conformance standard.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK government: the statutory accessibility duty for public sector services.
• DCB0129 / DCB0160 Clinical Risk Management standards — NHS England: clinical safety standards for the manufacture and deployment of health IT systems.
• Design Council Double Diamond — Design Council: the discover–define–develop–deliver model underpinning discovery and design.

References#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards