Skip to content
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

Question page #58

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


Copy link

@govuk-design-system 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
Copy link

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

Copy link

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

Copy link

@nickcolley 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?

Copy link

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

Copy link

@timpaul timpaul commented Aug 20, 2018

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

Copy link

@mikeash82 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants