Patterns are reusable pieces of service design made from one or more pages. A pattern belongs to a library and can be inserted into future services in that library. Use patterns to speed up common work and standardise a proven way of asking for information.

Open a library and select Patterns from the library navigation.

Understand reuse

flowchart LR
  A[Create and maintain library pattern] --> B[Insert into Service A]
  A --> C[Insert into Service B]
  B --> D[Independent copy in Service A]
  C --> E[Independent copy in Service B]

After insertion, the service receives a copy that can be customised. Updating the source pattern does not automatically update pages already inserted into services. This protects existing journeys but means a standards change must be assessed across previous copies.

Create a pattern

1. Select Add pattern.
2. Give it a clear template name and description.
3. Add and order pages and components as you would in a service.
4. Configure page titles, progress text, conditions and reusable content.
5. Test the pattern by inserting it into a temporary service and opening User view.
6. Refine the description so builders know when to use it and what must be customised.

The pattern list shows its name, description, last editor and update time. Use the description to state the user need, included pages, required follow-up configuration and any unsuitable use.

Reuse pages through copy and paste

The page-design view provides copy and paste controls that can move pages between services and patterns. Before copying, remove service-specific names, email addresses, URLs, identifiers and conditions that will not make sense elsewhere.

A good pattern contains coherent defaults and obvious placeholders. It should not quietly depend on a field or action that exists only in the source service.

Design maintainable patterns

Use a pattern for a meaningful interaction, such as contact details or evidence upload, rather than for every individual component. Keep it small enough that a builder can understand and adapt it.

For each maintained pattern, record:

• the user need and owner;
• pages and components included;
• required service settings or integrations;
• accessibility and research evidence;
• the date and reason for the latest material change.

Field and page IDs in an inserted copy must remain unique within the destination service. Review conditions, Liquid references, action inputs and navigation after insertion.

Update or delete a pattern

Open a pattern to change its name, description, page content or components. Test the revised source in a temporary service. Because existing copies do not update, tell service owners when an important defect or policy change affects prior use.

Delete a pattern only after confirming that it is no longer needed as a source. Deletion does not remove copies already inserted into services.

Pattern quality checklist

• The name describes the interaction, not the original service.
• The description says when to use it and what to customise.
• Content contains no source-service data, credentials or private URLs.
• Conditions, navigation and identifiers work after insertion.
• The pattern has been tested in a temporary service at mobile and desktop widths.
• An owner reviews it after platform or policy changes.

Related guides

• Design pages and navigation
• Add and configure components
• Use conditions and branching
• Service change management