Buttons

[davidhunter08]

Use this issue to discuss buttons in the NHS digital service manual

[chrimesdev]

Saving these messages from Slack incase it ever gets deleted due to limit on free Slack.

Answer to "Why are the buttons 100% width on mobile devices?"

From Ben Cullimore:

Hey, I did work on buttons. We spoke to a number of designers and teams working on forms in the NHS (and wider) - many used the GOV.UK kit. A significant number of teams said that the full width gov button on mobile screens was problematic in user testing - it took many users time to realise it was a button (some thought it was a title, some the bottom of the screen). They found having the button sized by the text (as it is on desktop) worked better with users - cognitive and speed. With the text and button size - its by no means small, it still touchable. Due to size, hit area - font/padding on buttons; we haven’t seen any issues from a range of users with a range of access needs

From Andrew Duckworth:

We’ve found full length buttons to be pretty problematic on mobile for users will low digital skills. Some users don’t actually see them as actionable things to click. Rather headings or banners

[sarawilcox]

I'd be interested to know if NHS designers/ content designers are using the wording for buttons that GDS suggests:

Write button text in sentence case, describing the action it performs. For example:

‘Start now’ at the start of the service ‘Sign in’ to an account a user has already created ‘Continue’ when the service does not save a user’s information ‘Save and continue’ when the service does save a user’s information ‘Save and come back later’ when a user can save their information and come back later ‘Add another’ to add another item to a list or group ‘Pay’ to make a payment ‘Confirm and send’ on a check answers page that does not have any legal content a user must agree to ‘Accept and send’ on a check answers page that has legal content a user must agree to ‘Sign out’ when a user is signed in to an accountH

Has anyone tested/used alternative wording?

[davidhunter08]

For the button component guidance, is there anywhere we can add guidance for adding a form tag so people know how to make a button work? Or is that covered elsewhere?

Been helping a grad get started with the prototype kit and we're coming onto linking up pages but it's not clear from the button page how you'd make them work

[sarawilcox]

We're going to recommend "Start now" for our Start page guidance on buttons. But @cjforms has suggested that the button does not need to be called "Start now".

Rule of buttons: label buttons with what they do.

So a CTA button must relate to the service: Book now Apply now Check now

We could do with some examples of this which have been tested in services before including this in guidance.

[sarawilcox]

From Book your coronavirus vaccination service

In fact, there are 2 buttons on that page to allow people to book and to manage appointments. 2 different buttons for 2 journeys.

[jonhurrell]

Saving these messages from Slack incase it ever gets deleted due to limit on free Slack.

Answer to "Why are the buttons 100% width on mobile devices?"

From Ben Cullimore:

Hey, I did work on buttons. We spoke to a number of designers and teams working on forms in the NHS (and wider) - many used the GOV.UK kit. A significant number of teams said that the full width gov button on mobile screens was problematic in user testing - it took many users time to realise it was a button (some thought it was a title, some the bottom of the screen). They found having the button sized by the text (as it is on desktop) worked better with users - cognitive and speed. With the text and button size - its by no means small, it still touchable. Due to size, hit area - font/padding on buttons; we haven’t seen any issues from a range of users with a range of access needs

From Andrew Duckworth:

We’ve found full length buttons to be pretty problematic on mobile for users will low digital skills. Some users don’t actually see them as actionable things to click. Rather headings or banners

@chrimesdev Hi, any update on this? Did you override the mobile default widths?

[sarawilcox]

We're going to add a new section on stopping users from accidentally sending information more than once - in our next frontend and service manual release. Based on the section on the GOV.UK buttons component page.

[ZeldaRhiando-nhs]

Saving these messages from Slack incase it ever gets deleted due to limit on free Slack.

Answer to "Why are the buttons 100% width on mobile devices?"

From Ben Cullimore:

Hey, I did work on buttons. We spoke to a number of designers and teams working on forms in the NHS (and wider) - many used the GOV.UK kit. A significant number of teams said that the full width gov button on mobile screens was problematic in user testing - it took many users time to realise it was a button (some thought it was a title, some the bottom of the screen). They found having the button sized by the text (as it is on desktop) worked better with users - cognitive and speed. With the text and button size - its by no means small, it still touchable. Due to size, hit area - font/padding on buttons; we haven’t seen any issues from a range of users with a range of access needs

From Andrew Duckworth:

We’ve found full length buttons to be pretty problematic on mobile for users will low digital skills. Some users don’t actually see them as actionable things to click. Rather headings or banners

Fullwidth buttons don't work well on larger smartphones, where the aspect ratio can cause the button to very wide and thin - which increases users' confusion about whether the button is actionable or not

[vanessapereira-nhs]

On the Blood Pressure tool we are using full width buttons on mobile devices. We are following the same button pattern GOV.UK has for mobile.

We tested the tool with these buttons and it worked really well, users were able to clearly see the CTA and be able to click them without any issue.

__ GOV.UK responsive button:

Blood Pressure tool button example:

[andymantell]

We have been using full width buttons in our "legacy" codebase on 111 online for several years now and have yet to observe anyone encountering any difficulties with them. Of course this is an absence of evidence for a thing - if other people have evidence that some people struggle with them then it nullifies our lack of evidence.

Also worth noting that recently, as part of integrating with NHS login, we made the decision to tweak our new nhsuk-frontend styled pages to also have full width buttons. This was in order to make our old and new code more consistent, but also to be consistent with the buttons on nhs login which are full width.

The NHS App itself uses left aligned buttons. I think NHS login might be the main proponent of full width buttons - it might be worth catching up with the login team to explore their reasoning.

[cjforms]

Having done a lot of testing of forms and buttons, some thoughts. I'm talking here about users who are using vision, no matter how limited that might be.

Users look for 'the thing that might be the button', typically starting their search immediately below the left edge of the last field they filled in.

In the context of NHS- and GDS- style forms, the wide green or blue thing with reversed text is a plausible object on the screen that meets the conceptual definition of 'button'. Our screens typically don't have a lot of other distractions on them and our footers are typically discreet and do not interfere visually in the search.

It doesn't matter hugely whether the plausible object is full width or not, especially when it's the only plausible object available.

I'm not entirely convinced by full width buttons when the screen is landscape-oriented, that is where the width of the object is greater than the height of the available screen.

I have seen full-width buttons work in landscape mode for users who were long-term members of a market research panel, doing loads of very long surveys every week (sometimes dozens each week). But I have seen things work for this user group, because of the obvious training effects, that I think are implausible for our usual users (that is, people who are doing our forms occasionally or rarely, not constantly).

If the screen is portrait, then full width seems to be fine. The plausible object is narrow enough to "look buttony", and the extra small cues such as the rounded corners and the slightly darker bases of the button reinforce the 'buttony' appearance.

Would these cues be enough to make a full width landscape button work for our typical audiences? I don't know, and we don't need to find out because our buttons size to the text within them in this case - which I think is appropriate because it helps them to 'look buttony'.

[michaelgallagher]

re: full-width vs collapsing to the text size – has anyone seen issues with reachability on mobile?

one advantage of full-width buttons on mobile screens that i've observed in the past (not at the NHS) is that they are easier for (mostly right handed) people to reach with their thumbs. users don't need to adjust their grip to reach the button, which is helpful if they are on the move, semi-distracted while using the service, or have physical difficulty doing so (e.g. arthritis). the theory being that the wider touch-target area is advantageous from a physical / situational accessibility perspective – the trade-off being that it may, as described above, reduce recognisability.

[michaelgallagher]

for the "white button on a solid background colour", thinking about the visual logic of the primary and secondary buttons, where the bottom edge is darker shade of the main background colour, should the bottom edge of the white button be a pale colour?

[aviangel-NHS]

Dual action primary button

The primary button (green) will generally have one call to action eg "Start now". This is so that users don't get confused about what will happen should they click on it.

The current example is the NHS service manual has 2 actions - "Save and continue", despite this users will expect to see only one change, to go to the next page.

The CMS and Nav team have been working on a button that can result in 2 different results depending on the users circumstances. Log in or open NHS App button A working example can be seen on the View your GP health record page.

The button has 2 dual purposes:

• If the user clicks on the button on a device that does not have the NHS app installed they will be taken in the broswer window to the NHS Login page
• If the user clicks on the button on a device that does have the NHS app installed then the app will open.

This component was tested with users and there is evidence that users understood what to expect when selecting the button.

At the moment this button is used in combination with a secondary button, allowing users to also create an account if they do not yet have one. Since both button actions are clear, having a secondary button next to a dual primary button was not an issue.

[michaelNetCompany]

For the dual purpose button, is it possible to change the label so it displays content specific to the device?

For example, the app can only be installed on a mobile device, so if someone is viewing the button on a desktop, the label is only "Log in"

[anandamaryon1]

for the "white button on a solid background colour", thinking about the visual logic of the primary and secondary buttons, where the bottom edge is darker shade of the main background colour, should the bottom edge of the white button be a pale colour?

@michaelgallagher Yes I think that makes sense. So, using, say $color_nhsuk-grey-3, we get this: (Instead of the current:)

[davidhunter08]

User research finding from the NHS App in June 2024.

Grey colouring (of secondary button) suggests to users that button is disabled