A Content and User Experience Strategy for local government

If there is an area in UX design strategy where following one guideline can conflict with following another guideline, it's in form design. Individual components of form UX guidelines should be seen as individual targets to aim for, however the goal of an archery competition is to score as many points overall as possible - if in a particular circumstance following one guideline closely will compromise the ability to closely follow another guideline, or compromise the overall usability of the form, then use your skill to make a sensible judgement of compromise.

There's a lot to pack in on this page. Sorry. You might want to get yourself an invigorating beverage and a biscuit. Since I know there's more still I want to add to this area I am almost certainly going to split it out in a near-future revision.

Question grouping

The principle of One Thing Per Page in Government Digital Service design guidelines also extends into the GDS form design guidelines. Unfortunately in too many cases closely following the GDS form design guidelines results in forms which are 10 questions with one question per page, which the user has to keep clicking Next from question to question, rather than simply scrolling down one or two pages. This becomes very tedious for the user, so we should not follow this guideline at all costs to the exclusion of other sensible UX considerations.

The underlying principle is still sound, though. Questions should be grouped onto pages in a logical manner – for instance, an antisocial behaviour report form can have a page of questions about the incident, a page of questions about the victim(s), a page of questions about the perpetrator, etc. A flytipping report form can combine the questions about the location of the flytipping with what has been dumped on to one page, and questions related to any witness information on to another page. 

Introducing the form and guidance on how to complete it

Consideration should be given as to whether this is a form that any given user is likely to use repeatedly, or whether the form will be used only once or twice by an individual user, as well as the (necessary) complexity of the form itself when designing the supporting introductory and guidance content for the form.

Users who are reporting flytipping, missed bin collections, street faults etc will usually be the kinds of experienced users who will need minimal guidance, and indeed it should be possible to design these kinds of forms in such a way in which minimal guidance outside the form itself is even needed. There should be no need for anything more than sparing introductory text on the first page of the form, and according to the Content Onion principle a content page leading to it should have the link at the top, not below several screenfuls of blah.

It's reasonable that a complicated form, such as eg a grant application form which requires a lot of information from the user might need more extensive guidance notes to help them provide the correct information. If there is information the user will need to go and find which they're not likely to know from memory, perhaps their National Insurance number, or there are copies of documents they'll need to photograph and upload, then they should be informed of this before they start the form. 

Once you've established what the user needs to have or know in order to complete the form, the general principle to follow is to give any further instructions that might be necessary at the point the user will need to know - don't give them instructions about how to complete page seven of the form at the beginning of the form and expect them to remember that by the time they get that far; if they don't need the instructions for page seven until they get to page seven, save those instructions for page seven itself.

Form length

It's helpful to users to know what kind of time investment they might need to set aside in order to complete a form. The problem, of course, is that is always going to be subjective.

Progress bars can help with this, if the progress bars are going to be an accurate and meaningful reflection of the true size of the form and the user's progression through it; page titles on progress bars so users can see all the way through that there's the Your Details page, the Alleged Perpetrators page, the Witnesses page, etc, still remaining to complete can provide extra reassurance to the user that the form is not as interminably long as a simple page count might make it appear.

Accurate-looking estimates of the amount of time it might take to complete are probably not as helpful to the user as you might think they are, however, rough estimates saying:

• This is a short form which should take you no longer than a couple of minutes to complete
• This is a medium form which you might complete in about 5-10 minutes
• This is a long form which you'll probably want to set aside a good amount of time and maybe complete over a couple of sittings

should satisfy the majority of users' capabilities in completing the majority of forms. Establish what those boundaries might be for your own situation with user research.

Medium and long forms should always allow the user to save their progress to resume later.

User contact details

As far as is humanly possible, we should standardise our contact details collection. We should also minimise it.

Our default standard should be to capture just name (as a single text input box), email address, and phone number. I'd actually be inclined to say just email address, but I'm offering the concession of a phone number as well on account of the possibility some users might be more inclined to prefer to give a phone number than an email address. This level of contact details capture I would name a Tier 1 Standard Contact Details capture; these fields should only be mandatory if they need to be mandatory.

