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

Create accounts #41

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


5 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


This comment has been minimized.

Copy link

sanjaypoyzer commented Feb 26, 2018

Starting to just prod a little at the format of "help a user to...", I wonder if it's more helpful to think about how services "recognise a user" and then work backward from there to whether or not that I have an account.

To unpack that a bit, I think there's 3 variations of recognising a user:

1. Recognising a user once

This is kind of mentioned in this pattern, under "when not to use", but I think we should probably also link off to a dedicated page for this – We've had stuff called "Save & Return" before and we definitely something about this properly documented.

2. Recognising a user you've seen before

This is what the current pattern is talking about. What's missing here is that the user might already have some way to identify them without creating an account. FutureGov have written about the idea of asking users knowledge based verification questions, which is also one way that Verify identity providers prove identity. In other words, this would be another page in itself which would be linked to from "when not to use this" which talks about using data already held about a user to identity them.

Connecting your service to Verify is another way of recognising a user, and is probably the best option if the only data your service holds about the user is their name, address and date of birth. Verify will validate that this is the current user's details by cross checking it with other information the user holds that your service won't see. In Verify land, we'd call this "matching".

3. Identifying a user you've not seen before, so you can recognise them later

This is sort "pure" creating an account – When you have no information about the user, but you need some for them to use the service. In these situations, it's important to consider what information you need from the user. We should make sure we document the fact that you shouldn't be asking for more information from a user than is neccesary.

Again, Verify can help with this because of it will (potentially) give you only the information you need (if that information is name, address and DoB) without you having to see the additional information which is needed to verify that data.

Sorry for the big brain dump, just thought it might useful to get some of this stuff down!


This comment has been minimized.

Copy link

owenm6 commented Mar 1, 2018

@sanjaypoyzer We (mostly Matti Keltanen) have been doing a bunch of thinking about how and when to identify users.

We published a bit of guidance on this - but it needs work.

Was just talking with @timpaul about how to structure guidance as it's kind of an adult pattern with lots of child patterns about how to approach different types of authentication. And how it links up with the service manual who are also writing guidance on this.


This comment has been minimized.

Copy link

jonodrew commented Oct 12, 2018

Digital Marketplace are looking at how we can encourage users to use more complex and memorable passwords. I think it's a pattern that would have value if we could fold it into this one.


This comment has been minimized.

Copy link

jonodrew commented Oct 12, 2018


I'm proposing a pattern for encouraging users to choose more complex, more memorable passwords.


Explain why you think this should be added to the GOV.UK Design System.

  • What evidence do you have that it's needed by multiple services across government?

Patterns for user creation already exist, and multiple services ask users to create an account where Verify is too heavy-weight for integration

  • What evidence do you have that it meets the needs of the users of those services?

Cyberaware, a campaign by HMG supported by NCSC, recommends three simple words for users to generate strong but memorable passwords

  • Have you checked that it doesn't already exist in the GOV.UK Design System?

I have

Anything else

Include links to any examples, research or code to support your proposal, if available.


This comment has been minimized.

Copy link

timpaul commented Oct 15, 2018

Thanks @jonodrew - we do have related guidance here, but it's mainly focussed on not stopping users from choosing the kind of passwords you describe, rather than actively encouraging them.

Have you had any success on Digital Marketplace with encouraging users to create stronger passwords?


This comment has been minimized.

Copy link

jonodrew commented Oct 15, 2018

So this is interesting because it came from recommendations to cleave closer to the pattern. We're planning to use a blacklist, and there's a separate thread of what the content design should be for that[0], but we're also working on also providing actionable information to the user so they've got a better idea of how to make a better password.

No data yet. I'm not really sure how we could check, other than comparing hashes?

[0] If there's an existing pattern I'd really appreciate if you could link to it


This comment has been minimized.

Copy link

sanjaypoyzer commented Oct 15, 2018

I think it would be good for the Design System to be recommending a passwordless authentication system, via a unique link in emails. The security benefits are well documented nowadays and the less we are asking users to remember passwords that they barely ever need to actually use, the better.

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