Loading Designed
What the screen shows while waiting, so it does not look broken.
Web App UX Design
Web App UX Design for the States Nobody Draws
Application designs are drawn in one state: loaded, populated, and everything working. Real use includes loading, empty, partially failed, offline and error — and those states are where users get confused. Web app UX design means designing all of them rather than leaving them to whatever the framework does.
We Design Every State, Not the Happy One
The states left undesigned are the ones users encounter when something matters.
Empty States
Every list and table before it has anything in it.
Errors Explained
What failed and what to do, not a generic apology.
Partial Failure Handled
When one part of a screen loads and another does not.
Unsaved Work Protected
Because losing input is the fastest way to lose a user.
What a web application is judged on
A web application is used repeatedly for work rather than visited. That changes what matters: it is judged on how it behaves over hundreds of sessions rather than on the impression it makes in the first one.
Core task efficiencySteps and time for the action users perform most often
Perceived responsivenessWhether the interface acknowledges input immediately
State preservationWhether work survives a refresh, a timeout or an accidental navigation
Navigation modelWhether users can tell where they are and how to get back
Deep linkingWhether any view can be shared or bookmarked by URL
Browser behaviourWhether back, forward and reload do what users expect
Offline and poor connectionWhat happens when the network degrades mid-task
Concurrent editingWhat happens when two people change the same record
Loading strategyWhether waits are communicated or the interface simply stalls
Keyboard coverageWhether frequent actions have keyboard paths
Accessibility conformanceFocus management and announcements in dynamic views
Data volume behaviourWhether views hold up at the record counts real accounts reach
State preservation is the check that produces the strongest reaction from users when it fails. Losing an hour of work to a timeout or a mis-click is remembered far longer than any interface improvement, and it is one of the few defects that reliably causes people to abandon a product they otherwise valued.
Web App UX, Explained
Which States Get Skipped?
Four, and all four appear in ordinary use.
Discuss Your App →- 1
Loading
A blank area, or a spinner with no indication of what is coming.
- 2
Empty
A table with no rows and nothing explaining why or what to do.
- 3
Error
A message that names a failure without naming a remedy.
- 4
Partial
Half the page loaded, half not, and no indication which is which.
What Web App UX Work Covers
The full state matrix, plus the interaction patterns that hold it together.
The build is covered by web application development. The build is web application development; the consistency layer across screens is design systems.
How We Design Web Apps
Enumerate the states per view, then design each one.
List the Views
Every screen the application has.
Enumerate States
Loading, empty, error, partial and populated for each.
Design Them
Including what the user should do in each.
Standardise
Consistent patterns rather than per-screen invention.
Test on Bad Connections
Where the skipped states actually appear.
What kind of application this is
Web applications range from simple record-keeping to environments people work in all day. What the interface must optimise for depends on which end of that range it sits at.
Internal business tools
Used by a known population who will be trained, where efficiency at the repeated task outweighs first-use approachability. These are frequently the most neglected interfaces in an organisation and the ones where improvement has the clearest operational return.
Content and record management
Where the work is creating, finding and editing items, and where search, filtering and bulk operations do more for productivity than any layout change. Volume behaviour matters more than it appears at launch.
Collaborative applications
Where several people work on the same material and the hard problems are conflict, presence and awareness rather than individual task flow. Deciding what happens when two people edit the same thing is a design decision, not only an engineering one.
Complex configuration tools
Where users assemble something with many interdependent options and the challenge is making consequences visible before committing. Preview, validation and reversibility carry most of the usability weight.
Applications replacing desktop software
Where users arrive with expectations set by a native application — keyboard shortcuts, offline capability, immediate response. Meeting the parts of that expectation which matter most is usually more important than matching the feature list, and it needs an explicit design system to stay consistent as the surface grows.
States
Why the Error State Is the Least Designed and Most Read
Users read error messages with more attention than anything else on the screen, and they are usually written last.
What makes an error message useful?
Saying what failed, why if it is knowable, and what the person can do next. "Something went wrong" satisfies none of those.
It should also distinguish between what the user can fix — a field, a permission, a connection — and what they cannot, where the useful advice is to retry or contact someone.
These messages get read carefully, because the user is stuck. That makes them the highest-attention text in the application and the last thing anyone writes deliberately.
Why does partial failure confuse people?
Because the screen looks like it worked. Most of the page is populated, one section is empty, and there is nothing distinguishing "no data" from "failed to load".
The user draws the wrong conclusion — that there is nothing there — and acts on incomplete information without knowing it.
Marking a failed region as failed, rather than letting it render as empty, is a small change and it is the difference between an inconvenience and a wrong decision.
Perceived speed is a design problem, not only an engineering one
Users judge responsiveness by whether the interface reacts, not by how long an operation takes on the server. An action that completes in a second while showing nothing feels slower than one taking three seconds with immediate acknowledgement and clear progress.
Several design techniques address this without any performance work. Acknowledging input the moment it happens. Showing the expected result immediately where the operation is very likely to succeed, and reconciling if it does not. Using skeleton layouts that indicate what is coming rather than a spinner that indicates only that something is happening.
These are not substitutes for genuine performance, and applying them to a genuinely slow operation produces a comfortable lie. Used alongside real optimisation they close the gap between how fast an application is and how fast it feels, which is what users actually experience.
Respecting the browser
Web applications frequently break the conventions of the environment they run in. The back button does something unexpected or nothing at all. Refreshing loses work or returns to a default view. Views cannot be linked to, so a user cannot send a colleague the thing they are looking at. Opening in a new tab produces an unrecognisable state.
Users do not treat these as application-specific quirks; they treat them as the application being broken, because every other site in the browser behaves consistently. The expectations are firmly established and violating them costs more goodwill than any feature earns.
Meeting them is mostly a matter of representing state in the URL and handling navigation deliberately. It also has a practical benefit beyond usability: linkable views make it possible for people to reference specific records in conversation, which is one of the most common things anyone wants to do with a business application.
Designing for the hundredth use, not the first
Applications are frequently evaluated on first impression — a demonstration, a trial, a review meeting — and designed accordingly. But the people who matter most use them hundreds of times, and the qualities that impress on first encounter often become obstructions with repetition.
Onboarding tours, explanatory panels and animated transitions are all reasonable for a first-time user and irritating by the twentieth. Generous spacing that looks clean in a screenshot means more scrolling for someone working through fifty records. Confirmation dialogues that felt safe become an obstacle to dismiss reflexively.
Resolving this means designing the experienced-user path as the default and layering guidance for newcomers on top, rather than the reverse. Dismissible help, shortcuts that reward learning, and interfaces that become quieter as the user becomes competent all serve the population that determines whether the product is kept.
Questions, answered.
Web app UX design covers the experience inside a web application, including the states most designs skip — loading, empty, error, partial and offline — alongside navigation, forms and feedback.
Because designs are drawn in the populated, working state and reviewed with good data on a fast connection. The other states are then left to whatever the framework produces by default.
Saying what failed, why if knowable, and what to do next. Error text is the highest-attention writing in an application because the user is stuck, and it is usually written last.
Marked as failed rather than rendered as empty. A section that failed to load but looks like "no data" causes users to act on incomplete information without knowing it.
Depends on the use case, but unsaved work should survive a connection drop regardless. Losing input is one of the fastest ways to lose a user's trust in an application.
Loading, empty, error and partial — because designs are drawn populated and reviewed on a fast connection. Those states are then whatever the framework does by default, and they are a large share of what users see.
A website is largely read and a web application is operated. A visitor to a site is being informed or persuaded, usually in one visit; a user of an application is performing work repeatedly. That changes almost everything — density, navigation, state handling and what counts as success. Applying marketing site conventions to an application produces something that looks polished and is slow to work in.
It depends on where it is used. Applications used in the field, in warehouses or in buildings with poor coverage need at least graceful degradation and preserved work. Applications used in an office on stable connections rarely justify the substantial complexity that full offline support introduces. What every application needs is sensible behaviour when the connection drops mid-action.
By examining what people actually use before removing anything. Usage data usually shows a small set of frequent paths and a long tail of rarely used features that some users depend on entirely. The workable approach is reorganising around the frequent paths while keeping the rest reachable, rather than a simplification that removes capability someone relies on.
Often more than customer-facing ones, on straightforward arithmetic. A tool used by fifty staff for two hours a day is consuming a large amount of paid time, and inefficiency in it is a direct operating cost. Internal tools are usually under-designed precisely because they have a captive audience who cannot choose an alternative.
Less than is usually assumed for interface decisions and more for behavioural ones. Layout, hierarchy and interaction patterns are achievable in any established framework. Things like real-time collaboration, offline capability and optimistic updates have real architectural implications, so they should be settled before development rather than requested afterwards.
Still deciding if web app ux design is right for you?
Talk to UsThe Design Had One State
Application interfaces get designed populated: realistic data, everything loaded, nothing failing. It is the state that photographs well and the state the team looks at for months.
Then it ships, and users encounter the version where the connection is slow, the list is empty, one panel failed and the error says something went wrong.
Nobody designed any of that. It is whatever the framework does by default, and it is a substantial fraction of what people actually see.
Free UX Review
See Your App in Its Other States
Give us access to your application. We will look at it empty, loading, offline and failing, and tell you what a user makes of it.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists