State for Designers
You already understand state. You just don’t call it that yet.
You’ve Seen This Before
If you’ve used interactive components in Figma, you’ve worked with state. A toggle has two states: on and off. A button has states: default, hover, pressed, disabled. You define what each state looks like, and you define what triggers the change between them.
State in a real app works the same way — just applied to everything at once.
Instead of a single component, your entire app has a “current situation.” Is the sidebar open or closed? What items are in the list? Has the user typed anything into the search field? Which tab is selected? Is the app loading data or done loading?
All of that is state. It’s the app’s memory of what’s happening right now.
What State Actually Is
State is just data that can change. That’s it.
When a user toggles dark mode, the app stores a value: darkMode: true. When they add a task to a list, the app updates an array of tasks. When they type in a search field, the app tracks every keystroke.
Every interactive thing in your app is backed by state. The visual change you see on screen is a result of some underlying value changing. The button doesn’t “look” pressed — a value changed to pressed, and the app renders accordingly.
This should feel familiar. It’s the same relationship between your design tokens and your components. Change the token, the component updates. Change the state, the interface updates.
Why Your Changes Disappear on Refresh
This is the first thing that trips people up.
You build a list. You add three items. You refresh the page. They’re gone.
That’s because the state was stored in memory — think of it like a whiteboard. While the app is running, the whiteboard has everything written on it. The moment you refresh, the whiteboard gets erased and the app starts over with a blank slate.
To keep data around, you need to save it somewhere permanent. A file. A database. The browser’s localStorage. This is the difference between in-memory state (temporary, lives in the whiteboard) and persisted state (saved, survives a refresh).
You don’t need to understand the mechanics. You just need to know the distinction exists so you can tell Claude what you want. The Data Persistence guide covers your options for saving data.
How Claude Handles This for You
You don’t need to write state management code. You describe behavior.
When you tell Claude “add a list where users can add and remove items,” Claude sets up the state — the array of items, the functions to add and remove, the connection between the data and what’s displayed on screen.
When you say “save the list so it’s still there after refresh,” Claude adds persistence. It picks the right storage method and wires it up.
Your job is to be specific about what should happen. Claude handles the implementation. The clearer you describe the behavior, the better the result.
Common State Patterns
These are the types of state you’ll encounter most often as you build:
Toggles. Anything that switches between two values. A dark mode switch. A sidebar that opens and closes. A dropdown that expands and collapses. One piece of state, two possible values.
Lists. Collections of items that grow and shrink. Todo items. Notes. Bookmarks. Habits. State tracks the full list, and updates when items are added, edited, or removed.
Forms. Every input field is a piece of state. What the user has typed, whether the input is valid, whether the form has been submitted, whether it’s currently submitting. Forms usually involve several pieces of state working together.
Navigation. Which page, tab, or view is currently active. When a user clicks a tab, the app doesn’t load a new page — it updates a state value, and the interface swaps what’s displayed.
Loading. When your app fetches data from an API, there’s a gap between asking and receiving. State tracks whether the app is loading, has finished, or hit an error. This is how you show spinners, skeleton screens, or error messages.
When to Talk to Claude About State
If something in your app isn’t behaving the way you expect, state is often the reason. Here are signs:
- “My changes disappear when I refresh.” State isn’t being persisted.
- “The button doesn’t remember that I clicked it.” The click isn’t updating any state.
- “Switching tabs resets everything.” Each tab is re-initializing its state instead of preserving it.
- “The form clears itself after I submit.” State is being reset when it shouldn’t be.
- “The loading spinner never goes away.” The loading state isn’t being updated when data arrives.
When you hit these, describe the problem to Claude in terms of what should happen versus what actually happens. You don’t need to diagnose the state issue yourself — but knowing that state is likely the culprit helps you ask the right questions.
State is the bridge between what your app knows and what your user sees. Once that clicks, a lot of confusing behavior starts making sense.