Because speed and perceived speed are not the same thing. A page that loads in one second but shows nothing for that second feels slower than a page that takes slightly longer while showing you it is working. What fills the wait matters as much as how long the wait is.
Loading and empty states are the parts of a design that almost nobody sketches. The hero gets six rounds of review. The blank search result nobody has ever seen gets none. Then it ships, a real user hits it, and the site looks broken for reasons that have nothing to do with the build quality.
These moments are cheap to design and expensive to skip. They are also one of the clearest signals of whether a site was finished properly or just launched.
A loading state is what a person sees while the site is fetching something. An empty state is what they see when there is genuinely nothing to show, like a search with no matches or a dashboard before any data exists. One says wait, the other says there is nothing here yet.
Designers often lump the two together, but they need different answers. A loading state should reassure. An empty state should explain and offer a next step. Showing a spinner forever when the real answer is no results is one of the most common bugs we find in a handover audit.
The third case worth naming is the error state, which says something went wrong. Keeping these three distinct in your design files is half the battle, because the code will mirror whatever the design assumed.
There are three well known thresholds. Nielsen Norman Group has published them since 1993: 0.1 seconds is the limit for something to feel instantaneous, 1 second is the limit for a user’s flow of thought to stay uninterrupted, and 10 seconds is the limit for keeping attention on the task.
Those numbers are old and they have held up, because they describe human perception rather than technology. Hardware got faster. Attention did not change. That is why the same three limits still turn up in interface guidance thirty years later.
The practical use is deciding whether you need a loading state at all. Under 0.1 seconds, do nothing, because a spinner that flashes for one frame is worse than no spinner. Under one second, a subtle indication is plenty. Past that, you owe the user real feedback.
Match the indicator to the length of the wait. Nielsen Norman Group recommends reserving looped animations, meaning spinners, for actions that take between 2 and 10 seconds, and using percent-done progress indicators for longer processes that take 10 or more seconds.
The reasoning is about information. A spinner tells you the system is alive but nothing else, which is fine for a short wait and maddening for a long one. A percent-done bar tells you how much is left, so the user can decide whether to wait or go and do something else.
Nielsen Norman Group adds a useful caveat: since you cannot always estimate the delay precisely in advance, it is worth lowering that threshold so longer than expected delays still get the more informative feedback. We take that seriously on anything involving a file upload or a third-party API, where the honest answer is that you do not know how long it will take.
Often, but not always, and we want to be clear this is our opinion rather than a settled research finding. A skeleton screen shows the shape of the content that is coming, so the page feels like it is assembling rather than stalling. That works well when the layout is predictable.
Where skeletons fail is when the real content does not match the placeholder. If your skeleton shows six cards and two arrive, the user watched a lie for a second and a half. That is worse than a neutral spinner, because it broke a small promise the interface made.
Our rule is that we use skeletons where the layout is fixed and known, and a simple indicator where the result could be anything. A search results page is a bad candidate for a skeleton. A profile card that always has the same structure is a good one.
Badly, if they change size when the real content arrives. Cumulative Layout Shift measures unexpected movement, and content that loads into unreserved space is one of the main causes. Google lists images without dimensions, ads and embeds without dimensions, and dynamically injected content among the top culprits.
The fix is to reserve the space before the content exists. Google’s guidance is to set width and height attributes on images and video, or use the CSS aspect-ratio property, and to add a min-height rule to reserve space for responsive content like advertisements.
There is a design lesson hiding in that technical advice. If your loading state is exactly the size of the content it will be replaced by, you get a smooth swap and no layout shift. If it is a small spinner in the middle of a collapsed container, the page jumps the moment content arrives. Our guide to Cumulative Layout Shift and how to fix it covers the measurement side.
Google also suggests letting the user initiate the load of new content, for example with a load more button, so they are not surprised by the shift. That is a design decision dressed as a performance tip, and it is usually the right call over infinite scroll.
Three things: it says clearly that there is nothing here, it explains why, and it offers the next action. A blank panel does the first badly and the other two not at all. An empty state is a small piece of writing more than a small piece of design.
The version we see most often is a centred grey icon and the word None. That tells the user the system worked but gives them nowhere to go. Compare it with a line that says no results for that search, try a shorter phrase or browse all projects, with the browse link right there.
Tone matters here more than almost anywhere else on a site, because the user is already slightly frustrated. Keep it plain and helpful rather than clever. Our piece on microcopy and how it changes conversions goes into how much these small pieces of text are actually worth.
Announce them. A sighted user sees a spinner appear and results arrive. A screen reader user gets nothing unless you mark the update as a status message, because the change happens somewhere they are not focused.
There is a formal requirement for this. WCAG success criterion 4.1.3, Status Messages, is a Level AA rule. It states that status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
The W3C’s own examples map neatly onto this article. It describes text reading 5 results returned appearing near a search result, a cart count updating to 5 items, and a dynamic progress bar announcing status intermittently. Those are exactly the moments people forget to mark up, and Level AA is a common contractual baseline rather than a stretch goal.
Designing the happy path and nothing else. It is genuinely easy to build a beautiful listing page using seed data where every card has a perfect image and a two line title, and never once look at what happens with zero items, one item, or a title that runs to four lines.
The habit we have built is to review every dynamic section in four states before it is signed off: loading, empty, one item, and far too many items. It takes maybe twenty minutes per section and it catches the problems that would otherwise be discovered by a customer.
Forms are the other repeat offender, because a submit button with no loading state invites people to click it three times. We treat that as a defect rather than a polish item, and we cover the wider version of it in our guide to designing forms people actually finish.
Open your own site and deliberately break it. Search for a nonsense phrase. Filter to a combination with no matches. Throttle your connection in browser dev tools and reload a heavy page. Whatever you see in those moments is what some portion of your visitors already sees.
Fix the worst one first, and it is almost always the search or filter with no results, because that user had clear intent and got a dead end. Giving them a way forward from that screen is a small change with a direct effect on whether they stay.
If you want a second pair of eyes on how your site behaves in the moments nobody designed for, we’re happy to run through it with you. Reach out at phoenix.studio and we will show you what we find.
Tell us where you want to go. We'll tell you how we'd get you there.