If we need to know where the user lives in order to provide the service, it is of course legitimate to ask them. In this case it can be legitimate to also ask on this Tier 2 Standard Contact Details page for their name expressed as First names and Last name[*], and for two phone numbers captured as main phone number and second phone number, not landline and mobile. It's 2024, not 1994. If we are culturally compelled to also capture a Title field, it should be Miss, Mr, Mrs, Ms, and Mx, and no more - any other titles (even Dr) in the list presents a wedge in which The Right Reverend Honourable Baron is given a legitimate complaint for their title not being included. Do we even need to capture a title anyway?

[*] This can be reasonably assumed as the default formulation for names in this, a generic UX Strategy for councils in the UK; you should establish through user research in your own council area whether a different formulation is actively desired by your citizens as being more culturally appropriate for your area.

Occasionally a service area will have a legitimate need to capture additional items of sensitive personal information which are genuinely necessary in order to process the request or deliver the service - fields such as date of birth, National Insurance Number, gender, etc - which the service might assume can be collected on the contact details page. This can be called Tier 3 Contact Details, but these additional fields should be captured on a separate page from the Tier 2 details; these are non-standard, service-specific details - if there's another page on the form design where it would be appropriate to capture them then that is preferred, otherwise they can be captured on their own page after the Tier 2 Standard page.

You can find the worked example of the Tier 1 and 2 Contact Details plus examples of additional Tier 3 fields on the example Standard Contact Details form. A blog post goes into more of the thinking behind this.

If you have some kind of online account system, the first page of the form should contain an invitation to login (or register). Once the user has logged in or registered, they should be redirected straight back to the form, and any relevant details - eg, their contact details - should then be prepopulated with the ability to edit that prepopulated information. Very, very, very rarely is it justifiable to make a form require the user to login. How would you take a report or a request from a citizen phoning up rather than using a form?

Opinion is divided as to whether contact details should be captured as the first page of the form or the last page. One view has to capture them on the first page because if the user gets the 'irrelevant' information out of the way first they're less likely to skip it out of boredom and they'll then get on with the important part having given us their contact details; the converse opinion has it that since people have come to the form to give us facts other than their contact details they should be allowed to crack on with the important questions first. I suspect user research would be inconclusive as to the extent users actually care one way or the other, so what is important is you decide which way you're going to swing and stick to it. On the sample report flytipping form I've placed the contact details as the first page on the form, in order to get...

Consent to do user research

We want to know whether our users find our forms easy to use or not. We might especially be interested in knowing why they might have started a form and stopped half way through - long forms and short forms alike. I've heard and read no end of confident assertions about why people abandon forms over the years. Almost all of it, no matter how confidently it is asserted, is nothing more than speculation - somebody could have just as easily realised they are unlikely to be awarded a grant half way through completing a long application form as given up because either the form itself or the underlying process is more complicated than it should be.

Why don't we just ask them?

If we seek consent as a default question on the contact details pages, we will be able to do that. If the forms module of the CMS stores incomplete submissions for a period of time we can indeed go back and ask the people who abandoned why as well as asking the completers if it was easy for them.

