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:

[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.

[Tosin-Balogun]

Native buttons

I asked the developers for code samples of the native buttons which we use on the:

• Landing screen (Splash screen)
• Carousel
• Error screen(s)

For android

fun NhsButton(
    onClick: () -> Unit = {},
    modifier: Modifier,
    buttonText: Int,
    buttonBgColor: Color = White,
    buttonTextColor: Color = NhsUkBlue,
    buttonBgColorDisabled: Color = ButtonBGDisabled,
    buttonTextColorDisabled: Color = ButtonTextDisabled,
    buttonShadowColorDisabled: Color = ButtonShadowDisabled,
    buttonShadowColor: Color = WhiteButtonShadow,
    enabled: Boolean = true
) {
    val color = remember { mutableStateOf(buttonBgColor) }
    val focusedButtonTextColor = remember { mutableStateOf(buttonTextColor) }
    Box(
        modifier = modifier
            .background(
                if (enabled) buttonShadowColor else buttonShadowColorDisabled,
                RoundedCornerShape(4.dp)
            )
            .testTag("Button Shadow")
    ) {
        Button(
            onClick = onClick,
            modifier = modifier.offset(x = 0.dp, y = (-2).dp)
                .onFocusChanged {
                    if (it.isFocused) {
                        color.value = NhsYellow
                        focusedButtonTextColor.value = WhiteButtonShadow
                    } else {
                        color.value = buttonBgColor
                        focusedButtonTextColor.value = buttonTextColor
                    }
                },
            contentPadding = PaddingValues(top = 1.dp),
            colors = ButtonDefaults.buttonColors(
                containerColor = color.value, // Set background color
                contentColor = Color.White, // Set text color
                disabledContainerColor = buttonBgColorDisabled, // Set background color disabled
                disabledContentColor = buttonTextColorDisabled // Set text color disabled
            ),
            shape = RoundedCornerShape(4.dp),
            enabled = enabled,
            elevation = ButtonDefaults.buttonElevation(defaultElevation = 0.dp)
        ) {
            Text(
                text = stringResource(id = buttonText),
                style = MaterialTheme.typography.displayMedium,
                color = if (enabled) focusedButtonTextColor.value else buttonTextColorDisabled,
                maxLines = 1,
                overflow = TextOverflow.Ellipsis,
                modifier = Modifier
                    .padding(start = 32.dp, end = 32.dp, top = 12.dp, bottom = 12.dp)
            )
        }
    }
}

Comment from developer is "...continue button has different styling as compared to others. Basically some workaround added for Continue button to make the shadow aligned to Web, it's not a native behaviour....basically the button is wrapped inside a box component with shadow color as background. And some padding added only at the bottom. This is also a potential candidate for native UI discussion. FYI"

For iOS

Button(action: {
               // action on button tap
              }, label: {
                NhsText(content: Constants.continueButton, weight: .bold, size: .small)
                  .multilineTextAlignment(.center)
                  .foregroundColor(Color(red: 0.13, green: 0.17, blue: 0.2))
                  .frame(height: 20)
                  .frame(width: 88)
                  .padding(.horizontal, 24)
                  .padding(.vertical, 12)
                  .background(.white)
                  .cornerRadius(4)
                  .shadow(color: Color(red: 0.13, green: 0.17, blue: 0.2), radius: 0, x: 0, y: 3)
              })
              .padding(.vertical, 16)

// Code for above Green Button:

Button(action: action) {
      Text(content)
        .font(Font.custom(weight.toFontString(), size: size.rawValue))
        .frame(minWidth: 200, maxWidth: 350)
        .multilineTextAlignment(.center)
        .foregroundColor(foregroundColor)
        .frame(height: height)
        .padding(.horizontal, horizontalPadding)
        .padding(.vertical, verticalPadding)
        .padding(.top, topPadding)
    }
    .cornerRadius(cornerRadious ?? 0)
    .shadow(color: Color(red: 0, green: 0.25, blue: 0.11), radius: 0, x: 0, y: 3)
    .buttonStyle(CustomButtonStyle(isEnabled: true, backgroundColor: backgroundColor, foregroudnColor: foregroundColor))

[sarahcroninrodger]

Rationale & guidance migrated from the NHS App Figma library file

[Tosin-Balogun]

Initial exploration of the visual contrast with different background for the outlined button

[cjforms]

Please can I make a suggestion that we change from "having a button on a reverse background" to "not having a button on a reversed background".

See discussion: nhsuk/nhsuk-service-manual-community-backlog#7

[davidhunter08]

NHS App usability testing

On 13-14th November 2024 we took a HTML prototype to the NHS usability lab in Leeds.

Users:

• 6 people’s views obtained
• including 2 users with red-green colour deficiency

Findings:

• 6/6 recognised it across all the screens
• 6/6 no hesitation in using the button

Next steps:

• We have high confidence that the new secondary button design has clear hierarchy with the primary button, but we’d still like to test the two buttons side by side.

[katydlmh]

NHS Wayfinder have upcoming usability testing where we would like to test the new secondary button design. In our upcoming testing, we would like to test swapping the old secondary button (which we use in combination with a link) for the new, outlined secondary design in combination with a link. We will share the findings once it is complete.


We currently use Secondary button + Link assembly component to give users two distinct options. Our reasoning for using secondary and link rather than primary and link is that each CTA is equally weighted and one is not the natural next step over the other, which the green button may suggest. Is this logic used in other services or is primary button + link the default here?

Also, is the new button design available in Figma format?

[Tosin-Balogun]

@katydlmh I don't believe we have it on Figma yet, but will create one and publish it

[anna-rigo]

@katydlmh we've just updated the secondary button in our Figma kit.

Please make sure to update it on your Figma so that it reflects in your files.

Here are the steps on how to do it:

• Click File/Asset on the top left and then click on the ‘book’ icon
• Click ‘update’ on the secondary button

PS: The secondary button isn’t in the design system yet and we’ve added it to Figma for testing purposes.

[davidhunter08]

Button group example used on the timeout modal. Text (tertiary) link is bold with no underline.

[davidhunter08]

Example of a blue (login) button being used:

[katydlmh]

Wayfinder usability testing on new secondary button - December 2024

We found that the grey secondary button caused some participants to pause and question what their next step would be. The weighting between the two actions when using the button/link assembly was also not consistent - seen as greyed out or 'dull' by some or bolder and prompting action as the main CTA by others.
The new secondary button did not elicit the same response in the latest round of testing and 6/6 participants were easily able to identify the actions conveyed on the button.