Skip to content
GO

GOV.UK

Public sector, forms · 2015 to now · 8 min

One thing per page

The least fashionable design decision in government, and why it beats every clever form you have ever seen.

The UK government runs services people cannot opt out of. You do not get to choose a competitor for renewing a passport, and the people using it include everyone: on old phones, on bad connections, in a second language, in a hurry, and sometimes in distress.

The Government Digital Service published a design pattern that sounds almost too simple to be a decision. Ask one question per page.

It is the clearest example in public of a design principle that costs something obvious, more page loads, to buy something less obvious and far more valuable.

How to read this

Scroll. The screen on the right changes as each beat arrives, and the callouts land on the part being discussed. Every beat names the principle underneath it, which is the bit that transfers to your product.

01 The wall

The form that looks efficient

Every field on one page looks like the considerate option. Fewer clicks, everything visible, one submit button. This is what most teams ship, and what most stakeholders ask for.

What it actually does is force the user to hold eleven unrelated decisions in their head at once, then punish them at the end with a page of red text.

It is also the version that breaks hardest. One validation error and the user is scanning a wall for the thing they got wrong.

Apply for a licenceTitleFirst nameLast nameDate of birthNational insurance numberAddress line 1Address line 2TownPostcodePhoneEmailContinue11 fields, 1 page12
  • 1Eleven fields, four different kinds of question.
  • 2All the failure arrives at once, at the end.
The wall. Drawn for this teardown, not a screenshot.
Cognitive load

Working memory holds very little. A form that asks for many unrelated things at once spends all of it on navigation rather than on answering.

02 The split

One question, one page, one decision

Split the same form into nine pages and something counterintuitive happens: completion goes up, not down. The user is never deciding what to do next, only what to answer.

It also makes the form honest. Branching becomes simple, because the next page can depend on the last answer. Progress becomes real rather than a bar you invented.

And every page is now small enough to read aloud, which is exactly what a screen reader does.

Step 3 of 9What is your date of birth?For example, 31 3 1980DayMonthYearContinueBack1 question, 1 page12
  • 1Real progress, because the route is known.
  • 2One question, in plain language, with an example.
The split. Drawn for this teardown, not a screenshot.
One thing per page

Each page asks a single question or makes a single decision. The cost is page loads. The gain is that nobody has to hold anything in their head.

What to take from it

The clever multi-column form is usually a designer optimising for the screenshot rather than the person filling it in.

03 The error

Errors that say what to do next

When one page holds one question, an error can be specific. A summary at the top, the same message next to the field, and an example of a correct answer.

Notice what is missing: no red field with a generic message, no scroll hunt, no lost answers. The user is told the problem in words they can act on.

This is accessibility and usability being the same thing, which is usually the case.

There is a problemEnter your date of birth, for example 31 3 1980What is your date of birth?DayMonthYearContinueError, then the field12
  • 1Summary first, linked to the field.
  • 2Tells you what good looks like, rather than that you are wrong.
The error. Drawn for this teardown, not a screenshot.
Error recovery

An error message has one job: make the next action obvious. Naming the rule is not the same as naming the fix.

What to take from it

Write the error message before you write the validation. If you cannot write a helpful one, the question is wrong.

Steal this, not that

What transfers to your product.

Split by decision, not by section. If a page holds two unrelated questions, it holds two pages.

Do not measure a form by the number of screens. Measure it by completion and by who drops out.

Write the question in the words a person would use out loud, and give an example.

Do not save errors for the end. Validate where the answer was given.

Test it on the oldest phone and the worst connection you can find.

Do not treat accessibility as a separate pass. The plain version is usually the better version for everyone.

Sources

Public commentary, written without involvement from GOV.UK. The screens are drawings made for this teardown, not screenshots, and nothing internal is claimed.

Sign in to keep this case study on your reading shelf.