(If we are not going to ask for consent to do user research, do we even need to capture contact details at all for many of our forms? When a citizen is reporting flytipping or a faulty streetlight, if the details they provide aren't clear, realistically, do we get back to them to ask for clarification? If we have no need or intention to contact citizens as part of a two way dialogue with them, then consider not even capturing their contact details at all)

Mandatory fields

There is a view that if a question is not genuinely mandatory for the form to be processed, then it should not be on the form at all - that a form should only ever contain mandatory fields. I do not hold with this view - in local government reporting and service requests there are many circumstances where additional information the user might voluntarily provide will make it easier for the council to quickly and effectively process the report, even if the information is not strictly necessary.

A case could be made to say that where there are mandatory fields on a page, the Next / Submit button should not be revealed until all the mandatory fields have been completed. User testing is needed before that case can be established.

I'm experimenting with having all the mandatory fields at the beginning of the form, and at the bottom of that page having a tickbox inviting the user to also give the optional information on subsequent pages - if the user ticks yes, the form works through the remaining optional question pages, if they leave the box blank it skips straight to the last page, the contact details. It's too early to say whether this can be done sufficiently often on most forms to mark it here as a guideline rather than an experiment.

Field length limits

If you are imposing field length limits on text boxes, the first question to consider back is why are you suggesting curtailing the user's response in this way - do you want to know what they have to say in answer to this question or not?

But accepting that actually yes there are sometimes legitimate reasons for giving the user a limit to work to, express that limit in the form of words or even sentences. Do not say 1000 character limit or whatever - what does '1000 characters' mean to a user? Are you expecting the user to sit there counting characters in their head whilst they poke or type, or after they've finished go and count the individual characters in their response? Whilst users are similarly unlikely to be sitting there counting words or sentences, those units of text are at least units most users will be accustomed to thinking about.

Ideally, the textarea field of the form builder for your web content management system would do the word and sentence counting for the user in real time as they type.

Locations

If you're placing a map on a form to enable the user to put a pin on a point, ensure the user can easily scroll past the map with their fingers when they're using their phone.

If the form is to allow the user to report something when they're out and about - eg report a street fault or flytipping - remember that the user is unlikely to know the postcode of the location they're in, and might not even know where exactly on a map in the town they're in they are, so make use of their phone's GPS capability to autolocate them.

If the form is going to accept a photo of whatever it is the user is going to report, then why not see if you can determine the location from the EXIF metadata of the photo and update the pin location on the map automatically?

Choice fields

No aspect of forms UX guidelines are the guidelines likely to end up more contradictory than in how choice fields are dealt with. For multi-select choice fields, checkboxes should always be used, never multi-select dropdowns. For single-select choice fields, no hard and fast rules can be given about whether to use radio buttons rather than a dropdown, however a good rule of thumb is if there are few options to choose from, radio buttons are usually better, whereas if there are many options to choose from a dropdown is usually better; conversely, if the choices are labelled as sentences rather than words, radio buttons are usually better, if they’re labelled as words rather than sentences, either are usually acceptable. If the client commissioning the form is requesting a choice field which is many options consisting of long sentences, invite them to reflect on their life choices which have led them to this point. 

Choices should be listed in a sensible, logical order; if the choice represent some form of progression of actions or hierarchy of meaning, then the order of the progression or hierarchy should be the order of the options, otherwise if the choice is a simple list, then the list should be in alphabetical order. For yes/no choices, you may have your own personal opinion about whether the first choice should be yes or no, however that order should be decided on and consistently applied throughout the whole site. I prefer Yes to be the first option, myself.

Unless it’s in the interest of the convenience of the user to have a preselected default option in a choice field, choice fields should start off with no option selected with the user having to make an active choice rather than passively accepting a default choice - if you are collecting data for the organisation it will be better for the field to not be completed than for the submitted data to be false.

'Other'

Unless the possible choices the user might want to select from can only ever be a strictly limited selection, there should always be an ‘other’ option, as the last option in the list; if you need information from the user it is less bad for you to have to manually interpret an ‘other’ answer than it is to force the user to select an answer which is incorrect because their preferred option wasn’t present. Only if absolutely necessary should the user be signposted to a separate 'other enquiry' form in this circumstance.

Mandatory login

Rarely is it of benefit to the user to force them to login in order to complete a form, indeed rarely is it of benefit to the organisation to force the user to login. On that basis, mandatory login to the user account for forms should only be done where it can be justified as essential in order to process the report or deliver on the request.

'But they might want to...' or 'but we might want to...' is not a legitimate reason to require mandatory login. 'They will need to...' or 'we will need to...' - with supporting evidence to back up the assertion - is the only legitimate reason to require mandatory login.

It's a sufficiently important principle that this point is made twice on this page.

Examples

I'm still working out how to effectively use LocalGovDrupal webforms, and thus I've not made many yet in order to demonstrate these guidelines in action. So far I have:

• Apply to rent a BigTown Council garage
• Report flytipping
• Report a missed bins collection
• Tier 1, 2, and 3 Standard Contact Details example

More examples will be added in due course, and I'll update the existing examples as I become more familiar with this platform.