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

[GrahamHNHSBSA]

User research finding from the NHS App in June 2024.

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

Awite David, long time no see. I'm back in the UK and with the NHS, once more. This time, the NHS BSA. On your point above about research finding the grey buttons in a disabled state. Whats your learning from this and might you have a recommendation? Or is this more something we should watch for?

[GrahamHNHSBSA]

Hey community, I'm wanting to use buttons within a table. I've been using link styles for these since the space is vertically narrow for the larger button sizes.

I'm designing for a internal team 'super user' who is savvy in the use of the tool I'm working on.

I really would prefer to use the default secondary button style as its better suited for a 'select' or 'cancel' buttons I need in my table. If I used the default style I would need to increase the table row space vertically to allow for the default button height.

Is there any designs or research that shows a secondary button appearing in a table row to give me some 'food for thought', please?

[davidhunter08]

User research finding from the NHS App in June 2024.

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

Awite David, long time no see. I'm back in the UK and with the NHS, once more. This time, the NHS BSA. On your point above about research finding the grey buttons in a disabled state. Whats your learning from this and might you have a recommendation? Or is this more something we should watch for?

Hey @GrahamHNHSBSA - good to see that you're back! On the NHS App we're currently testing a new design for the secondary button. Research findings should follow in a week or two!

[vickytnz]

I've been trying to use the inverted button on a hero image for a subsite. Something is off with the inheritance as the button does not maintain its background.

It would be good to have something like notify to have buttons work on inverted backgrounds

I can't find any examples of inverted text so can't be sure if it's the particular configuration i have or something with the button. As an aside the example below no longer has anything helpful:

White buttons on solid background colour are good on components like interruption cards where link text, primary and secondary buttons would be lost. (There's an example on the Your data matters service.)

as the example page is now a normal page with no inverted colours

[cjforms]

@vickytnz I'd be really cautious - the point of saying 'don't do it' - about putting a call to action in reversed polarity text (in this case, white on blue).

Seen so many examples in user research where people say the reverse polarity stuff as a banner / divider without really absorbing information from it.

At the very least, I'd strongly recommend a further call to action in the standard-text 'meat' of the page. Which suggests: why have two calls to action?

This exact context isn't too much of a problem because the intended users are all at least knee-deep, and probably much deeper, into being web specialists / digital people. But I'd worry about creating a precedent.

[vickytnz]

@cjforms the manual says that it is OK to do it and links to an example that doesn't exist https://design-system.nhsapp.service.nhs.uk/components/buttons/ , so this would mean reversing the guidance from 'do it' to 'don't do it'

All I know is that it's sort of available but breaking, which is even worse than nothing at all.

[cjforms]

Well, I disagree with the service manual here. Would be very interested to know whether there are any other examples "in the wild" and how they test.

Can we suggest taking this out and see what happens?

[frankieroberto]

@cjforms it’s quite a common pattern across the GOV.UK platform services - the GOV.UK Design System, GOV.UK Pay, GOV.UK Notify, GOV.UK One Login, GOV.UK Forms all do it.

That said, I too have sometimes found myself missing the button within the blue hero components on those pages.

The NHS App Design System has something similar. I think with the black text and shadow it might be more visible?

One to keep an eye on and do some research on though!

I think for the NHS Prototype kit we’d ultimately end up with 'Get started' as the first item in the horizontal nav, as well as being on the button on the homepage, so that might help mitigate?

[cjforms]

@frankieroberto very much agree with the 'keep an eye on'

In the case of the app thing, I'd say "just because you can doesn't mean it's a good idea".

There's a lot of text in that blue banner. I'd definitely want to move the text into the body of the page, and add calls to action after the text.

In this mockup, I've styled the call to action as a link because of lack of time and prototyping skills, and because I quite like it as a link. It would give me the option of having calls to action for each thing that you can do rather than one somewhat vague one.