Buttons

[davidhunter08]

What

Use this issue to discuss buttons used on the NHS App.

Related

NHS App design system Figma file
NHS design system guidance
NHS design system discussion
GOV.UK Design System guidance
GOV.UK Design System discussion

[davidhunter08]

Full width buttons

Team Frontier have been exploring making buttons full width on the NHS App for smaller screens (640px and below).

Mobile screen

Tablet screen

Next steps

Continue to test to see if:

• full width buttons are problematic for users with low digital skills
• users don’t actually see them as actionable things to click

[davidhunter08]

Accessibility notes

3.2 Touch Target Size and Spacing

The high resolution of mobile devices means that many interactive elements can be shown together on a small screen. But these elements must be big enough and have enough distance from each other so that users can safely target them by touch.

Best practices for touch target size include the following:

• Ensuring that touch targets are at least 9 mm high by 9 mm wide.
• Ensuring that touch targets close to the minimum size are surrounded by a small amount of inactive space.

3.5 Placing buttons where they are easy to access

Mobile sites and applications should position interactive elements where they can be easily reached when the device is held in different positions.

When designing mobile web content and applications many developers attempt to optimize use with one hand. This can benefit people with disabilities who may only have one hand available, however, developers should also consider that an easy-to-use button placement for some users might cause difficulties for others (e.g. left- vs. right-handed use, assumptions about thumb range of motion). Therefore, flexible use should always be the goal.

Some (but not all) mobile operating systems provide work-around features that let the user temporarily shift the display downwards or sideways to facilitate one-handed operation.

[michaelgallagher]

i asked about this over in the community backlog a while ago

[davidhunter08]

Button sizing

Current sizing of the NHS design system button.

From screen size width 641px

Height = 60px

• Border (2px top and bottom) = 4px (transparent to make visible in forced colours modes)
• Padding (12px top and bottom) = 24px
• Line-height = 28px
• Box-shadow (bottom) = 4px

Width

• Border (2px left and right) = 4px (transparent to make visible in forced colours modes)
• Padding (16px left and right) = 32px
• Text length = unlimited

Until screen size width 640px

Height = 48px

• Border (2px top and bottom) = 4px (transparent to make visible in forced colours modes)
• Padding (8px top and bottom) = 16px
• Line-height = 24px
• Box-shadow (bottom) = 4px

Width

• Border (2px left and right) = 4px (transparent to make visible in forced colours modes)
• Padding (16px left and right) = 32px
• Text length = unlimited

[Tosin-Balogun]

Secondary or low priority CTA

I would add this here regarding the use of secondary buttons because I think it will become particularly relevant to the app in context where there is a promo but a primary button isn't appropriate.

The current secondary had less design effort compared to the primary and it has weaknesses around versatility across different context, plus when paired with the primary, it is relies on colour alone to make the distinction of hierarchy between them.
nhsuk/nhsuk-service-manual-community-backlog#417

[Tosin-Balogun]

Prescriptions and medicines use buttons in several of their prototypes

[growe88]

Sticky CTA's

For the past few months, our team has been experimenting with Sticky CTA's, i.e. buttons which remain in a fixed position within the app viewport as the user scrolls up/down a screen. We have been exploring types of screens they may work well, as well as situations in which they would not be suitable.
/
important note: as part of the NHS App visual uplift work, we are now using full width, edge to edge buttons for all CTA's on mobile breakpoints.
/
Some of the perceived benefits of fixed CTA's would include:

• Accessibility (touch target): by locating the primary CTA above the bottom nav, part of the button should always fall within the ideal thumb touch-target for users (both right and left handed). This is enabled by our addition of full width CTAs.

• Accessibility (next step always visible): when the primary action for the screen is pinned to the bottom nav, it is always visible to the user, without having to scroll below the fold to see where to progress. This allows users to build up stronger mental models.

• Expectation: users should be able to build up mental models of knowing where to continue a flow. This would be particularly useful for long, repetitive forms with limited content on each page.

• Modern interface: Sticky button's are a fairly commonplace pattern found in many native experiences (think Trainline, Monzo, Uber, Instagram, Strava, End etc.). Use of this pattern should feel intuitive to users, as well as assisting the UX in feeling more like a sleek, modern experience.

• Use in a Bottom Sheet component: it is a fairly standard pattern to use a sticky button within a bottom sheet (tray) component. Since the sheet would act as an overlay, covering up the bottom nav, the CTA would be pinned to the bottom on the screen.

/

Potential drawbacks of fixed CTA's would include:

• Screenreaders: this could prove a complicated pattern to optimise logically for use with a screen reader. Would it read the CTA last and treat it as if it's at the bottom of the content or not? This would require more research.

• Autonomous clicking of the button: for longer, more repetitive flows which don't require much deeper thought, we run the risk of users clicking the CTA before interacting with/absorbing the content which is on the page. This would result in an error state and hint text explaining what the user needs to do.

• Users progressing through pages prematurely: pinning the CTA to the nav means that on longer pages, content could be nested below the fold earlier, and even skipped past. This is of course something we would want to avoid.

/

Potential step-around
A possible solution to the possibility of people clicking the sticky CTA and missing content below, could be to add an inactive state to the CTA itself. This would allow designers to disable the CTA until the user has interacted with the page (eg. scrolled to the bottom of the content, or selected one of the radio buttons). We could still find a way to feature hint text if users click the inactive button. My hypothesis is that this would reduce the autonomous clicking of the Primary CTA on the page without any deeper thought.

/

Conclusion
As it stands, we are still toying with the pattern and would like to experiment with some user research. If anyone has any thoughts about this, please feel free to comment below or reach out. And if you think this could be a useful pattern for your screens, we'd love to chat about that too!

/

Useful links:

• https://uxdesign.cc/things-to-consider-when-designing-sticky-ui-elements-10aef22dac3d#:~:text=A%20sticky%20element%20is%20anything,as%20someone%20navigates%20a%20page.

[davidhunter08]

Button group example:

[michaelgallagher]

what do we think about outline buttons?

we've had feedback from users that the standard secondary button looks like it is deactivated.

a outline format might be a way to avoid that impression while providing a button that isn't as emphatically THE MAIN THING as the big green button.

[davidhunter08]

An outline button was recently tested on a load more pattern for booking a gp appointment. [insert findings here]

[michaelgallagher]

follow up about the image above: should the bottom edge of the button be thicker, so that it is more like the standard filled button, which simulates a 3D effect with the darker bottom edge?

[davidhunter08]

follow up about the image above: should the bottom edge of the button be thicker, so that it is more like the standard filled button, which simulates a 3D effect with the darker bottom edge?

yeah, I think it does - that will also make it sit well next to a primary button (if used together in a button group)

[davidhunter08]

Possible options

1. NHS blue border + NHS blue box-shadow

2. NHS blue border + darker box-shadow

3. NHS blue border (no bottom border) + box-shadow

[davidhunter08]

Option 2 with states

:hover

:focus

:active

[michaelgallagher]

@davidhunter08 i would think option 1 makes the most sense for colour (because it is the most direct), but option 3 makes the most sense for size (so the bottom edge is the same height as the bottom edge on the primary button). not sure how you do that!

also, bit of a curveball: are we willing to consider proposing increasing the size of the bottom edge and/or corner radius for all buttons?

the rationale here is

• the 3px bottom edge that is standard on buttons doesn't give us much to work with to create the visual effect of the button being 3D if the border is 2px
• outlined buttons look like they have a sharper corner because the inner edge is quite tight, and that is what the eye focusses on.

some tests...

[davidhunter08]

Note: Current NHS button attributes

border: 2px solid rgba(0, 0, 0, 0);
border-radius: 4px;
box-shadow: 0 4px 0 #00401e;

To achieve the same size (height) buttons we need to adjust either the border or box-shadow values.

If you have a bottom-border-color: transparent on the outline button, you get a weird looking edge:

