Design States

These are the different versions of each design a user may encounter, depending on their circumstances.

Beware the “happy path”

Never assume that the most frequently used design is automatically your priority. Helpful content across all scenarios should be the priority – a poorly designed error state can lose customers, even with a flawless happy path.

Types of states

1 Educational: First run, Loading, EmptyThese states shouldn’t appear often, but when they do, the user needs answers. Our job is to offer just enough info so the user learns what to do, without creating confusion.

Figma example
[image needed]

2 Expected: One, Some, Success, DoneThese are the default screens that users see over and over. They will memorize the flow and don’t expect interruptions.Strong designs are mindful of redundancy, unnecessary info, and high cognitive loads better suited for educational states. 

Gmail example
[image needed]

3 Unexpected: Invalid, Too many, & moreThese aren’t scenarios you want users to encounter, but they’re when users need the most help. Implement best practices for users under stress. When blocked from their task, they have less patience for humor, reading, or lengthy explanations. State the issue, why it happened, and what next step they can take.

Atlassian example
[image needed]

Additional considerations

  • Show, don’t tell - Informational doesn’t have to mean wordy. Leverage all the ways you can teach a user without relying on text (positioning, timing, color, icons, etc).
  • Design collaboratively - Limited text doesn’t take you as far if the visual design is still too complex. Channel these principles collectively across all disciplines (engineering, interaction, content, etc.)
  • Accessibility isn’t an exception - While you may have specific states dedicated to WCAG requirements, every state should account for accessible design.

More on design states