A Content and User Experience Strategy for local government

Form design is the one area of UX design strategy where following one rule can conflict with following another rule.

Think of each part of form UX guidance as a single target to aim for. But the goal, like in an archery competition, is to score as many points overall as possible. If following one rule closely would stop you from following another rule closely, or would harm the overall usability of the form, use your judgment to find a sensible compromise.

This page covers a lot of ground. I plan to split it into smaller pages in a future update, because I still want to add more to this area.

Question Grouping

The Government Digital Service (GDS) design guidance includes a principle called "One Thing Per Page". This same principle also appears in the GDS form design guidance.

But following the GDS form design guidance too closely often results in forms with 10 separate pages, one question per page. Users then have to keep clicking "Next" from question to question, instead of simply scrolling down one or two pages. This becomes very tedious for the user. So we should not follow this rule at all costs, ignoring other sensible UX points.

The underlying principle is still sound, though. We should group questions onto pages in a logical way. For example, an antisocial behavior report form can have one page of questions about the incident, one page about the victims, and one page about the person responsible. A flytipping report form can combine questions about the location of the flytipping and what was dumped onto one page, and put questions about witnesses onto another page.

Introducing the Form and Giving Guidance on How to Fill It In

When designing the introduction and guidance text for a form, think about two things. First, is this a form a given user is likely to use often, or only once or twice? Second, how complex does the form itself need to be?

Users who report flytipping, missed bin collections, or street faults are usually experienced users. They will need very little guidance. We should design these kinds of forms so that little or no guidance outside the form itself is needed.

These forms need no more than a short amount of introductory text on the first page. Following the Content Onion principle, a content page that leads to the form should put the link at the top, not below several screens of text.

It makes sense that a complicated form, such as a grant application form that needs a lot of information from the user, might need longer guidance notes to help the user give the correct information. If the user will need to go and find information they will not know from memory, such as their National Insurance number, or if they will need to photograph and upload copies of documents, tell them this before they start the form.

Once you have worked out what the user needs to have or know to fill in the form, follow this general rule: give any further instructions at the point the user will need to know them. Do not give instructions about page seven of the form at the beginning, and then expect the user to remember them by the time they reach page seven. If they do not need instructions for page seven until they get there, save those instructions for page seven itself.

I’ve written a blog post which goes into the rationale of respecting the competence of our users with the accompanying text.

Form Length

It helps users to know how much time they might need to set aside to fill in a form. Of course, this is always going to be subjective.

Progress bars can help with this, if they give an accurate and meaningful picture of the true size of the form and the user's progress through it. Progress bars with page titles — for example, showing that the "Your Details," "Alleged Perpetrators," and "Witnesses" pages are still to come — can reassure the user that the form is not as long as a simple page count might suggest.

Accurate-looking time estimates probably help the user less than you might think. Rough estimates work better:

• "This is a short form. It should take you no longer than a couple of minutes to fill in."
• "This is a medium-length form. You might fill it in over about 5 to 10 minutes."
• "This is a long form. You will probably want to set aside a good amount of time, and you may want to complete it in more than one sitting."

Estimates like these should work well for most users filling in most forms. Use user research to work out where these boundaries sit for your own situation.

Medium and long forms should always let the user save their progress and come back to it later.

User Contact Details

As much as is humanly possible, we should make our contact details collection standard across all forms. We should also keep it to a minimum.

Our default should be to collect only a name (in a single text box), an email address, and a phone number. I would lean towards asking only for an email address, but I accept that we should also ask for a phone number, since some users may prefer to give a phone number rather than an email address. Call this level of contact details collection "Tier 1 Standard Contact Details." These fields should only be required if they genuinely need to be required.

If we genuinely need to know where the user lives to provide the service, it is reasonable to ask them. In this case, it is also reasonable to ask, on a "Tier 2 Standard Contact Details" page, for the user's name split into first names and last name[*], and for two phone numbers, labeled "main phone number" and "second phone number" — not "landline" and "mobile," since these terms are out of date.

If we feel we must also collect a Title field, limit the choices to Miss, Mr, Mrs, Ms, and Mx, and no more. Adding any other title (even "Dr") to the list opens the door to complaints from people with less common titles, whose titles are also missing. It is worth asking: do we even need to collect a title at all?

[*] You can reasonably assume this is the default way of asking for names in this general UX Strategy for UK councils. But you should check, through user research in your own council area, whether a different way of asking for names would be more culturally appropriate for the people you serve.

Sometimes a service area will have a genuine need to collect extra, sensitive personal information that is truly necessary to process the request or deliver the service. This might include fields such as date of birth, National Insurance number, or gender. The service might assume these can be collected on the same page as the contact details. Call this "Tier 3 Contact Details." But collect these extra fields on a separate page from the Tier 2 details, since they are not standard fields — they are specific to that service. If there is a more suitable page elsewhere in the form to collect them, use that page instead. Otherwise, give them 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, and a blog post goes into more of the thinking behind this.

If you have an online account system, the first page of the form should invite the user to log in or register. Once the user has logged in or registered, send them straight back to the form. Any relevant details, such as their contact details, should then be pre-filled, and the user should be able to edit this pre-filled information. It is very rarely justified to make a form require the user to log in. Think about it this way: how would you take a report or a request from a citizen who phones you, instead of using a form?

