The four interface states that 90% of designers forget

Open any fresh layout in Figma - the main product screen, dashboard, tape. With a probability of almost one there is drawn one state: all is well, the data is, the user is logged in, the Internet is working, the server answered for 200 ms. An ideal scenario that occurs in a minority of sessions.

Find the same product in reality. First launch without data. Long load on 3G. A search that found nothing. A uniform that didn't go. And that’s where the real UX begins – the one where the user decides whether to stay or close the tab.

Four states that almost everyone forgets about: empty, booty, erroneous and partial. They are not front-end bugs, not “developer will finish”, not “later draw”. These are full screens that more people see than the main feature of the product.

---

## Why these conditions fall out of work

It's not the laziness of designers. It's about how the process works.

The layout is made for the presentation: the stakeholders need to show value, not emptiness. The design review goes the Happy Path because it's faster. In a design system, the components lie in a state of default – and copy into the layout just like this. The developer, without receiving the layout for error, puts a default alert browser or gray text “Something went wrong”.

As a result, the problem pops up not at the design stage, but in the sale - through complaints in support, drop-offs in analytics and the phrase "nothing works for me" in reviews.

### Who Really Sees These Conditions

• Any new user sees an empty state immediately after registration.
• Any user with a weak internet connection sees the download longer than the designer planned.
• Anyone searching, filtering, importing, synchronizing runs the risk of falling into error or emptiness.
• Anyone on a mobile subway is a guest of all four states at once.

If you add up these segments, it turns out that the “ideal scenario” is, on the contrary, the exception. And designing just for it means designing a product for a minority of sessions.

---

## State 1: Empty State (Empty State)

An empty state is not "nothing." This is the first time a product has spoken to a user without data support. There is nothing to push: no cards, no charts, no tape. All that remains is design.

### Three types of empty states

They are often thrown together, and this is the first mistake.

• First-use empty - the user has just logged in, the data can not yet be in principle. Here you need onboarding tips, a sample, a “create the first” button.
• User-cleared empty - the user deleted everything, completed all tasks, closed all tickets. Here it is appropriate to congratulate, not to scare with emptiness.
• **No-results empty - search or filter found nothing. This is the most dangerous: easy to mistake for a breakdown.

One oops, nothing screen for all three cases is an anti-pattern. The context is different, the user’s reaction is different, the text and action should be different.

### Anti-patterns that occur on a review

• Illustration-mask and the text “Here is still empty” – no clue what to do.
• The "Create" button is hidden in the upper right corner, and in the center of the screen is only a picture.
• No-results has no filter reset, no “try another request” prompt.
• The same screen for the first entry and for the case when the user has completed all the tasks.
• Text in the spirit of "No data available" - machine, not explaining.

### What should be on the empty state screen

• A clear explanation of why it’s empty (not “no data” but “you haven’t added a customer yet”)
• One main action is a button or link leading from the void
• An example of what it will look like when the data arrives
• For no-results, a way to reset filters or change a request
• The tone of voice that matches the rest of the product, without “oops” where it is not in the brand

### Questions for an empty state review

• The user, seeing this screen, understands if the product is broken or so intended?
• What next action is obvious? Is it one or more?
• If the screen was seen by a person who came here by accident, he would understand why go here?

---

## Status 2: Loading State

Downloading is not “until nothing, be patient.” This is a full state of the interface, in which the user spends a significant part of the time. And this is where the feeling of product speed is most often broken - even if the backend is fast.

### Perception speed vs. API speed

The user does not measure milliseconds. It measures whether the interface twitched after the click, whether there was a response, whether you can see progress. An 800ms request with instant skeleton feels faster than a 300ms request with a frozen screen.

Therefore, work with loading is primarily work with feedback, and only in the second – with the response time itself.

### How to replace an infinite spinner

The spinner in the center of the screen is default and almost always the worst choice. He does not say anything: not how much to wait, not what is loaded, not broken.

Which works best depending on the context:

• ** Skeletons** - for tapes, cards, dashboards. Show the future structure, reduce the feeling of emptiness.
• *Progress Bar – when the duration is known or predictable: file download, import, report generation.
• Optimistic UI – like, add to the cart, rename. The action is shown immediately, the rollback is only with an error.
• Phase-by-stage download – first the framework, then the main content, then secondary. The user starts working earlier.

### Anti-loading patterns that are caught on the review

• Timeoutless spinner: Hangs until the user closes the tab.
• The skeleton does not coincide in geometry with the final content - after loading, the screen twitches, the buttons shift, the wrong thing is pressed by mistake.
• Progress bar jumps back or freezes by 95% (this item is especially hated by installers).
• Optimistic UI without rollback: the user sees that the like has been set, but it is not on the server - and when restarting everything disappears.
• The download blocks the entire screen, including navigation. If the answer came with an error, the user can not even exit, except by closing the tab.
• Preloader logo for five seconds just because "so prettier.".

### Load status checklist

• Any click gives a visual response in the first 100 ms — at least a change in the state of the button
• If the answer is longer than 1 second, show something structural, not a point in the center
• If it is longer than 10 seconds, there is progress and a clear “what are we doing now”
• Skeleton matches in height and grid with real content
• There is a way if the request falls: go into a state of error, not a perpetual spinner
• Navigation and secondary blocks are not blocked by downloading a single widget

### Questions for review of loading status

• What does the user see in the first 200 ms after the click?
• If the request hung for 30 seconds, what does the screen look like?
• Can I start reading or working on one part of a page while the other is loading?
• How many times does a user see a spinner in one scenario? If more than two, the float is designed “by the handles”, not by the task.

---

## State 3: Error (Error State)

Error is a state that is drawn last in the layouts, on a thin, often after release. Therefore, in most products, it looks like a hastily glued module: red text, an exclamation point, a “Try again” button. At the moment of error, the user decides whether to trust the product.

### Four Types of Mistakes That Confuse

• Systems - server down, no internet, timeout. The user is not to blame, and the text must acknowledge this.
• **User * - invalid email, weak password, incorrect file format. You need an explanation and an example of how to do it.
• Business restrictions - the limit is over, there are no rights, the tariff has expired. This is not a technical error, but it feels the same interface. We need a solution: upgrade, access request, contact with admin.
• Silent – some of the data is not loaded, but the interface is silent. The most insidious type: the user makes a decision on an incomplete picture.

One error pattern for all four cases is the main reason why product errors sound like a robot.

### Anti-Error Patterns

• “Something went wrong. Try it later – no options, no context, no idea who has the problem.
• Technical stacktrace or code 500 without human translation.
• Toast disappears in 2 seconds, and the user does not have time to read what happened.
• The shape field is red, but doesn't explain what's wrong.
• The "Repeat" button sends all the long flow from scratch, losing the entered data.
• Full-screen error for temporary failure of one widget – the user can not use the rest of the product.

### Check of the state of error

• Text Explains What Happened, In User Language, Without Codes
• It is clear what to do right now: repeat, change the input, contact in support
• Entered data is saved - repetition does not cost the user the work
• There are temporary errors (you can wait) and permanent (you need action)
• The error is localized: the widget breaks - the entire screen does not break
• Important mistakes have a way to a person: chat, email, link to status

### Questions for an error state review

• Can the user solve the problem by relying on the text alone?
• What's lost if it hits "Repeat" -- given shapes, progress, context?
• Is it clear from the tone that the product is to blame, not the user, when it is?
• If the error is repeated three times in a row, what happens next: an endless loop or a path to support?

### How to embed errors in the workflow

The most common reason for bad mistakes is that they are drawn separately from the main flow, at the end of the sprint, without the involvement of a copywriter and developer. What changes the picture:

• Each layout of the key screen immediately goes to Figma three: empty, load, error. We won't finish it later.
• Error texts are written together with a UX copywriter or at least using a dictionary of tone, not the developer at the time of integration.
• On the review, the mandatory item is “show what this screen looks like if the API answered 500.” If there is no answer, the layout is not accepted.

It's not a duck

the desire of the process. It’s a shift: Errors are no longer a mockup and become part of the screen itself.

---

## Status 4: Partial data (partial state)

The fourth state almost never appears in models. And in production, it occurs more often than it seems: something is downloaded, something is not. Some of the cards received a preview, some of the stubs. The statistics widget replied, the recommendations widget silent. The user sees a screen that technically works, but the picture is incomplete.

### Where this state is caught

• Dashboards with independent blocks: one source fell, the rest are alive.
• Lists with child queries for each item (avatars, statuses, tags).
• Real-time data: connection interrupted, last 30 seconds - gray area.
• Offline mode: Cached data is visible, but not the latest.

### Anti-patterns

• The screen shows the data, but nowhere is it marked that some of it is outdated or unloaded.
• The stub of the item is visually indistinguishable from the empty value - the user thinks that "there is really zero there.".
• When the real-time connection breaks, the numbers are frozen without an indication, and the person makes decisions on the old numbers.
• Cash offline has no timestamp: it is unclear whether it is relevant or yesterday.

### Partial state checklist

• Each block has its own boot state and errors, not a common one
• You can see what data is fresh, which is from the cache, which is not loaded
• Element plugs are distinguishable from “real zero”
• When a connection is lost, the interface speaks honestly about it rather than pretending to
• Actions that depend on unsubmerged data are blocked or warned

---

## Advanced scenarios: states in combination

Interface life is not one state at a time. The real screen is often mixed: the list is loaded but empty; the data came in but is out of date; the form is sent, but some fields are back with an error. A useful review exercise is to build a matrix: each block of the screen × four states. You can see which cells the team has never worked on.

### Long operations

If the operation takes more than a few seconds, the four states turn into five: progress is added. Signs that progress has been made correctly:

• You can see that the system is really working, not hanging
• There is a time estimate or stage ("3 of 7: image processing")
• It can be distracted: the notification will return
• Cancellation does not leave data in a half-broken state

---

## AI features: the same four states, new risks

AI interfaces break habitual state patterns, and commands often miss this.

• In a chat with an assistant, “empty” is not “no data” but “no context.” A good blank AI feature screen shows examples of queries for a specific user role, rather than an abstract “Ask Anything.”.
• Download. Spinner for 20 seconds in the LLM response is a flop. Token streaming is perceived faster, even if the total time is the same. It is important to show what the model is thinking, not that the app is hovering.
• Error. A new type is added to the system and user ones: low confidence model or actual hallucination. The interface should be able to say “I’m not sure” – the “check source” button, the confidence marker, the reference to the source data.
• Partially. The model answered part of the request, in part - refused or did not find. This should be shown honestly, not glued together into one confident answer.

### Risks worth discussing with the team

• Streaming can mask an error: the text began to be generated, then broke – the user sees the stump.
• The “Repeat” button in the AI feature is not the same repetition as in the usual form: the answer will be different. You have to talk about it in the UI.
• Auto-generation in Figma/MCP plugins often only delivers a “perfect” layout. The states are empty/download/error/partially have to be drawn with your hands – put that in the score.

---

## How to Incorporate Four States into a Team Process

### Definition of Done for the screen

The screen is considered ready only if there are:

• Ideal state with real data, not lorem
• Empty – for a new user and for a filtered result
• The download is short and long, with progress if necessary
• Error – System, User, Business Limitation
• Partial – where data comes from different sources

### Design review questions

• Show this screen the day you first log in -- no data, no history.
• Show this screen on slow 3G.
• Show this screen if the API answered 500.
• Show this screen, if half the data came in, half didn't.

If there is no answer to any of the questions in the layout, the layout is not accepted. Not "finish later," but literally not accepted.

### How to explain it to the team

The most working argument is not “so right on UX,” but money and time. Every ill-conceived state turns into a bug in the prode, a ticket in support, a developer's night fix and an oblique metric. The drawn state is five minutes in Figma instead of five hours on a burning release.

The second argument is for the product: four states make visible those decisions that the developer otherwise makes alone, at three o’clock in the morning, based on “as usual”. So, the product ceases to diverge from the idea in the most nervous points of the user path.

## The anti-patterns you see on any review

These things are repeated from project to project, regardless of industry. If you find out at least three, it is normal, everyone has it. If not, you probably don’t notice them.

### Spinner instead of state

The most common. Any uncertainty is closed by a spinning circle: no data is a spinner, network error is a spinner, slow API is a spinner forever. The user does not understand whether something is loaded, broken, or has nothing to wait for.

### Empty screen like a stub

Gray illustration, the inscription "There is nothing here yet" and that's it. No explanation of what should appear, no buttons to create it, no clues as to what to do. It’s especially painful on the product’s home screens where a new user decides to stay or leave.

### Toast with the text "Error"

A red notice that disappears after three seconds, with the text "Error 500" or worse, "Error 500." The user did not have time to read, did not understand what broke, does not know whether his data was lost. He cannot copy the text of the error in support either.

### “Success” where there is no success

A green checkmark after clicking "Save", although the server took three of the five fields. Formally, the answer is 200, which is actually a partial state disguised as ideal. A week later, support receives a complaint “I saved, but nothing survived.”.

### Conditions that only a designer can see

The layout is drawn, in Storybook lies, in Figma signed - but in the sale it does not cause any real scenario. Either the developer did not find it in the specification, or the condition did not match, or the feature flag closed. The condition is on paper and not in the product.

## Extended checklist before merj

This does not duplicate the Definition of Done from the section above – this is the last check of the already assembled feature before the user sees it.

• Flowed with a clean account, no history and no data
• Passed the float with a disconnected Internet and a slow network
• Deliberately broke one of the API calls through DevTools - saw an adequate message
• Opened the screen at minimum width and at 4K - the state did not float
• Checked states with long names, long lists, emojis and hieroglyphics
• Screenshots of all states are attached to the task - not just the ideal one
• Error texts passed through the editor or at least reread aloud
• Analytics shoots at every fortune, not just success

## Questions for in-depth review

Once the basic four states have been drawn, it makes sense to ask second-order questions. They often reveal what the team used to ignore.

### According to the data

• What happens if the data comes in, but in an unexpected format?
• What will a user who has ten times more data than the average see?
• How does the screen behave if the data came with a delay after the user left it?

### Timely

• What happens in the first 200 milliseconds before anything loads?
• What happens if the download lasts 30 seconds instead of the expected three?
• What will a user see when they return to the screen after a day with an open tab?

### In action n

• What happens if the user presses the button twice?
• What happens when you cancel in the middle of the operation?
• What will a user see if they have lost access rights while they are working?

### By trust

• What state does the user most doubt that the system works?
• Where in the interface can he think "I broke something" and close the tab?
• Where exactly does he need confirmation that his action has reached?

## Practical outcome

Four states are neither a theory nor a beautiful checklist in Figma. This is a way to stop handing over layouts that turn into bugs, nervous calls and lost users.

Minimum that pays off immediately: on each screen, talk out loud empty, download, error and partial state. Not for everyone, for those where screen blocks can actually end up in these states. Write down what is going to happen and draw. It takes minutes and saves days.

Next, build it into the process: add to Definition of Done, ask four questions on each review, refuse to accept a layout where there is only “perfect.” In a couple of months, the team will no longer think of it as a checklist - it will become the norm. And it’s from that moment that the product begins to feel like it was made by adults, not like a beautiful presentation that broke at the first real user.