Question page

[govuk-design-system]

Use this issue to discuss this pattern in the GOV.UK Design System.

[la5942]

Should there be additional guidance/linked guidance to confirmation page or a final page for question pages? I think it's really important for the user to know when they have finished a process and what they can do next.

e.g after the feedback questions once you have logged out of a digital service you are presented with a thank you page. It is neither a confirmation page nor a question and in my opinion doesn't quite close the user journey.

[antimega]

Should we mention not auto-tabbing on entry in text boxes? It seems to be in the date component (but not pattern page) but feels more like a general design principle for question pages.

[nickcolley]

When we break questions into many pages (or one thing per page) we increase the risk of a bad network breaking a user's journey.

As we all know, staff hate waiting for anything to load as rubbish equipment and network latency already slow everything down. So we use conditional reveals in a few places rather than loading different views.

alphagov/govuk-frontend#754 (comment)

There are things we could consider here technically, has anyone else seen any examples of where too many views are frustrating for users on slow connections?

[abbott567]

Just to elaborate on the comment that @nickcolley quoted:

We're building a lot of services for staff in DWP. The equipment Civil Servants have to use isn't great. They use thin clients with a streamed desktop. The majority are Windows 7 with IE9.

When using a streamed desktop with Windows 7 and IE9, the equipment itself is pretty slow. Particularly because the staff often have to have several legacy systems open and have to keep switching between the windows.

What we've found is even when we integrate with a legacy system, it doesn't always speed anything up. Sure, the staff have to switch between windows less so it slightly reduces the processing power of the awful equipment and the time to orientate themselves in the new window. But, there are so many layers of security that by the time you bounce an API call through all the firewalls etc the latency is still several seconds between pages.

So, we've ended up chunking a lot of information. For example, rather than have a page for the clamant's name. Then a new page for their date of birth etc. We just have one page with 5 or 6 fields titled: Claimant details. So our one thing per page is more one theme per page.

We also rely a bit more on conditional reveals. For services that citizens use, I'd avoid them as much as I could and fork the journeys between page loads. But because of the latency we know we'll have we do reveal the content a little more on the fly.

There is little we can do to impact the latency, as it's a technical constraint we didn't really pick up on when testing early prototypes on a Macbook. But we have found a nice balance between one thing per page and agents wanting to smash the screen in. 😅

Hopefully this all makes sense.

So, my caveat is that this is a staff facing service, it may not be relevant for anything citizen facing. But I would be interested in seeing more research on anybody with a poor or throttled connection.

[timpaul]

THIS is fascinating. Designing for the real world. It would make for a really good blog post.

[mikeash82]

@jennifer-hodgson commented on 27 Sep 2018

We suggest that there is a need for extra guidance as regards the content design of questions, that is: to guide designers to ask direct question to elicit information, rather than just naming input boxes, whether or not to have the question in the h1, etc.