Published on | Prototyping: From UX to Front End — Medium Chris Lorensson

Button interactions can make or break the usability or accessibility of an application. Donning our IX and UX Designer hats, we’ll take a second look at designing button interactions to see where improvements can be made.

Open the Fiddle to see examples

Core Concepts

1. Design: Careful consideration for priority and state
2. Interaction: Duration, design metaphors and :active
3. Methods: Perceived brightness and contrast increase
4. Accessibility: Click targets and title text for accessibility

1. Design

Carefully design buttons to indicate priority and state throughout the interaction lifespan.

Design for Priority

As a designer, my sense of aesthetics tells me to keep uniformity at all costs, which is why the question of visual priority is always a battle. But for good usability, buttons must have easily‑distinguishable visual priority — especially for web apps because they tend to have lots of buttons. But the rule applies to pretty much all sites that have any type of navigation.

Buttons are usually the mechanism that enable the user to perform actions. For example, an online banking website will have buttons for navigation, but if the user wants to make a money transfer, the button for submitting that transfer should be prioritized above even the primary navigation buttons. Similarly, if the money transfer form has a reset button, it should not be quite as prominent as the button which submits the transfer, because we must assume the user intends to submit a money transfer. This might sound obvious, but it’s still a common mistake that’s made when designing buttons for online forms.

Simplicity married with consistency is the key here, so let’s talk about how this is achieved. (See the working Fiddle)

Navigation
Visual priority need not be so pronounced

Primary Button
The button that we want users to click/tap

Secondary Button
Here designated to actions

Tertiary Button
Lower priority than primary

Mapping Button Priority

Button priorities ideally will be ‘mapped’ upon completion of the Task Model, or at least in Flow Diagrams. I like to do this as a simple exercise which results in an additional deliverable or part of a functional or UI specification. Here’s an example of a tabular button priority matrix for an online banking site:

A tabular button priority matrix

Of course there are many more columns you could add depending on how much fidelity you wanted such as pages, technical navigation methods, navigation exceptions or even button design subsets, but a matrix like this would be useful for front‑end developers, designers, business analysts and UX-ers.

Standardize a Design Language

This means creating a consistency across the designs of each button, globally. For example, in my buttons, each has rounded corners, a drop‑shadow and a background gradient. The interaction lifespan of each button is also the same — utilizing either the preceived brightness increase or the increased contrast methodology (more on that later).

The base design of each button is simple, but we’ve also differentiated it from the rest of the page by adding a drop shadow and some texture in the background gradient. That wraps up creating our standard, but there are many design languages one could use for this. Simplicity is accomplished through standardization.

Be consistent

Being consistent in the use of each type of button sets and then reinforces our users’ mental model of the site, increasing usability. Our examples are built using HTML & CSS — so consistency is almost inherent. We’ve got a class for each style of button, but you could take it even further and have a default .button class which rounds the corners, adds the drop shadow and sets default padding or size. Building buttons using other technologies should follow the same principles where possible. Consistency is all about usage. In our example, we’re using a similar design for the primary navigation and the primary buttons, but we differentiate tertiary buttons, and we use smaller buttons for the ‘actions’ of our application. Since we’ve defined this usage pattern, we can use it to create consistency.

Navigation
Visual priority need not be so pronounced

Primary Button
What we want users to click/tap

Secondary Button
We’ve designated secondary buttons to actions.

Tertiary Button
Lower priority than secondary buttons

Button Interactions

Buttons transition from state to state. How this transition happens is a subtle (but important) element in the perceived quality of usability and responsiveness of our application.

Reference the Fiddle to feel the differences

Transitions

Transitions are an often‑overlooked detail in designing button interactions. I typically use CSS3 to design my buttons, but any type of front-end syntax will have its own quirks set by its default functionality. In HTML & CSS, I might tell the buttons to change background colors when in the :hover state, but by default the background color shifts instantly, which can feel clunky and sudden—especially if the contrast betwen the two states is high.

Transition durations

See the example Fiddle for reference

I use CSS3 transitions to mitigate this feeling of clunkiness by setting an animated transition duration of 0.1 – 0.15 seconds. This duration retains the responsiveness of the button but smooths out the clunky-ness of the default functionality. Test these transitions carefully, though. When the contrast between states is high, the animation doesn’t have enough time to work, making it feel as though the change is still instantaneous. The lower the contrast between transitions, the faster they should happen. But also be wary of long transition times — though they may look nice, they can also make the button feel slow to respond.

The goal of using transitions is to smooth out the sudden changes in contrast while maintaining the feeling of a responsive and a fluid experience.

DO craft your transition to feel responsive
DO get rid of any transitions on the :active state

DON’T let your transitions feel unresponsive
DON’T let the transition be too short, making it feel jolty.

Interaction Methods

Button states make up the button’s interaction lifespan. Each is carefully crafted to supply the most useful feedback.

Interaction lifespan Design Methods

Elements that interact all have a lifespan. A user clicks, drags, drops, sees, reads and does all sorts of useful things with them. If our interactions are design correctly, they’ll each have a useful amount of feedback that confirms to the user the system is responding as expected. So it’s not enough to just add a style to a button — we need to think about each state of the button and the in‑between places.

To do this, we examine each systematic state of the button, but we also think about transitions and ways we can use design to help the user develop a mental model (which we can then reinforce).

Here are two methods for designing a button’s interaction lifespan. These two methods are commonly used and easily recognisable, and easy for us to maintain. They’re not rocket‑science, but then again, isn’t it all about simplicity?

As you can see with each of these examples, as the button ‘ages’ with each stage of interaction, the contrast is always raising between the colour of the button background and the button title text. This practise further reinforces the progression and perception of progress.

Sometimes having very light‑coloured buttons is aesthetically necessary for a user interface design, but my personal preference is to try and always increase the contrast between the button background and the page background because it’s less likely to lose the visual click‑target definition. This is particularly relevant when the button is ‘floating in space’, and perhaps less relevant when contained in a ‘toolbar’ or similar.

Perceived Brightness

Perceived brightness is exactly what it sounds like — the perception that an element is becoming brighter when hovered — as if it is lighting up. Because we’re accustomed to lighting being used as indicators in our everyday lives, there is a built‑in perception that they are actionable. For example, buttons on the dashboard of modern cars are backlit, and sometimes lighting is even used to indicate an ‘on’ state, such as light switches in the home. We can take advantage of this cognitive precedent by employing the same interface metaphor in our button :hover states.

See the example in the Fiddle: The button ‘brightens’ as the user progresses further toward their goal: see, hover, click.

Contrast Increase

As perhaps the most commonly used method of indicating a :hover state, the method of increasing contrast is perhaps a more reliable method of indication, because by nature, increased contrast almost always is synonymous with increased readability.

See the example in the Fiddle: The button’s contrast increases as the user progresses toward their goal: see, hover, click.

Special Consideration for :active

Because the :active state is only active when the the mouse button is down, they tend to be shown only for a split‑second in most cases. This fact gives us a useful piece of information—it tells us that this is a state whose benefits could easily be missed by the user. So, given that most occurrances of the :active state are split‑second fast, how can we design the state so that the benefit is not lost?

I will typically design the :active state to have a slightly higher contrast difference than the difference between the default and :hover states, and more importantly, I always make sure to follow any conventions I’ve already set for the interaction lifespan. For example, if my button’s default contrast is 50%, and my :hover state’s contrast is 60%, then I will make my :active state 75‑80%, rather than 30% or 40%.

Using Contrast Increase
So if my button’s interaction lifespan employs the contrast increase method, the interaction steps go in this order:

See: 50%
Hover: 60%
Click: 80%

