Every screen has more than one state

A designer hands a developer the Orders screen for a food delivery app. It shows three neat orders, each with a short restaurant name, a photo and a price. It's beautiful.

Then the app launches. A new customer has no orders, and sees a blank white screen. On a slow network, the screen shows nothing for six seconds. A caterer has 214 orders, and the list takes forever to scroll. One restaurant is called "Mama Ngozi's Authentic Eastern Kitchen and Pepper Soup Joint", and its name runs off the card. When the orders fail to load, the screen stays blank. And when the customer is offline, it's blank again.

The developer had to guess what to do in every one of those situations, because the design only showed one. Every screen has more than one state. This lesson teaches you to design all of them.

Words in this lesson

Why states matter

Jakob Nielsen's first usability heuristic is Visibility of System Status:

The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

NN/g's tips for this heuristic include: no action with consequences to users should be taken without informing them, and build trust through open and continuous communication.

A screen can only do that if you've designed what it shows in every situation. If you only design the ideal state, you're leaving the others to chance.

The states every screen needs

Use this list as a checklist for every screen you design:

Not every screen needs every state, but you should decide, for each one, rather than forget.

The "lots of content" state is where layouts break

Test every screen with:

• the longest realistic name or title
• the largest realistic number, like ₦1,250,000.00
• many items, like 200 orders or 50 messages
• none or one item
• a missing photo

This connects to lesson 5.1: when people make text bigger, every one of these gets harder to fit.

Component states

Screens have states, and so does every button, field and card inside them.

Material Design 3 describes six interaction states:

Some details from Material worth knowing:

• States can be combined, such as selected and hovered at the same time.
• There can only be one hover, focus, pressed or dragged state at a time in a layout.
• Disabled components can't be focused, dragged or pressed, and don't change when tapped. Material notes that disabled states don't need to meet its contrast requirements, which matches WCAG's exception for inactive components (lesson 6.4).

On phones, you'll design enabled, pressed and disabled most often. But don't skip focused: some people use keyboards, switch devices or other non-touch input, and your web products will be used with keyboards too.

Focus: a state people depend on

WCAG 2.2 has two rules about focus at Level AA:

• 2.4.7 Focus Visible: any keyboard-operable interface has a mode where the keyboard focus indicator is visible. W3C adds that when focus is shown, it must stay visible, not disappear after a moment.
• 2.4.11 Focus Not Obscured (Minimum): when a component receives keyboard focus, it's not entirely hidden by content the author created, like a sticky footer, a cookie banner or a snackbar.

Material Design 3 describes a ring-like focus indicator that helps people know where they are on a page.

So in your designs, give every interactive component a focused variant with a clear, visible indicator, and check that nothing you've placed on top, like a fixed bottom bar, can completely cover a focused element.

Disabled buttons need a reason

A disabled button is a state, and it's easy to get wrong. A greyed-out Continue button with no explanation is a dead end: people don't know what's missing.

If a button is disabled, the screen should make the reason obvious, like an unfinished field with a clear label. Another option is to keep the button enabled and show a specific error when it's tapped (lesson 7.3), so people learn exactly what to fix. Whichever you choose, test it with real people.

Map it with a state matrix

A state matrix makes missing states impossible to overlook. List your screens down the side and states across the top:

Every ❌ is a situation where a developer would have to guess. Every "n/a" is a decision you've made on purpose.

Do the same for components: buttons, fields, cards and tabs against enabled, pressed, focused, disabled, selected and error.

Build states in Figma

Component states as variants

You learned variants in Module 3. Use a State property with values like Enabled, Pressed, Focused and Disabled for buttons, and add Error and Filled for fields (lesson 5.3).

Make them interactive in prototypes

Figma's help centre describes interactive components, available on any plan: prototype interactions between variants in the same component set, using the Change to action.

1. Open the Prototype tab in the right sidebar.
2. Select the Enabled variant, and drag its connection to the Pressed variant (or add an interaction and set the action to Change to).
3. Choose a trigger. Figma's While pressing trigger returns to the original when released, which suits a pressed state.

Every instance of that button now shows its pressed state in your prototypes, without extra frames.

Screen states as named frames

For each screen, create a frame per state, and name them clearly so a developer can find them: Orders / Ideal, Orders / Empty, Orders / Loading, Orders / Error, Orders / Offline.

About the steps in this lesson. The Figma steps were checked against Figma's help centre in September 2026. If a step doesn't match your screen, search help.figma.com for interactive components or prototype triggers.

Common mistakes

The short version

• Nielsen's heuristic #1: keep people informed about what's going on, with feedback in a reasonable time.
• Screen states to consider: ideal, empty, loading, partial, error, offline, lots of content, success. Decide for every screen.
• Material's component states: enabled, disabled, hover, focused, pressed, dragged. States can combine; disabled doesn't need to meet Material's contrast requirements.
• WCAG 2.2: 2.4.7 focus must be visible; 2.4.11 a focused component must not be entirely hidden by your content.
• A state matrix shows what's missing. In Figma, use variants with Change to and While pressing, and name state frames clearly.

Try it yourself

1. Make a state matrix for every screen in your product's main flow, using the states in this lesson. Mark each cell ✅, ❌ or n/a.
2. Design every ❌ state for your two most important screens.
3. Test one screen with the longest name, largest amount and most items you can realistically imagine, and fix what breaks.
4. Add Enabled, Pressed, Focused and Disabled variants to your button component, with a clearly visible focus indicator.
5. Make the button interactive with Change to and While pressing, and try it in a prototype.
6. Find every disabled button in your flow, and make sure the reason is obvious.
7. Rename your screen frames using the Screen / State pattern.

You'll know you've got it when a developer could build your two main screens for any situation, empty, loading, broken, offline or overflowing, without asking you a single question.