In the previous parts of this series we built a button from the ground up using design tokens and addressed accessibility concerns while making our button adjust to a wide variety of situations. In this part of the series we expand outwards as we add variants to fill all kinds of different needs that rise when designers start to use our button in actual user interfaces.
Fig. 1. Remember this little fella? Seems awfully lonely at the moment...
Styles
A common need in UIs is to direct the user’s attention by making some elements more prominent than the others. In the first part of this blog we went through how our button uses an accent color that really pops against the rest of the UI. But what about when we want a subtler button? It’s not like we always want to scream every button to the user as doing so would diminish the effect: when everything pops, nothing pops (except maybe the user’s brain). So, we need more button variants in our toolkit.
Fig. 2. From left to right: primary, secondary, and tertiary button.
In Fig. 2 we have three levels of emphasis for our buttons: a striking accent color for most important primary actions, a milder color for less important secondary actions, and a subtle tertiary style with just an outline for the least important actions.
The thing is, presenting these variants to three different designers, we probably get four different interpretations of what these levels of importance mean in practice and how they should be used in any given view. And that’s a perfect recipe for inconsistent UIs, which is in direct conflict with our goal of steering designers to create consistent user experiences.
Fig. 3. Which is the correct pair of button variants here?
Creating these style variants is only half of the job. The other half is the documentation that tells the designer how to actually use them. We have to accompany the components with clear usage guidelines. These variants could be accompanied with the following guidelines:
- Primary: The most emphasized action of a given view. One per view at most. (A modal window counts as a separate view.
- Secondary: Emphasized action in a set of actions when Primary style is not available. One per set of actions at most.
- Tertiary: Default button style.
That should be enough information to figure out the correct combination in Fig. 3.
And there are other kinds of style variants that might come in handy. Let’s add three more variants that address other common needs. (Fig. 4)
- Danger: A dangerous action that leads to permanent loss of important data.
- Inverse primary: Emphasized action on inverse backgrounds. One per set of actions at most.
- Inverse secondary: Default button style on inverse backgrounds.
Fig. 4. The rest of the button style variants. Inverse buttons are only used on dark backgrounds. Or light backgrounds in dark mode.
Sizes
Having different sizes of buttons is a no brainer. We might use a larger call to action button in a huge front page hero. Or maybe we need a smaller button so that we can fit many of those in a small space. We might not be sure yet what the actual use cases are but we know they will emerge at some point. So let’s use the power of foresight and and add bunch of sizes to accommodate those future needs. (Fig. 5)
Fig. 5. Sizes (by height) are multiplies of eight: 56, 48, 40, 32, and 24 points.
Now, as we just learned, we also need the usage guidelines for these sizes—we don’t want to end up with a mess where the button sizes are all over the place across different views. But how do we proceed if we don’t have any actual use cases in mind?
Here we stand at the crossroads that I often find myself in when building a design system. The big question is: what goes in and what goes out. There probably is a case to be made for all five of these button sizes (IBM’s Carbon Design System for example has a total of six button sizes) but our design system isn’t quite there yet. To avoid a the mess, it’s probably safer to err on the side of having too few options than having a lot of options with unclear usage guidelines. So, we downsize. See our revised button sizes in Fig. 6:
Fig. 6. It doesn’t matter how many, as long as it’s as few as possible.
And the guidelines:
- Large: Strictly for situations where “style is prioritized over substance”: call to action buttons in large marketing banners.
- Medium: Default button size.
- Small: Used in space constrained situations such as in tables. If unsure, use medium size instead.
Putting it all together
Let’s not forget all of those different modes and states we added in the second part of this series. With the two new button sizes, we must also consider how they scale on smaller screens, like we did with the medium sized button back then. Scaling is actually not that complicated: we can shrink the large variant a bit and leave the small one untouched as it’s already designed for small spaces. (Fig. 7)
Fig. 7. Size variants in different screen sizes.
With the size variants covered, let’s make sure our new style variants are compatible with all the states and modes. We brought in some new colors, but we haven’t defined how the new colors should behave when e.g. the button is hovered. Here’s a list of things still left unaddressed:
- Four different states: hover, press, focus, disabled
- Dark mode version and all of those states for that (five in total)
- Windows high contrast mode (another five)
With five new style variants, that makes 5 × (4 + 5 + 5) = 70 potential new manifestations of our button. Some of those are very straightforward (we could use the same disabled look for all style variants) while others could get a bit more involved (do we even try to represent three levels of visual hierarchy in Windows HCM?).
All of this sure seems like a lot of work to plow through. And that’s not actually everything—the loading indicator... and so on and so on. It’s a lot of combinations, and work, but there’s a silver lining: working with these large masses of permutations is streamlined immensely by the use of design tokens, as demonstrated in the previous blog post.
Fig. 8. Comparison of focus states in light mode. Most style variants go with the default black indicator ring but on inverse background style variants we switch to a white one.
In conclusion
I guess the takeaways are:
- Documentation is as important as the component itself. It is the key to achieve consistency across UIs designed by multiple designers and long timespans.
- If it’s difficult to come up with clear usage instructions for something, it’s best to leave it out of the design system.
- And maybe it’s best to keep things simple in general, if only for the reason that number of things we are juggling is starting to get out of hand.
In the final part of this series, we’ll stretch the limits of our component to a literal breaking point as we start playing with icons inside the button.
