Recommended updated Button Visual Design and Placement

[JessicaGentry]

Summary

The Carbon button visual design is not inline with current usability standards. The Carbon specification for button layout is not specified.

We are requesting a meeting to discuss this issue and the recommended solutions

1. Visual Design of Buttons

The Call to Action button (primary button) needs to have the highest point of contrast. Black on white creates the highest contrast possible (source:color theory), even higher than the Carbon brand blue on white (or light grey). This means the secondary button in Carbon has higher contrast than the primary button, which will cause user errors and reduce efficiency in using forms and dialogs.

The recommendation is to retain the primary button design and instead use the tertiary button design as the secondary button design. These meet usability guidelines and is consistent with many other Design Systems in the market as well.

Source: https://www.lukew.com/ff/entry.asp?571

2. Button Placement

Carbon doesn’t explicitly state guidelines for button placement in forms, only dialogs. The recommendation is to explicitly provide guidelines based on form design best practices for forms, wizards and dialogs.

Forms

Buttons should be left aligned under the form input fields, starting with the primary button on the left, and if necessary, the secondary buttons displayed in order of importance/usage to the right of the primary button.

Sources: https://www.lukew.com/ff/entry.asp?571 https://static.lukew.com/webforms_lukew.pdf

Wizards

In order to be consistent with the standard form design recommendation and leverage form design best practices, buttons should be left aligned under the form input fields, starting with the primary button on the left, and the secondary buttons displayed in order of importance or usage to the right of the primary button. For a Wizard this means using the Continue for the primary button, Go Back for the Secondary.

Source: https://www.lukew.com/ff/entry.asp?730

Modal/Dialogs

In order to be consistent with the standard form design recommendation and leverage form design best practices, buttons should be left aligned under the content, starting with the primary button on the left, and the secondary buttons displayed in order of importance or usage to the right of the primary button. The buttons should retain their affordance as buttons and not be stretched to the width of the dialog.

Carbon DS- The secondary button has the highest contrast and is in the location the primary button is expected to reside. The buttons are distorted losing their affordance as buttons:

Recommendation:

Modal/Dialog for Confirming an Irreparable Action

In order to be consistent with the standard form design recommendation and leverage form design best practices, buttons should be left aligned under the content, starting with the primary button on the left, and the secondary buttons displayed in order of importance or usage to the right of the primary button. The buttons should retain their affordance as buttons and not be stretched to the width of the dialog.

Carbon DS- The secondary button has the highest contrast on the screen and is in the location the primary button is expected to reside. The buttons are distorted losing their affordance as buttons:

Recommendation:

Resources

This recommendation is made in part of the Watson IoT Enterprise Design System Effort being carried out by Guidea working with: Erin Buonomo (ebuonomo@us.ibm.com) and Chris Reckling (chris_reckling@us.ibm.com) @creckling

[designertyler]

Copied from my email response to document here:

• Updating the secondary button's color to gray-80 is already in progress and will help with contrast ratio gap compared to the primary.

• The button placement is a debated topic and we've found arguments for either direction. The one that everyone agrees is that it should be consistent throughout a product and platform. We've checked with public cloud, Cloud Data and AI, Watson health, and Security and they prefer primary action on the right. The reasoning from WH and public cloud was, "Having the positive action on the right implies forward progress to the next step/stage of a user flow/task/or journey. The negative action (cancel or back) implies backward progress to the previous action or screen." and "... things on the right advance the workflow while things to the left move back or are destructive/negative actions."

It would be a large effort for those platforms to make that change and in the process would create inconsistencies and impact users already familiar that platform's norm. It would need to be evaluated if that cost is worth the benefit.

• The modal/dialogs full-bleed buttons were a decision mostly led by the brand team to have moments throughout IBM UI's that reinforce the new brand language. We haven't heard from teams that their user's struggling with the styling, but recognize the visual treatment isn't common. We can bring up any user feedback with the brand team to figure out a way to have a branded IBM moment in UI that doesn't impact usability. The team also cited Fitt's law and the benefits of the full-bleed buttons as larger target areas.

[jeoffw]

