Skip to content
Alpha

This site is an alpha version and is still being developed in the open - your feedback will help us improve it. See the roadmap. Last updated: 14 October 2026.

Version in force: 0.3.0 (6 October 2026).

Working with architects

For service designers, interaction designers, content designers and user researchers: when to involve an architect, what to bring, and what you can expect in return.

Prototype - testing with users

This section is an early prototype that we are testing with users. It may change a lot, and some of it may be wrong. Check with your solution design authority before relying on it, and tell us what works and what does not through the feedback link above.

Why this matters to designers and researchers

Many decisions that shape the user experience are architecture decisions too. They are cheap to change in discovery and alpha, and expensive afterwards. For example:

If you design or research any of these, involve an architect early. The guardrails each role leads are on the pages for service designers, interaction designers, content designers and user researchers.

When to involve an architect, and what to bring

This page covers the architecture touchpoints only. For your own discipline, use the Defra Digital Service Manual: design, user research and content design, including what content designers do in discovery, alpha, beta and live.

Discovery

Bring:

  • the current journey, mapped against the systems, teams and organisations behind each step
  • the information you ask users for, so an architect can tell you what Defra already holds and where the authoritative sources are (GR-DATA-02, GR-DATA-04)
  • what you are learning about users' devices, connectivity and who acts for whom

Alpha

Bring:

  • your riskiest assumptions on the user side, so you can test them alongside the riskiest technical assumptions rather than separately
  • the prototypes that depend on a technical choice, such as sign-in, file upload or a forms platform - prototype these on the real platforms where it matters, so research tests what users will actually get
  • anything that would mean departing from the GOV.UK Design System

Beta

Bring:

  • what users see when a dependency is slow or fails, such as a payment provider or a back-office system, and the content for it (GR-OPS-04)
  • confirmation and status content: what happens next, how long it takes and how users find out - based on how long processing really takes
  • findings from research with assistive technology users that need a technical fix

Live

Bring:

  • how you will tell users about incidents and planned downtime, and who sends those messages
  • research findings that point to a change in how the service works, not just how it looks - these may be a significant change

What architects do in return

Architects working with your team should:

  • come to show and tells and research playbacks, so they hear from users directly
  • join design critiques for journeys with technical constraints, such as sign-in, payments or file upload
  • record decisions that affect the user experience as ADRs, with the designer or researcher named as a contributor, so the reasons are kept alongside the technical ones - see architecture decision records
  • explain constraints in plain English, and say which ones are fixed and which can be challenged
  • raise it early when a technical decision will change what users see

How to ask

  • If your team has an architect, talk to them first.
  • If not, contact the Delivery Architecture team at delivery.architecture@defra.gov.uk. They will tell you the principal architect for your delivery group. See architecture in the Defra Digital Service Manual.
  • You can also use the routes on the architecture team page, which describes the architecture drop-in sessions.

To be confirmed

TODO: when and where the architecture drop-in sessions run, and how designers and researchers book them.