Tim PDon't rely on the visual difference between radio buttons and checkboxes
Many users do not know the difference between radio buttons and checkboxes.
Make it clear from the wording whether you're asking users to select a single or multiple options. For example, before a set of checkboxes you can add the text: "Select all that apply:"
Use a large, visible hit area where appropriate
A properly marked-up radio button or checkbox can be selected by clicking anywhere on the label, not just the control. However, many users do not know this and continue to try to click the controls, which are usually quite small. This can be particularly tricky on mobile devices.
To help with this we've created an alternative style for radios and checkboxes where the clickable area is bigger and visible:
This style isn't always appropriate, but can help when you've got a relatively simple form with a few options to choose from.
We have discovered that this background style doesn't help all that much. Many users with low digital skills continue to aim for the small target, failing to realise the purpose of the visible clickable area. Possibly surprising, many users with high digital skills do exactly the same. Please see more discussion below about using large targets.
Tim PIn general, avoid pre-selecting checkboxes or radios.
It can confuse some users, and you'll never know if they explicitly chose that option or just didn't notice the question. An exception is when the user is returning to a form they have previously filled out, in which case it should be in the exact state it was when they last saw it.
Remember 'none of the above'
If 'None of the above' is a valid option it must be explicitly represented - you can't un-check a set of radio buttons once one has been checked.
Align the options vertically
In general, align the options vertically as it makes them easier to scan. An exception is where you have binary choices with short labels, like 'Yes / No'. The convention here is for horizontal alignment.
Our current guidance is a dynamic width, based on the amount of text in each option. On GOV.UK Verify we're trying a fixed width. It means each option has more equal weight and predictable hit boxes, but the width is arbitrary - it doesn't line up with any other content.
On the Carer's Allowance service we tested a range of different styles for the active and hover states of radio buttons, none of which caused users to click the label instead of the control.
Only when we removed the controls did people start to click the labels:
Basically, we got rid of radios and checkboxes and replaced them with a kind of button. They tested very well - no-one hesitated to use them. I'm nervous about throwing away well-established elements, but I'm all for reducing the overall vocabulary of elements. What do others think?
The example above shows a nested radio button group within a selected parent radio button. Is this a suitable use of radio buttons that are by definition a list of mutually exclusive options? Does providing a nested group of mutually exclusive options inside a selected mutually exclusive option create additional complexity that will cause usability problems? It seems to work when there are no control icons, but how about when they are reintroduced? Is indentation of the radio button group sufficient enough to communicate what interaction needs to take place?
OK. I think we've learned a lot about radio buttons and checkboxes - Paul and I are planning some blog posts around things learned on Verfiy, looks like this would be a good candidate to start the series
(Can we get rid of the .gif above? It's driving me nuts trying to type and seeing it flicker !!!
Brian HRadio button testing at Student Loans Company
We tested radio buttons recently, for questions that have 2 options for answers. We have yet to adopt radios in the same way other exemplars have. This is what we found out when we tested them in our app:
Some participants encountered issues successfully selecting radio buttons. Their click wouldn’t register since the mouse was moving across the button during the action
Some answered questions too soon (after skim reading the question) and this caused them to:
Doubt their action and re-read questions in full
Refer to help text rather than reading the question
Change their answer before continuing
Ask moderator for help
The behaviour above has been observed before within our current app. However our test would indicate that using radio buttons exacerbated these issues.
It’s worth pointing out that we changed the labelling of our buttons for the test (example below) and our test sample was small.
I would be interested to hear feedback from anyone who has noticed similar issues using radio buttons.
Some services may need users to upload documents as part of their application. Where possible, services should avoid the need for users to provide separate documents - if it's evidence, could this information come via an API or another government department?
People’s mind states vary according to the task they are trying to achieve, from an office worker whose job it is to apply for export licenses to someone requesting the right to live and work in this country.
Different types of applications involve different sets of tasks, from those that can be completed quickly in one sitting, to those that require supporting documents to be prepared over a period of weeks or months.
The experience can be time-consuming and stressful, as one aspiring childminder put it, “It feels like you’re being judged rather than helped sometimes.”
During our research, we spoke to a government agency where over 60% of customer support is attributed to queries about application procedure.
Through listening, designing, testing and iterating we identified the following group of common needs that we have attempted to address through the task list pattern:
We collected and compared these examples. This involved discussions on mailing lists, speaking to the teams that designed them and sticking screenshots on a wall.
Examples of task lists
We did this for a couple of reasons. First was to check all examples were designed to meet the same user needs. They were.
Second was to find the most general pattern. We did that by comparing how the examples were the same as each other. Our reckon is that the pattern lies in how different examples are the same:
see all tasks in advance
group content into tasks by theme. For example questions about money
name of task describes itself. For example ‘give medical information’
suggest order to do tasks in
label tasks’ status . For example ‘completed’
edit answers for each task
All the tasks - the whole service
During discovery, whilst comparing other examples, we learned something important; users need to see all the tasks required to do something. Not just the online tasks, an overview of everything they need to do.
This meant a task list needed to include:
online tasks, such as 'book a test’
offline tasks, such as 'do training'
non-government tasks, such as 'get insured'
This got us thinking. At least from the point of designing it, a service is a list of tasks.
Iterating the pattern
We built prototypes with these similarities in the examples and in keeping with GOV.UK styles.
Then tested these prototypes with 34 users over 5 rounds of research. Users becoming childminders, learning to drive and transporting goods.
After each round of testing, we iterated the pattern.
These observations contributed to subsequent design iterations - such as enabling users to save and return to the service at a more convenient time, or reducing user’s cognitive load by splitting up task lists into sections.
At first tasks were just one unordered list:
Users were unsure what order to do tasks in or if some tasks could be done at the same time as each other. So we change this, putting tasks into numbered groups:
This made the page faster for users to scan and clearer what order to they must do tasks in.
Another iteration was to let users check their answers for each section. We found early on, users wanted to check their answers for each task as they went along. Not just before they submitted an application. We let them do this by clicking the link on ‘completed’ tasks, which they did intuitively:
— Email is the preferred option for formal correspondence, where students expect a letter (physical proof that they’ve done or are going to receive something).
— SMS is great for instant messages e.g. ‘You’ve just been paid’. Users are always happy to provide their mobile number; student finance is important and they have an expectation that we’ll send them updates.
— If you want to ensure you can email the user in 12 months time, don’t allow users to give .sch or .ac.uk email addresses. All students will have more than one email address. We’ve also discovered that some University’ email filters may mean your email may not actually reach the user! It’s doubtful that students will forget their University email address, biggest problem they’ll face is whether they can access it post graduation (timeframe for this varies widely).
Caroline JPeople with unstable lifestyles / poor people ...
if people are homeless or in and out of work etc then they may not have, or may not recall, email addresses.
if money is short then several people in a household may all share access to the internet and hence share an email address.
are more likely to have low digital skills
are less likely to have access to a computer
may not have an email address, may share an email address with other members of the household, or may have an email address but not know what it is or how to use it.
Also: even amongst those of us who use email regularly, we may not recall which email address we used for a service or remember all of our email addresses. Example: I had to look up a business email address that I use rarely, but had to resurrect this week because my primary email account suddenly took against someone and I didn't want to use my personal or government email for that particular discussion.