What is a state?

A state is a condition or mode of being, where the user interface or system satisfies particular conditions and/or awaits an interaction. Under different settings, the UI will produce perceivably different display variations or results. When annotating an interaction design, it’s helpful to comprehensive describe the range of states of each page, component, or even element of an experience. With such visual and textual descriptions, you can concretely set expectations to establish consensus and foster understanding across your documentation’s many audiences.

Common examples where a designer considers states include:

• When to show or hide a messaging unit to invite the user to sign in to a personalized experience.
• When particular tabular components are included above, below, or omitted relative to other components based on stored data
• When explicit user input (such as a product selection) as well as implicit behaviors (navigating an audienced site section) result in data entry defaults in a checkout process

The Fundamental Question

When describing states in interaction design, the designer’s focus is on the user - what can the user see, what are they perceiving, how is their cognitive model mapping to what the system actually manifests? Ultimately, these instances can be described by visible states that a designer can boil down to a fundamental question, with three parts:

When do you see what?

First, the “When.” This aspect focuses on the conditions or circumstances of a state. Here, it’s critical to describe conditions in terms of inexorable statements and visualizations, removing any ambiguity as to when such a state occurs - and doesn’t occur. If a designer can’t accurately describe conditions of when a state applies, then any hope at applying the “See” and “What” is fruitless. Example conditions include:

• Signed in?
• Old enough?
• Content available?
• Consumer or business or government?
  
• Account created?
• Option selected?
• Name defined?
• Playlist nonempty?
• A/B test resulted in showing version A?

All of these questions can be posed as circumstances with an answer that cannot be debated, if formed correctly. Yes, the user’s signed in or no, the user is NOT signed in. The user was defined as born before a specific date or the user is too young (or the system doesn’t know how old the user is).

Next, the “See.” This is pretty simple. When taking the user’s point of a view, describe states of a user interface is about defining whether the system should show or hide an element, component, or even a page as an interaction sequence progresses.

Finally, the “What,” which isn’t that complicated either. Here, the designer is looking to define precisely how the user interface appears. What gets shown, or not shown.

How do you communicate “When do you see what?” Via pictures and words, of course, which will be the subject of the remaining two segments of this topic.