‹ All writing

Let a design pattern earn its place in the system

Let a design pattern earn its place in the system

Let a design pattern earn its place in the system

Greg Herboek

Design process

The short answer

Keep a new pattern local until it has shown up in more than one product, been tested with the people who will use it, including disabled people, and has a named owner. Ship it where it's needed now, and propose it to the system in parallel, with the evidence.

Keep a new pattern local until it has shown up in more than one product, been tested with the people who will use it, including disabled people, and has a named owner. Ship it where it's needed now, and propose it to the system in parallel, with the evidence.

Original mobile concept in charcoal and bright yellow-green. A team app called Patterns shows Bulk select, a candidate pattern to keep local for now, with 3 of 5 checks met. Evidence: used in Billing and Reports, ticked; unique, no bulk select yet, ticked; reuses checkbox and table row, ticked; tested with, not yet with screen readers, open; works on, desktop only so far, open. Owner: Design systems lead. Exceptions: ask the owner, give a reason and where it breaks. Note: stays local until every check is met. Buttons: Add evidence and Propose to system. Beside the phone, dithered mismatched one-off blocks and three identical tiles lead to a solid yellow-green tray of matching tiles, with one tile dropping into the last empty slot. Text: Illustrative concept. Ship it locally. Standardize it once it has earned it.
Original mobile concept in charcoal and bright yellow-green. A team app called Patterns shows Bulk select, a candidate pattern to keep local for now, with 3 of 5 checks met. Evidence: used in Billing and Reports, ticked; unique, no bulk select yet, ticked; reuses checkbox and table row, ticked; tested with, not yet with screen readers, open; works on, desktop only so far, open. Owner: Design systems lead. Exceptions: ask the owner, give a reason and where it breaks. Note: stays local until every check is met. Buttons: Add evidence and Propose to system. Beside the phone, dithered mismatched one-off blocks and three identical tiles lead to a solid yellow-green tray of matching tiles, with one tile dropping into the last empty slot. Text: Illustrative concept. Ship it locally. Standardize it once it has earned it.

Illustrative concept, not client work or measured results.

Two questions, asked at different times

The GOV.UK Design System splits the decision in two. A proposal has to show the pattern is useful, with "evidence that this component or pattern would be useful for many teams or services," such as screenshots or links to versions already in use. It also has to be unique: not a repeat of something in the system, or, if it replaces something, shown to be better.

Only then comes the bar for publishing. The pattern must be usable, "tested in user research and shown to work with a representative sample of users, including those with disabilities." It must be consistent, reusing existing styles and components. And it must be versatile, working across a range of services, browsers, assistive technologies and devices.

The split matters because the two questions need different evidence. "Do several teams need this?" can be answered with screenshots. "Does this version work?" takes research. Merge them and a team can end up standardizing whichever version it happened to build first. GOV.UK's proposal guidance even asks people to "avoid spending time working on a specific design or writing code" at that stage.

Two questions, asked at different times

The GOV.UK Design System splits the decision in two. A proposal has to show the pattern is useful, with "evidence that this component or pattern would be useful for many teams or services," such as screenshots or links to versions already in use. It also has to be unique: not a repeat of something in the system, or, if it replaces something, shown to be better.

Only then comes the bar for publishing. The pattern must be usable, "tested in user research and shown to work with a representative sample of users, including those with disabilities." It must be consistent, reusing existing styles and components. And it must be versatile, working across a range of services, browsers, assistive technologies and devices.

The split matters because the two questions need different evidence. "Do several teams need this?" can be answered with screenshots. "Does this version work?" takes research. Merge them and a team can end up standardizing whichever version it happened to build first. GOV.UK's proposal guidance even asks people to "avoid spending time working on a specific design or writing code" at that stage.

Ship it locally, propose it in parallel

Waiting for the system shouldn't block the product. Trys Mudford describes building a component that was already on his design system team's backlog, and deciding not to add it to the system straight away: "Good design systems live in a lower pace layer than the projects they serve." He shipped it in the product and, as a parallel task, opened a pull request to the design system with a live example of the component in use.

That is the useful middle. The product gets its pattern now, and the system gets a real example to judge instead of a guess.

Keep the evidence where people can see it

In this illustrative concept, a bulk-select pattern sits in a team's pattern library as a candidate. Its card lists where it's used, what it reuses, who it has been tested with and who it hasn't, plus an owner and a way to ask for an exception. It stays local until the gaps close.

The evidence doesn't stop at publication. GOV.UK says it doesn't usually act on feedback immediately: "we need to grow a clear body of evidence." Depending on severity, the team will usually investigate when it hears similar findings from four or more different services. That number is GOV.UK's own rule of thumb, not a universal threshold, but the habit travels: decide in advance how much evidence moves a pattern, in either direction.

Ship it locally, propose it in parallel

Waiting for the system shouldn't block the product. Trys Mudford describes building a component that was already on his design system team's backlog, and deciding not to add it to the system straight away: "Good design systems live in a lower pace layer than the projects they serve." He shipped it in the product and, as a parallel task, opened a pull request to the design system with a live example of the component in use.

That is the useful middle. The product gets its pattern now, and the system gets a real example to judge instead of a guess.

Keep the evidence where people can see it

In this illustrative concept, a bulk-select pattern sits in a team's pattern library as a candidate. Its card lists where it's used, what it reuses, who it has been tested with and who it hasn't, plus an owner and a way to ask for an exception. It stays local until the gaps close.

The evidence doesn't stop at publication. GOV.UK says it doesn't usually act on feedback immediately: "we need to grow a clear body of evidence." Depending on severity, the team will usually investigate when it hears similar findings from four or more different services. That number is GOV.UK's own rule of thumb, not a universal threshold, but the habit travels: decide in advance how much evidence moves a pattern, in either direction.

Illustrative concept: From one-off to standard. Three steps: 1, ship it where it is needed, local, with no promise of reuse; 2, propose it with evidence, where it is used and why it is not a repeat; 3, publish when it is tested, with disabled users and across devices. Beside it, a pattern library by status: Date input, Standard, tested across 6 services; Bulk select, Candidate, 3 of 5 checks met; Filter chips, Local, used in 1 product so far. Note: local patterns ship now; the system waits.
Illustrative concept: From one-off to standard. Three steps: 1, ship it where it is needed, local, with no promise of reuse; 2, propose it with evidence, where it is used and why it is not a repeat; 3, publish when it is tested, with disabled users and across devices. Beside it, a pattern library by status: Date input, Standard, tested across 6 services; Bulk select, Candidate, 3 of 5 checks met; Filter chips, Local, used in 1 product so far. Note: local patterns ship now; the system waits.
Illustrative concept: From one-off to standard. Three steps: 1, ship it where it is needed, local, with no promise of reuse; 2, propose it with evidence, where it is used and why it is not a repeat; 3, publish when it is tested, with disabled users and across devices. Beside it, a pattern library by status: Date input, Standard, tested across 6 services; Bulk select, Candidate, 3 of 5 checks met; Filter chips, Local, used in 1 product so far. Note: local patterns ship now; the system waits.
Illustrative concept: From one-off to standard. Three steps: 1, ship it where it is needed, local, with no promise of reuse; 2, propose it with evidence, where it is used and why it is not a repeat; 3, publish when it is tested, with disabled users and across devices. Beside it, a pattern library by status: Date input, Standard, tested across 6 services; Bulk select, Candidate, 3 of 5 checks met; Filter chips, Local, used in 1 product so far. Note: local patterns ship now; the system waits.
Illustrative concept: From one-off to standard. Three steps: 1, ship it where it is needed, local, with no promise of reuse; 2, propose it with evidence, where it is used and why it is not a repeat; 3, publish when it is tested, with disabled users and across devices. Beside it, a pattern library by status: Date input, Standard, tested across 6 services; Bulk select, Candidate, 3 of 5 checks met; Filter chips, Local, used in 1 product so far. Note: local patterns ship now; the system waits.

Before you standardize it

Ask four questions. Where is it used today, in real products rather than imagined ones? Who has it been tested with, in which contexts, and who hasn't? Does it reuse what the system already has, and if it replaces something, what shows it's better? Who owns it, and how does a team ask for an exception? If any answer is missing, keep the pattern local and keep collecting evidence.

Before you standardize it

Ask four questions. Where is it used today, in real products rather than imagined ones? Who has it been tested with, in which contexts, and who hasn't? Does it reuse what the system already has, and if it replaces something, what shows it's better? Who owns it, and how does a team ask for an exception? If any answer is missing, keep the pattern local and keep collecting evidence.

References

References

About Greg Herboek ›