Design Systems Hot Takes

Choose wisely

11 min read

If you believe in free-will, options are most likely a foundational aspect of your philosophy. Designers are responsible for presenting choices to users so that they may select the best option and advance toward a goal. Historically, we have introduced several patterns which support the ability for users to make a choice. In this exploration we will consider some common interface components and understand why we might decide to use one over another.

Ground rules

The abstract concept we’ll be focusing on is a group of similar items and the ways they can be presented and interacted. This means singular buttons and inline links aren’t included in this exploration.

The act of creating an option will also be avoided. Generally speaking, once the option is created, it’ll be included within the existing presentational group of options using one of the approaches described. An example of this might be creating a post category for use in tagging entries in a blog.

While important, this exploration will not be focusing on the curation of the content within an option. Certainly, poor choices in wording or inaccessible options will inhibit the user from making the best choice. The following exploration assumes options are well-crafted.

Definitions

The following patterns will be referenced throughout this exploration:

It’s also important to define a few terms used for accessibility:

Instant gratification

One of the attributes of making a selection is the immediate result of the interaction. Patterns that show new content based on the selection are commonly immediate. For example, navigational menus which redirect to new content should be instant. Buttons that update state like deleting a row of data are also expected to happen quickly.

This is in contrast to options which expect a user to make selections and then commit those selections in a final action. This is commonly form elements such as radio buttons, checkboxes and HTML selects. The user will choose these options but no updates to the larger system will be made until the user sends a final command. This is often the case for wizard experiences also, where the act of going to the next step submits the options selected before traversing further.

This means we can divide the patterns into some groups:

Full disclosure, I am a big proponent for clarity of intent. I believe links should have an underline and navigate to new pages, allowing for all the default behaviors an <a/> tag provides. Buttons should have visible padding and execute actions on the current page, allowing for all the default behaviors a <button/> tag provides. With that out of the way, there’s additional level of consideration for the difference.

Links (<a/> elements) are meant to be individual tab stops always. This means that if the link is meant to be navigational and sends the user to a new page, the user should be able to go to this element using just the Tab key.

For buttons (<button/> elements), this isn’t the case when prepared as a proper group of related controls. The group is expected to be a single tab stop. Once within the tab stop, a roving tabindex pattern is used to traverse the controls.

This is a good place to introduce the tab user interface pattern which commonly is treated to look like manilla folder tabs. If the tab interface you prepare expects each tab to be a navigational link that can be revisited using the browser’s URL bar, this means that each tab is an individual tab stop; as link behavior is expected. On the other hand, if each tab is meant to execute a command, thereby keeping the user on the same page, then the entire tab group is one tab stop with roving tabindex navigation. In this way the tab pattern can either act as a navigational menu (using links), or a button group (using buttons). The main decision goes back to the links versus buttons debate to decide which experience to use.

Let’s continue to group our patterns:

Confirmation follows form

Returning to the confirmational group, these are patterns most commonly found in forms. This aligns to the way which we would fill out paper forms by entering in all the information first before submitting.

One of the most clear indications of usage between these patterns of the group is between checkboxes and radio buttons. Checkboxes are meant for selecting more than one option, while radio buttons are used for selecting a single exclusive option.

Interestingly, the native HTML select allows for both configurations (using the multiple attribute for multiple selections). So the question is, why use the native HTML select when there are other patterns which more clear usage?

One of the properties of the HTML select is the limited amount of data shown. The element is restrictive to a word or phrase which represents the value for selection. The other patterns allow for much more information. In relation, the select only displays the selected value. This means that it is less likely that the user will review the selection since it requires extra interaction. Laying out all the options as checkboxes or radio buttons help the user consider all the possibilities. Additionally, the HTML select options are not bound to the page layout; its options will exist separately from visual flow. This supports the basis of using checkboxes and radios for options which need more detail from options that are concise.

Let’s break down the options one more time:

Flow

Here’s a visual representation of our decision tree:

  
graph TD
    A[Give user a choice]
    A --> B{Happens immediately?}
    B -->|Yes| C[Instantaneous]
    B -->|No| D[Confirmational]
    C --> E{Directed to new page?}
    E -->|Yes| F[Navigational]
    E -->|No| G[Functional]
    D --> H{Include considerations?}
    H -->|Yes| I[Verbose]
    H -->|No| J[Concise]

The flow chart above can help lead a path toward a decision by asking why…

Adding purpose to these decisions will ultimately support design decisions with clarity. You can be confident that the pattern chosen is the best one based on the answers to these questions.

Unavailable options

A pattern that may be examined is disabling an option. This could occur because the user hasn’t satisfied criteria or the system is not yet prepared to offer the option. Opinions vary about the decision of showing options that the user is unable to select. I believe the following questions can determine if showing a option as disabled is helpful to the user.

If the answer to the questions are “yes” then it may be appropriate to disable the option. However, note that disabled options aren’t detectable to screen readers and commonly lack sufficient color contrast. Providing the criteria for enabling the option will support these deficits. Vitaly Friedman goes into greater detail at Smashing Magazine.

To put it simply, if it isn’t important why include it in the experience? This segues into the next topic.

Abundant options

Presenting the user with too many options introduces a cognitive load and decision paralysis. As described by Hick’s Law, the more choices you present, the longer it will take to reach a decision. This might include halting the current flow to return to at a later time. In contrast, limiting the number of options will improve the user experience. While some patterns expect to provide dozens of choices (eg. country of origin), there might be better design choices to capture the same information (eg. text field filtering of the list).

Use empathy to drive your design choices and your users will be thankful.

Big four oh Colors don't solve problems