FYI, Patternfly recently updated their system to go with left-aligned buttons and primary on left, even in wizards. (Personally, I do think it's weird in wizards, but they do lay out pretty good reasoning.) https://blog.patternfly.org/patternfly/button-placement-on-forms/

Interesting comment by Cameron Britt at the bottom of that page:

Should we apply this same reasoning when considering how pagination should be laid out? As that student noted, going to the next page is “the action I most likely want”. Switching pagination controls around seems like pretty radical idea. While it makes some logical sense to do so, that logic ignores a deeply engrained idea that (at least for native readers of English) time flows from left to right. The past is to the left; the future is to the right. This left to right bias is not universal, (apparently Arabic readers have the opposite bias), but it accepted as a standard in UIs (viz. pagination).

[creckling]

my comments: Gray 80 is still pretty dark for a secondary button. I would add that the affordances in the modal do not look like buttons, which could cause errors, too. Has anyone tested this with users yet? I would separate out the pagination from button placement in a form issue. They seem like different use cases, where pagination is more like navigation.

I would love to see any data on the left or right placement rather than preferences. It makes sense to me to have the primary action in line on the left with the rest of the form fields.

[chrisconnors-ibm]

Button order: OK/Cancel or Cancel/OK? Nielsen/Norman Group have a great summary on this one. On one hand, "Listing OK first supports the natural reading order in English", on the other hand, "Listing OK last improves the flow, because the dialog box "ends" with its conclusion. Also, as with Previous/Next, you could argue that OK is the choice that moves the user forward, whereas Cancel moves the user back" These arguments have raged for 20 years (possibly more) because there's no clear winning or disqualifying argument to be made for either.

What they conclude though is twofold:

In cases like this, it often doesn't matter what you do. Either choice has good arguments in its favor, and no choice is likely to cause usability catastrophes. It might save some users 0.1 seconds if you pick the "right" choice for certain circumstances, but it's simply not worth it to conduct sufficiently elaborate research to find out what that choice is. Better to spend your usability resources on those things that can change your key performance indicators by 83% or more.

So, to make this specific choice — as well as many other small choices in application design — it's best to follow the platform GUI standard. Applying consistent design that follows user expectations saves people much more time (and many more mistakes) than doing something that might be a tiny bit more optimal for your application but introduces an inconsistency.

tl:dr; is this really the biggest issue your users will have to overcome, big enough to merit the investment we've already spent debating it, and specifically, the billing hours an agency logged litigating it, and two, it won't really impact performance so be consistent with your platform.

Our platform guidance, as adopted by dozens of offerings already in production, is the stated guidance: Cancel/OK, with the confirming action on the right. Changing this would either make work for all of those already delivered offerings, with very little if any benefit, or place your offerings in the position of being inconsistent with existing offerings. If an offering varies from this guidance, it should expect to be be flagged in a DUX review.

How bad is inconsistency? I sure notice it on Github: DropBox:

gmail:

[chrisconnors-ibm]

Full Width Buttons Our rationale here is two fold: one, the significant advantage increased size/shortened distances affords to target selection time/accuracy thanks to Fitts' Law, and two, as a design idiom, it's much more common now, and hasn't in production been the source of task failures.

The Interaction Design Foundation describes Fitts' Law as:

"Fitts’ law states that the amount of time required for a person to move a pointer (e.g., mouse cursor) to a target area is a function of the distance to the target divided by the size of the target. Thus, the longer the distance and the smaller the target’s size, the longer it takes."

It's a log relationship too, so the time (accuracy) penalty for reducing button size as proposed is significant. I could actually model it and do the math*, but can promise you that reducing target sizes by more than half while increasing the distance to target will significantly increase acquisition time.

The full bleed button also moot the arguments made above to justify the the buttons to the left since full justification is effectively left and right justification. the button pair is aligned left (as well as aligned right) in full justification. Additionally, in our Cancel/OK convention, the Confirm button starts at the center, not sequestered off to the far right (for modals)

In the intervening time I've started to notice similar idioms (where previously I hadn't really, I just clicked them and moved on): Notifications Alert, Chome: Locations access Alert, iOS So it's not even that novel an approach, and may even be approaching convention. Note also placement of the confirming action here on the right.

Users use a set of attributes to identify a button's intent including Label, Placement, and Color ahead of contrast ratio (which is why we haven't found the identification of which button is the confirming action problematic for people in practice), reconsidering the the color tokens used for the "Secondary Button" is certainly possible since that's what tokenization is for. Or, I think what is being suggested is that the 'Cancel' is a tertiary button rather than a secondary button? That's a specific area of iteration we could investigate with you, but honestly I'd be reluctant to commit scarce resources to it when we aren't seeing people struggling with it, on a hunch.

*I actually leave the math as an exercise for the reader :)

[mjabbink]

I’m still in favor of the full width buttons as well. Color is a different issue and we should solve for that to be accessible. The full width button allows for some unique nature although that is becoming less and less true since it’s quite frequent.

[JessicaGentry]

Uniqueness is not a characteristic we generally recommend striving for in a UI. Clear, Expected and Consistent and in line with current Standards are usually the desired traits we are going for.

[chrisconnors-ibm]

Full width buttons are not particularly novel. Guidance remains as stated with rationales above, and as embodied in the current components.

[wonilsuhibm]

Regarding the order, this is a slightly different use case, but on marketing pages, our research indicates that secondary / primary order is better than primary / secondary. Eg) Learn more / Buy. Research shows that while the order (secondary / primary VS primary / secondary) does not affect the conversion rate, users do not remember the secondary button in the primary / secondary order. So our suggestion is to use secondary / primary order.

[creckling]

You can close this issue. I will open another one around the secondary button color once we do some testing.