Skip to content

Instantly share code, notes, and snippets.

@ohiosveryown
Forked from alishalisha/states.md
Last active January 30, 2018 14:26
Show Gist options
  • Save ohiosveryown/02283d65cdb292faf124a1350e6580f4 to your computer and use it in GitHub Desktop.
Save ohiosveryown/02283d65cdb292faf124a1350e6580f4 to your computer and use it in GitHub Desktop.
Checking state on product design patterns

Checking the State of Your States

If applicable, make sure your design component accounts for all these states. This is basically copied from the Nine States of Design Medium article. 😛

  • Initial state: What happens before your component does anything? Maybe it’s the first time a user sees it. Maybe it’s not activated yet. Essentially, the component exists but hasn’t started.
  • Loading state: Have you accounted for when a user will be waiting for something to happen? What does that look like?
  • Empty/Zero state: Your component has initialized, but it’s empty. No data. No Items. Now may be a good time to get the user to act (“Do this thing!”), or to reward them (“Good job, everything is taken care of”).
  • One state: You have some data. On an input, this may be after the first keystroke. In a list, it might be when you have one item (or one left).
  • Some data state: This is usually what you think of first. What is the ideal state for this component? Your data is loaded, you have input, and the user is familiar with it.
  • Too much data state: Woah there! The user has overdone it in some way. Too many results (maybe you paginate them now), too many characters (maybe ellipses?), and so on.
  • Incorrect state: Something is not right about the component. An error has occurred.
  • Correct state: The input is valid, everything is ready to go. Give the user positive feedback.
  • Done state: Again, give the user positive feedback that the action they just wanted to take has been completed and they’re good to go.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment