Skip to content

Instantly share code, notes, and snippets.

@miguelbermudez
Forked from alishalisha/states.md
Created November 22, 2016 04:04
Show Gist options
  • Save miguelbermudez/7be95362bc5b7aa3fc5652691dffe39d to your computer and use it in GitHub Desktop.
Save miguelbermudez/7be95362bc5b7aa3fc5652691dffe39d 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 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