This method of linear interactions preserves any precedents set by previous states. To the user, the mental model is the higher the contrast, the closer I am to performing my desired action.

Using Perceived Brightness
If the perceived brightness method is used, then it might go the other direction:

See: 60%
Hover: 50%
Click: 30%

Of course when using the perceived brightness method, your :active state could go as bright as you like if it doesn’t jolt the interaction—for example, when your button’s interaction lifespan is getting lighter and lighter and it’s on a white background, even though you might not be increasing the contrast with the background colour, the perceived brightness is increasing which achieves the same effect. As you can see, whether the contrast difference is increasing or descreasing, the values are always flowing in the same direction. While I’m not suggesting this as a hard‑and‑fast rule, I’ve found it to be the most effective and intuitive method for designing interaction lifespans.

Button States

Button states represent each milestone in its interaction. For example, using HTML & CSS, buttons are systematically allowed :link, :focus, :hover, :active and :visited states.

Not all of these states are particularly useful, and some (like :visited) can actually be problematic because it was written into the HTML specification well over 15 years ago and web design has simply evolved past it. That being said, let’s take a look at some of the more common states.

Of course, since we’re talking exclusively about buttons, there are several ways these can be implemented in HTML code, including (but not limited to) <button>, <input type=”button”>, <a>, and even <object> and <canvas>. Though many are possible, not all browsers support the modern CSS pseudo‑classes on all elements for :hover, :focus or :active, so be sure to browser test your buttons.

:link (default)

The default :link state is all about visual priority. Users automatically assume that the most dense combination of contrast, colour, size and placement represents the gateway to their next step in whatever they’re trying to accomplish. For example, a user on an internet banking website may be intending to transfer money from one account to another. They will assume they need to somehow ‘action’ the transaction.

If this ‘action’ button is hidden away in a tiny, grey‑on‑grey contrast at the bottom‑left of the page, the user will become frustrated or else try some other button that looks like it’s a higher priority. No — you want to put that action button right below the form, and perhaps even to the lower‑right of the form to flow with the top‑left to bottom‑right typical gaze plot.

:hover

The :hover state is perhaps the most important feedback indicator of them all. It shows the user when an element is actionable—a crucial piece of information.

Traditionally the :hover state has been largely neglected, or else a rather shocking design difference has been applied. But there’s no need to shock our users—we can maintain the integrity of our brands, design and user experience by offering subtle‑but‑noticeable indicators.

:active

The :active state is the state the button is in when the mouse‑button is down. They can be an often overlooked stage in the interaction, but they can supply a very useful feedback since they essentially show a user when something has been successfully clicked.

.active (“down”)

The down state is typically reserved for navigation. It is used to indicate you are on this page or in this section — depending on your Information Architecture and Taxonomy.

Button Accessibility

Improve accessibility through the use of contrast for readability. Maintain usability by setting the right sized click target and writing simple, actionable title text.

Click Target

The size of a click target should generally be proportionate to the button’s priority — the bigger it is, the more important. Click targets can often be found in a standoff with design, so make sure to create a design language earlier rather than later. A design language combined with a button priority matrix should supply the information needed to properly assign click target sizes.

DO Match your target’s size and design to it’s functional priority
DON’T Make your target change position between states

When Priorities Change
Sometimes an action is more important in one context than another.

Real‑world example
When designing AlbumExposure, we came across this issue when it came to the album design presentations — the white‑labeled screen that designers show their clients — the photographer. This became an issue because our client presentation were our only page that could be white labeled. We had to give these photographers an indication that they had actually signed up for an account, and that they were now signed‑in. We decided to add a ‘My Account’ button to indicate this, but now we had another problem.

Our ‘My Account’ button already existed, though not on this white‑label page. The button had already been assigned a priority and a design. So how were we going to maintain the design of the white‑labeled page while also adding a button that had an existing priority and design? Our answer was to clear the clutter. We removed all other navigation items from the nav menu and added a ‘My Account’ button whose design would jive with any white‑label colours or logos. We realised that, in this context, a client wasn’t typically ever going to see the full navigation menu, and the priority was to retain our client’s branding integrity. So we didn’t need to maintain our brand, but the designer’s brand. That got the design out of the way and let us focus on the white‑label design.

Title Text

When it comes to writing the title text for the button, keep in‑mind that this text is what the user is looking for to successfully perform an action. This might be searching for cute kittens, or it could be dropping $1,000,000 for a MacLaren.

Keep it simple, sucka’ (K.I.S.S.)
Whether search for cute kittens or buying a McLaren online, that button had better do what it says on the tin, because sometimes it’s mission‑critical, but it’s always a make‑or‑break for the user experience.

Real‑world example
When working on AlbumExposure, we ran into a problem with our buttons. We had a button that was submitting comments and then emailing them. We had a hard time making it clear what the button was doing without over‑complicating it. We started out with “Send all comments: I’m done making changes for now.”

After a little UX brainstorming, we realised these were two different actions which should each be in the control of the user independently. So we split it into two different buttons:

“Add”, and then
“Send all comments”

This allowed us to keep the directions simple while providing more control to the user. While adding more buttons isn’t always the right solution, it was in this case because users were accustomed to using things like AOL Messenger and other chat‑like applications. We wanted to take advantage of this familiarity in our user interface, but ours had to work a little different. Splitting into two buttons was the step that enabled us to simplify the user experience. With buttons, they should always “do what it says on the tin.”

More information about button title text:

uxMovement on Why your links should never say “click here”

Button Design for Whitelabel Sites

I’ve designed three white‑label sites; one for Ascentric, one for Calorie Cloud and another for AlbumExposure. In each, the client had the ability to brand their version of the the site with a background colour and logo. This has strong implications when trying to design buttons that will support the integrity of their brand while remaining usable, beautiful and accessible.

While each design had its own set of underlying ‘engine’ code with varying degrees of capability, at the end of the day, the button has to look like it’s ‘at‑home’ with the rest of the site. The branding, colours and sometimes even style need to match in order to supply a truly ‘white‑label’ solution.

Technique for designing white‑label buttons

The best technique I’ve used is a combination of design that gracefully degrades and some system functionality that can change the design based on the branding. In situations like this, it’s always about treading a fine line between how much functionality should be coded into the system and how much ‘smart’ coding enables the design. The balance between the two should vary from system to system, so you’ll choose the best balance for your needs.

Here’s what could happen; contrast is lost with the matching bg colour luminance.

For the client presentations at AlbumExposure, we had to enable our client to input their logo and background colour into the system. We then built‑in an algorithm that reads the HEX colour value, then translates it into RGB values, then calculates the luminance based on the average capabilities of a typical human eye. This provided us with a luminance scale of 1‑10. We could then tell the system to serve up a different set of button styles based upon the luminance of the background colour.

Here’s what they look like now; the contrast is set to oppose the background colour, but still retain a little branding by allowing the user‑set color to show through.

If the client’s background colour was dark, we would serve up light‑coloured buttons. If it was light, we’d contrast it with darker‑coloured buttons. This balance allowed us to give a little more design and a little more system code to retain the great accessibility of the site while not creating a large amount of back‑end work for either the Development or Design departments.

Resources

Example in the Fiddle

Best Practices

Improve usability through creating a consistent design language
Differentiate priorities using a combination of size, contrast & placement
Raise contrast or perceived brightness for :hover and :active states
Smooth out transitions carefully
Collaborate with Development to cater for white‑label elements

Relevant Reading

Paul Olyslager on the design of call‑to‑action (or primary) buttons
Jacob Nielsen on Usability for Senior Citizens (see Readability and Clickability)
37Signals on Padded link targets for better mousing

Designing Usable and Accessible Buttons was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing Usable and Accessible Buttons

Cool stuff, every week

More Articles