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
Showing users how page content has changed over time.
Example: Service manual
Understanding when and why updates are made
Users are building their services to the specification of the guidance that the service manual provides. It is therefore important that when this guidance is changed or updated we clearly explain what has been changed, and why.
Research has shown that users have varying levels of interest in the updates to guidance, often depending on their role within the service team or the kind of guidance in question. We show two levels of detail:
a brief summary of the updates, including a one line description of the change (in the metadata at the footer of the guidance.)
an in depth view of the specific changes made with more background information (on a separate 'page update' page.)
This gives users enough information to make a discussion to either interrogate the update further and link though to the page update or be satisfied with the information in the description and continue browsing.
The more engaged users can then find out more detail in the 'Page update' page.
These pages document the state of the guidance on the date of the update, including a summary of the change, a detailed description of the reasons for the change and a preview of the actual changes from the previous version.
This stand alone page approach was taken as it allow us to easily surface more contextual information about the change. It should also be more clear to the user that they are not looking at the latest version of the guidance due to the considerably different page layout.
The method of displaying the diffs has so far tested well with users showing a strong understanding of the changes being displayed. We are still working on creating a rational for how to write the detail for the change logs.
Having explored a wide range of approaches to showing diffs (GitHub, Wikipedia, Google, etc.) and experimented with existing service manual content and updates, we are confident that the in-body comparison is more readable with our style of content and thus more effective than the side-by-side approach.
These update pages will only appear for non-minor (e.g. spelling errors, broken links etc.) updates which will be specified as such in the publishing process.
What exactly should be included in the explanation and descriptions of the updated still need to be nailed down. We hope to develop a clear rational for anyone publishing updates to the guidance to ensure the change log is filled out effectively as possible.