People disagree about whether contact details should be collected on the first page of the form or the last page. One view says to collect them on the first page. This way, users get the "less interesting" information out of the way first, so they are less likely to skip it out of boredom, and can then move on to the important part having already given us their contact details. The other view says that since people came to the form to give us facts other than their contact details, we should let them start with the important questions first.

I suspect user research would not give a clear answer about how much users actually care either way. So the important thing is to decide which approach you will use, and stick to it. On the sample report flytipping form I've placed the contact details as the first page.

Consent to Do User Research

We want to know whether our users find our forms easy or hard to use. We are especially interested in why some users might start a form and then stop partway through — for both long forms and short forms.

I have heard and read many confident claims over the years about why people abandon forms. Almost all of these claims, however confidently people state them, are nothing more than guesswork. For example, someone might realize partway through a long grant application form that they are unlikely to be given a grant, just as easily as they might give up because the form or the process behind it is more complicated than it should be.

Why do we not just ask them?

If we ask for consent, as a standard question on the contact details pages, and we place the contact details capture as the first page, we can do exactly that. If the forms system in our content management system (CMS) stores incomplete submissions for a period of time, we can go back and ask the people who abandoned the form why they did so, as well as asking the people who completed it whether it was easy for them.

If we are not going to ask for consent to do user research, do we even need to collect contact details at all for many of our forms? When a citizen reports flytipping or a broken streetlight, and the details they give are not clear, do we realistically contact them again to ask for more information? If we have no need or plan to contact citizens as part of a two-way conversation, consider not collecting their contact details at all.

Required Fields

Some people believe that if a question is not genuinely required for the form to be processed, it should not be on the form at all — that a form should only ever contain required fields. I do not agree with this view. In local government reporting and service requests, there are many cases where extra information the user chooses to give will help the council process the report more quickly and effectively, even if that information is not strictly necessary.

You could argue that where a page has required fields, the "Next" or "Submit" button should stay hidden until the user has filled in all the required fields. But we need user testing before we can make that case with confidence.

I am experimenting with putting all the required fields at the start of the form (see the "Report flytipping" form), with a tickbox at the bottom of that page inviting the user to also give optional information on later pages. If the user ticks "yes," the form continues through the remaining optional question pages. If the user leaves the box unticked, the form skips straight to the last page, the contact details. It is too early to say whether this works well enough, on most forms, to recommend it as a firm rule rather than an experiment.

Field Length Limits

If you are thinking about putting a length limit on a text box, first ask yourself why you want to limit the user's answer in this way. Do you actually want to know what they have to say in answer to this question, or not?

But there are sometimes good reasons to give the user a limit to work towards. If so, describe that limit in words, or even in sentences. Do not say "1000-character limit" or similar — what does "1000 characters" actually mean to a user? Are you expecting the user to count characters in their head as they type, or to count every character in their answer after they finish? Users are also unlikely to sit and count words or sentences, but these are at least units of text that most users are used to thinking about.

Ideally, the text box in your web content management system's form builder would count words and sentences for the user in real time, as they type.

Locations

If you place a map on a form to let the user mark a point, make sure the user can easily scroll past the map with their fingers when they are using their phone.

If the form lets the user report something while they are out and about — for example, reporting a street fault or flytipping — remember that the user is unlikely to know the postcode of their location. They might not even know exactly where they are on a map of the town. So use their phone's GPS feature to find their location automatically.

If the form accepts a photo of the thing the user is reporting, consider working out the location from the photo's EXIF metadata (the technical information stored inside the photo file), and updating the pin's location on the map automatically.

Choice Fields

No part of forms UX guidance is more likely to end up contradictory than how we handle choice fields.

For fields where a user can choose more than one item, always use checkboxes. Never use multi-select dropdown lists.

For fields where a user can choose only one item, there is no fixed rule about whether to use radio buttons or a dropdown list. A good rule of thumb: if there are few choices, radio buttons usually work better. If there are many choices, a dropdown usually works better. If the choices are written as full sentences rather than single words, radio buttons usually work better. If the choices are single words, either style is usually acceptable.

If the person asking for the form wants a choice field with many long-sentence options, ask them to think carefully about how they arrived at this point.

List choices in a sensible, logical order. If the choices represent a sequence of actions, or a hierarchy of meaning, list them in that order. If the choices are just a simple list, put them in alphabetical order.

For yes/no choices, you may have your own view on whether "yes" or "no" should come first. But whichever order you choose, use it consistently across the whole site. My own preference is to put "Yes" first.

Choice fields should normally start with no option selected, so the user must make an active choice, rather than passively accepting a default. The exception is when a preselected default genuinely helps the user. If you are collecting data for the organization, it is better for a field to be left blank than for the submitted data to be wrong.

'Other'

Unless the possible choices are strictly limited, always include an "other" option, as the last item in the list. If you need information from the user, it is less of a problem for you to interpret an "other" answer by hand than it is to force the user to pick an answer that is wrong, just because their preferred option was not on the list. Only point the user to a separate "other enquiry" form if this is truly necessary.

Required Login

It is rarely helpful to the user to force them to log in to fill in a form. It is also rarely helpful to the organization. Because of this, only require login to a user account for a form where you can justify it as essential to process the report or deliver the request.

"But they might want to..." or "but we might want to..." is not a good enough reason to require login. "They will need to..." or "we will need to..." — backed up by evidence — is the only good reason to require login.

This point matters enough that it 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.