Buttons

Buttons are the main component people use to take action in our products. For example, they let people create experiments, remove goals, and close dialogs.

OUI buttons

Button Styles

Our standard button style is a rectangular button that includes text, an icon, or both.

Primary Button

Use the primary button to highlight the primary call-to-action. There should only be one of these per screen.

Example

Example of when to use Creation buttons

Good uses include the “New Campaign” button.

Directional Button

Use the directional button to direct the user to other parts of the product, such as opening the editor.

Example

Good uses include the “Results” button in the Campaign overview, as pictured above.

Cancel Button

Use the cancel button to cancel an action. They're most commonly used to dismiss dialogs, but are also used in settings screens to discard any changes a user made.

Example

Example of when to use cancel buttons

Destructive Button

Use destructive buttons to confirm destructive actions, such as deleting a variation. Actions that are not permanent and can be un-done should use a Directional Button instead (such as pausing or archiving an experiment). By using this button style rarely, it’s more impactful when we do use it.

Example

Example of when to use Destructive buttons

Default Button

Use the default button for neutral actions that don't need to call attention to themselves.

Inactive (Disabled) Buttons

Use Inactive (disabled) buttons when the user cannot take any action (such as when a form is incomplete).

Button Sizes

Buttons can be one of three sizes: Normal (default), Small, and Full Width.

Small

Use small buttons for secondary or tertiary actions that need to be fit into a constrained UI. A good example is the “Save & Apply” button in the editor's code box. Choosing to use a small button is partially an information architecture decision, and partially an aesthetic decision.

Example of a small button

Full Width Buttons

Use full width buttons when you need a larger button to fill out space, such as the “Preview” button in the campaign editor. Like small buttons, choosing to use a full width button is partially an information architecture decision, and partially an aesthetic decision.

Example of a full width button

Button Text

Buttons should use active verbs that clearly communicate what action the system will take when the user clicks the button. The standard format is “[Verb] [noun]” (e.g. “Add Goal”). Do not use just a noun (e.g. “Editor”) or non-specific words (e.g. “Okay!”). Ask yourself: If the user only reads the button text, will they know what will happen? If not, then you should revise the button text so that it clearly communicates the action.

Aim for clarity over brevity. Although saying, “Yes, delete this variation” is longer than just, “Delete” or “Okay”, it’s much clearer to users what clicking that button will do.

Good Examples

  • “Create Audience”
  • “Start Experiment”
  • “Yes, delete this variation” or “No, don’t delete this variation” (instead of “Cancel”)

Bad Examples

  • “Editor” – Just a noun. Does it open the editor?
  • “Okay”, “Yes”, “No” – Yes to what? Understanding what these do requires reading the rest of the UI, which is more work and cognitively taxing.
  • “Save” – Save what? Better to say, “Save Settings”, for example.

Further Reading: