https://designnotes.blog.gov.uk/2015/07/03/one-thing-per-page/

One thing per page

One thing per page

Yesterday we updated our guidance on how to design form content for services on GOV.UK. In the previous version we’d discussed the relative merits of three approaches:

  1. one question per page
  2. all questions on a single page
  3. single page, but previous questions are collapsed

Since then we’ve had a lot more experience designing services for the general public. We’re now confident that you should start with the first approach and split all your questions out on to separate pages.

The new guide goes into more detail about why we think forms work better like this, but to summarise:

  • low-confidence users find them easier to use
  • they work well on mobile devices
  • they’re better at handling things like errors, branches, loops and saving progress

Read the new guide

 

6 comments

  1. Tim Blackwell

    I've always liked one question per page:-

    - because it lets you be more conversational

    - because it gives the best opportunities for filtering

    - because it makes it easier to include contextual support from previous
    answers

    I maintain an application with a very large number of potential questions, of which several dozen might be asked in a typical consulation. Some years back we moved from strictly one-question-at-a-time to a hybrid approach with limited grouping. We did this because:

    - navigating around very long question sequences was overwhelming for users

    - it was sometimes easier for users to have subsidiary parts of a question on screen at the same time

    To illustrate the second point, suppose we need to know whether someone is in work, but also whether they're on sick leave, maternity leave etc.

    Users found (not sure how code will format, apologies)

    Q1 Are you in work [ 1a]

    :if pregnant_or_recent_birth: and on maternity leave [ 1b] /if

    :if has_sickness_or_disability: and off sick [1c ] /if.
    -

    easier to answer than :

    Q1) Are you in work?

    Q2) :if in_work and is_pregnant_or_recent_birth: Are you on maternity leave? /if

    Q3) :if in_work and has_sickness_or_disability: Are you on sick leave? /if

    and was less cumbersome than explicitly reminding users that they might be in work and off work
    because of sickness or disability etc, then duplicating text by asking the specific leave questions independently.

    Q1 Are you in work?

    :if has_sickness_or_disability: answer yes if you are in work but off work due to sickness /if

    :if pregnant_or_new_mother: answer yes if you are on maternity leave /if

    Q2..
    Q3..

    Procedural branching does not scale well for us as a filtering mechanism - especially when information is potentially required in multiple contexts. Declarative statements work much better - so that as far as possible questions are only asked at the point of use (ie the point where we fail to deduce something *without* asking a question). The trade-off is loss of narrative control over the dialogue - we use some procedural nudges in an effort to make the question sequence more natural. But it's far from perfect.

    Link to this comment Reply
    • Tim Paul

      Thanks Tim. We agree - whilst it's good to start with everything on it's own page, user research can help you identify opportunities for merging questions. Also - this technique shouldn't be used to mask the fact that you've got too many questions - which is why a question protocol is so important.

      Link to this comment Reply
  2. Joanne Schofield

    Hi Tim
    There's a counter-argument that one question per page is frustrating for a user because it takes time waiting for each page to load, the links between pages are often hard to thumb on mobile, it breaks the readers flow etc.
    Now people are more use to scrolling, have any of these points come out at user research?
    Thanks

    Link to this comment Reply
    • Joe Lanman

      Hi Joanne, thanks for your comment.

      I'm a designer at GDS, I worked on Register to vote, and now GOV.UK Verify, and we've researched the 'one thing per page' pattern in great depth on both.

      You're right, it's key that page load times are very fast when using this pattern - we try and make sure that's the case.

      We always make sure that the interface on mobile is easy to use - for example buttons are often full width, and we make sure to test this with users in the lab.

      On balance, we see many benefits in lab to using one thing per page, as Tim detailed in the article, and the linked guidance, and we'd encourage projects to start with this approach and see how it goes with your users in research.

      Link to this comment Reply
  3. Tony Barron

    The 'one thing at a time' approach probably works quite well in the example situation. Transfer it to dealings with, say, HMRC and it causes a problem for the respondent. Most people don't have a comprehensive summary of their finances immediately available, and each new question can lead to half a day rummaging through drawers and boxes to find mislaid (or probably put in a place that was too "safe") paperwork. (Remember how many days it took to fill in a paper tax return?) Maybe the best approach would be to provide a complete example form, or a list of questions, for viewing; so that necessary information can be gathered before the actual filling in stage?

    Link to this comment Reply
    • Tim Paul

      Hi Tony, thanks for the response. You're right - the scenario you describe is a very common one, and not just for tax services.

      We think that you can combine the approach described above with other design patterns that help people in that scenario though.

      We already have a pattern for summarising the information a user has provided, and many services on GOV.UK allow users to save and return, or to enter information in an order that's convenient for them.

      We're discussing some of this work on our wiki. Please, feel free to contribute if you'd like to.

      Link to this comment Reply

Leave a comment