If you have bottom-border-width: 0 with a box-shadow: 4px, the button height is 2px shorter than the primary button:

Increasing the the top and bottom padding by 1px each solves that problem and makes the buttons the same height:

But for some reason, in a button group, it misaligns them by 1px 🤔 so I need to look into this.

[davidhunter08]

nhsuk/nhsuk-service-manual-community-backlog#417

[Tosin-Balogun]

@davidhunter08 Have a look at the way I implemented it on Start for life here

The design spec on Figma here
https://www.figma.com/design/3GWK5Kbv5G88L8aKoPBHqd/Start-for-Life-prototypes?node-id=816-3525&t=FlZoluk1DRYpBa9n-4

The actual working code on the 'sign up for newsletter' section

https://www.nhs.uk/start-for-life/

Detail

In terms of the box shadow, I had to remove this because it was overlapping behind the transparent background, what I did instead was to use a 4px border bottom to create that shadow look.

I also reduced the border opacity of the default state to allow for the animation transition when a user hovers or clicks it so it gives that instance feedback that it's an interaction element. In addition, I added a tinted blue for the background when hovering or selected, as well as change the font weight to be default when selected

.s4l-button {
    background-color: transparent;
    border: solid rgba(0, 94, 184, .35);
    border-width: 2px 2px 4px 2px;
    color: #005eb8 !important;
    font-weight: 600;
    box-shadow: none;
}

.s4l-button:hover {
    background-color: rgba(0, 94, 184, .05);
    border: solid #005eb8;
    border-width: 2px 2px 4px 2px;
}

.s4l-button:active {
    background-color: rgba(0, 94, 184, .05);
    border: solid transparent;
    border-width: 2px 2px 4px 2px;
    box-shadow: 0 0 0 2px #005eb8;
    font-weight: 400;
}

Reference

nhsuk/nhsuk-service-manual-community-backlog#417

[MaryHarmon-ID]

Research findings for secondary buttons

For the Proxy application service, we trialled use of a secondary button on a screen where users could choose from two different actions:

1. Accessing services for someone else where access had already been set up
2. Apply to access services for someone new

Moderated usability research with 10 participants showed that the secondary button was not easily identified as the option to select to continue with a new application. This was mainly attributed to the grey colour.

I'm checking for further findings on this and will update further if more comes to light.

[katydlmh]

Research findings for buttons

Source - NHS Wayfinder usability testing, May-July 2024. We tested new components in the NHS design system as part of our design system uplift work.

1. Full span buttons

Finding: Patients found full span buttons clear and straightforward. They were recognised immediately as buttons and patients were able to move easily through the screens.

2. Button/link assembly component

Finding: Patients recognised two distinct but related actions they could take and had no difficulty in finding both or either option.

[davidhunter08]

Secondary button

Design hypotheses

We've observed that users are hesitant to select the secondary (grey) button as they perceive it to be inactive/disabled
If we change the colours of the secondary button
Then users will perceive the button to be active/selectable
We’ll know this is true when we no longer observe users hesitating about whether to click the secondary button

We've observed that the visual hierarchy of the primary and secondary buttons is unclear for people with monochromatic vision
If we change the colours and add a border to the secondary button
Then there will be a clear visual hierarchy between the primary and secondary button for all users
We’ll know this is true when users can describe the two types of buttons as having different levels of importance

Design

Desktop

Mobile

Coded examples

View coded examples (u: app / p: redesign)

Next steps

1. Test the design hypotheses
2. Document findings

[anandamaryon1]

@davidhunter08 This looks really good and something I've wanted to resolve in the service manual design system, any idea on when this will be tested? I'd be keen to get it straight into nhsuk-frontend rather than only the app, if that's possible.

[davidhunter08]

@davidhunter08 This looks really good and something I've wanted to resolve in the service manual design system, any idea on when this will be tested? I'd be keen to get it straight into nhsuk-frontend rather than only the app, if that's possible.

Hey @anandamaryon1, we're currently planning the user research for this, it's looking like it'll be in-person in Leeds on the 13th and 14th November.