Interaction states

Interaction states define a visual language for communicating the state of a component as merchants interact with it. These visual styles correspond to hover, focus, active, selected, disabled, and subdued states. They help merchants understand what to expect while interacting with Shopify.


Principles

Interaction states should communicate status of an action, establish confidence once an action is taken, and suggest the ability or inability to interact with an element.

Be subtle, but clear

Interaction state styles should be subtle, but clear about the message that’s being relayed. Successful interaction feedback should inform and is not decorative. Avoid elaborate transitions that create visual noise, intense color changes or distracting animation can create disturbance and make an interface unpleasant to use. Instead, aim to empower merchants and help them feel confident when carrying out their tasks.

Be consistent

Consistent treatments for interaction feedback create recognizable patterns for merchants. If an interaction produces different feedback across Shopify, it risks confusing merchants and deteriorates the integrity of the pattern.


Designing interaction states

Merchants interact with interfaces differently depending on input device, so when designing your feature consider different input devices merchants use.

Input devices to consider

  • Mouse
  • Touch screen
  • Keyboard
  • Voice
  • Game controller
  • Refreshable braille display

See the accessibility guidelines for further reading.

Use signifiers

Signifiers are clues about how an interface should be used, typically provided by the component itself or its context. For example, Polaris buttons can have three kinds of signifiers:

Explicit, where content directs merchants to do the intended action, such as “Save”.

Hidden, where the clue isn’t revealed until merchants attempt to interact with it, such as hovering to see if the button is clickable.

Negative, where the action looks inactive because you are specifically trying to tell merchants that they can’t use it, such as the reduced contrast of the button’s disabled state.

Provide merchants with cues as to what the interface will do if they interact with it. By using signifiers we set expectations about what components can do, which creates a more intuitive interface that’s easier to use.

Behavior

When merchants interact with a component, use feedback indicators like progress bar or spinner to let them know that the interface received their request, and if appropriate, provide information about the completion.


Styles

Polaris components have interaction state styles built in. Follow these guidelines when styling the interaction states of new components or custom features.

The following examples use a normal state with a white background. For components that have non-white normal states, colors may need adjustment. See the mixin docs for more information.

Hover

One method of applying a signifier to an element is to change its visual state when hovered. This communicates that an element is interactive. Disabled components shouldn’t have styled hover states. This is to reinforce that the normally interactive element isn’t available for interaction.

Example
Selected
DisabledSubduedFocused
.my-custom-component-class {
  @include state(hover);

  /* Combined states */
  @include state(hover, selected);
  @include state(hover, subdued);
  @include state(hover, focused);
}

Focused

The focused state shows that an element is ready to receive input from an input device, such as an assistive technology or a keyboard. Disabled components can’t receive focus states. This is to reinforce that the normally interactive element isn’t available for interaction.

Example
Selected
DisabledSubdued
.my-custom-component-class {
  @include state(focused);

  /* Combined states */
  @include state(focused, selected);
  @include state(focused, subdued);
}

For nested interactive elements, the parent element may maintain the focused background style, but not the visual marker (box-shadow) when an element within it is focused.

Example
.my-custom-component-class {
  @include state(focused);

  > .within {
    // remove boxshadow from regular focus state
    box-shadow: none;
  }
}

Active

The active state occurs when merchants press an element with an input device, such as a mouse click or keyboard press. Like hover, disabled elements don’t have styled active states. This is to reinforce that the normally interactive element isn’t available for interaction.

Example
Selected
DisabledSubduedFocused
.my-custom-component-class {
  @include state(active);

  /* Combined states */
  @include state(active, selected);
  @include state(active, subdued);
  @include state(active, focused);
}

Selected

Shows that an element, such as an option in a selectable list, has been picked. Selectable components may contain additional elements such as checkboxes or radio buttons to add clarity to selected states.

Example
.my-custom-component-class {
  @include state(selected);
}

Disabled

Use to show that an interactive element isn’t available for interaction.

Example
.my-custom-component-class {
  @include state(disabled);
  color: color('ink', 'lightest');
}

Subdued

Use to indicate reduced importance of an element, such as an archived order on the order list page. A subdued element is available for interaction, but requires less attention than an element in a normal interaction state.

Example
.my-custom-component-class {
  @include state(subdued);
  color: color('ink', 'lighter');
}

Resources