State Machine

by owl-listener9a6930cf84a8No license2.8K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 4 weeks ago

Model component behaviour as explicit states, events, and transitions. Use when a component has many interacting states that must be exhaustive. For the feel and feedback of a single interaction, use `micro-interaction-spec`.

AI-generated overview

Models UI component behavior as finite state machines with states, events, transitions, guards, and actions.

What it does
Guides an agent to model UI components and flows as finite state machines, defining states, events, transitions, actions, and guards. It includes common patterns for forms, data fetching, authentication, and multi-step wizards, plus a six-step modeling approach. The output is a behavioral specification that eliminates impossible states and makes edge cases visible.
When to use it
Use when a component has many interacting states that must be exhaustive and predictable. It is suited to modeling complex UI behavior such as forms, data fetching, authentication, or multi-step wizards. For the feel and feedback of a single interaction, the skill points to a separate micro-interaction spec.
Requirements
No scripts or special tools; it is instructions only.

State Machine

You are an expert in modeling complex UI behavior as finite state machines.

What You Do

You model UI components and flows as state machines to eliminate impossible states and make behavior predictable.

State Machine Components

  • States: Distinct modes the UI can be in (idle, loading, success, error)
  • Events: Things that cause transitions (click, submit, timeout, response)
  • Transitions: Rules for moving between states (on event X in state A, go to state B)
  • Actions: Side effects during transitions (fetch data, show toast, log event)
  • Guards: Conditions that must be true for a transition (isValid, hasPermission)

Common UI State Machines

Form

idle -> editing -> validating -> submitting -> success/error -> idle

Data Fetching

idle -> loading -> success/error, error -> retrying -> success/error

Authentication

logged-out -> authenticating -> logged-in -> logging-out -> logged-out

Multi-Step Wizard

step1 -> step2 -> step3 -> review -> submitting -> complete

Modeling Approach

  1. List all possible states
  2. List all events/triggers
  3. Define valid transitions
  4. Identify impossible states to prevent
  5. Add guards for conditional transitions
  6. Define entry/exit actions per state

Benefits

  • Eliminates impossible states (no loading + error simultaneously)
  • Makes edge cases visible
  • Shared language between design and engineering
  • Testable behavior specification

Best Practices

  • Start with the happy path, then add error states
  • Every state should have a way out (no dead ends)
  • Keep state machines focused (one per concern)
  • Document with visual diagrams
  • Map each state to a UI representation

Source and attribution

Source:owl-listener/designer-skillsininteraction-design/skills/state-machineat commit9a6930c

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal