New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question page #58

govuk-design-system opened this Issue Jan 12, 2018 · 6 comments


7 participants
Copy link

govuk-design-system commented Jan 12, 2018

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

@govuk-design-system govuk-design-system created this issue from a note in GOV.UK Design System Community Backlog (In progress) Jan 12, 2018

@govuk-design-system govuk-design-system moved this from In progress to Published in GOV.UK Design System Community Backlog Jan 12, 2018

@timpaul timpaul added the pattern label May 21, 2018


This comment has been minimized.

Copy link

la5942 commented Aug 6, 2018

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.

screenshot-www tax service gov uk-2018 08 06-12-56-07


This comment has been minimized.

Copy link

antimega commented Aug 14, 2018

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.


This comment has been minimized.

Copy link

nickcolley commented Aug 20, 2018

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?


This comment has been minimized.

Copy link

abbott567 commented Aug 20, 2018

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.


This comment has been minimized.

Copy link

timpaul commented Aug 20, 2018

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


This comment has been minimized.

Copy link

mikeash82 commented Nov 29, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment