Are we confident that this pattern has had enough testing across a range of services to be sure this is the best way to solve this problem? – Would different approaches work better for different combinations of sign-in methods or services?
That sounds good. It might help to add a bit more clarity as to how confident we are with these if this content is being shared more widely.
Rather than having several pages confirming that details are correct, could we just play back all the users data on a single page and have some kind of ‘Yes, these are correct’ option at the bottom and ’Change my name/DOB/address’ options beside the data, similar to the examples here? – presumably the majority of users data will be correct, so it might allow many more users through with a few fewer clicks.
Does allowing the user to change their own details open up opportunities for fraudsters to Verify themselves at one address and then use a different address to get a permit wherever they want? Also, if they change their address, what happens to that data? Is it somehow fed back and updated on the IDPs side? Would users expect this to be how it behaves?
After this the user can continue with the rest of the service.
Doesn't feel like the right page for this, but just a thought about the process in the comment directly above: If you ask people to commit to honesty before the form, rather than after, it makes their responses more honest. I don't know if your service suffers from many fraudulent claims, but you might want to consider this if so. If the next action after that confirmation is to close the page and exit, it's a lot easier to do that than go back and correct any dishonesty.
Many users of services of GOV.UK will have characters in their names that do not fall within the A-Z latin alphabet. Examples have arisen whereby users have been unable to use a service as their name, containing either diacritics/accents, failed validation and prevented them from continuing.
Michael TAccept whatever characters the user inputs
Ideally we would accept whatever characters the user puts in, since by definition the name I give you is the name it's OK to use.
Or, request they match the name on an existing document
If you need a name that's used somewhere else, e.g. for identity matching services, be transparent and explicit about that (e.g. "Name, as given on your passport / We need this so we can check your application against our records)
If all else fails, anglicise names but be clear that this is whats happening
If you're dealing with a legacy system, anglicise names where possible without throwing up an error - e.g. "Björk" becomes "Bjork" (obviously some people are going to - justifiably - get annoyed about that, but might be the least bad option).
If we have a system that cannot accept certain characters - like the British Passport system - then we can do the hard work to convert the character to its transliteration and notify the user that that is what we are doing. They shouldn't have to do any extra work.
For instance, the International Civil Aviation Organisation (ICAO) have an internationally agreed list of transliterations (converting certain accents/diacritics into their closest A-Z equivalents) in the 'Numbers, Symbols and Punctuation Marks' section of HMPO's Names and changes of name document. It should be noted however that this is not an exhaustive list of all accents and different languages may transliterate characters differently. But should we consider building up a list of known diacritical/accent characters along with appropriate transliterations?
You may not be able to change what someone types in:
a) for legal reasons (non-repudiation)
b) because you may not know what caused the error, just that it was triggered
– Because of b, one team wrote an error that began "First name must only include letters a to z..." that explained what characters and symbols you could include. It tested OK but some people treat 'è' as 'e' so the error does not help them.
Use this section to draft guidance for the pattern. This will become the first draft of the pattern page when it's added to the Service manual, at which point it will be removed from this page. It's quite common for a single pattern page to describe a number of different approaches. We're using the following structure to document each approach:
Example: 1 line intro plus screenshot or HTML
Pros: What this pattern is good at and when to use it
Cons: What this pattern is less good at and when not to use it
Guidance: General guidance on implementing this pattern
A place to have a more general conversation about the pattern.
Examples on GOV.UK
Post images and links to examples on GOV.UK or prototypes
A section to talk more generally about research relating to this pattern