Q388: Empty Loading Error State Drill Making UI Feel Complete

What Interviewers Want To Evaluate

This drill tests whether you build interfaces beyond the happy path.

Incomplete loading, empty, and error states are one of the fastest ways for a polished UI to feel unfinished.

Senior frontend engineers model these states early because they affect layout, accessibility, analytics, and user trust.

Short Interview Answer

I design loading, empty, and error states as part of the feature, not as afterthoughts. Loading should communicate progress without layout chaos, empty states should explain what happened and what the user can do next, and errors should be specific, recoverable, and accessible. I also test these states because they often break when data changes.

State Inventory

For every data-driven UI, ask:

before request
loading first time
refreshing existing data
success with data
success with empty data
partial success
validation error
authorization error
network error
server error
retrying

These states should be named before code becomes complicated.

Loading States

Use loading states that match wait time:

skeleton for page-level loading
spinner for short local work
inline pending text for actions
progress indicator for long tasks
dim existing content during refresh

Avoid replacing everything with a spinner if the user already has useful data.

That creates unnecessary flicker.

Empty States

A good empty state answers:

why is this empty
is it expected
what can the user do next
does the user have permission
can filters be cleared
can data be created

Example:

No results match these filters.
Clear filters or try a broader search.

That is better than simply saying No data.

Error States

Error states should include:

plain language
scope of failure
retry action if useful
support path if needed
technical detail only when helpful
accessible announcement

Do not expose raw stack traces to users.

Do not hide useful recovery steps from users.

Partial States

Partial states happen when:

main content loads but sidebar fails
some widgets fail
cached data exists but refresh fails
permissions hide part of the UI

Partial failure is often better than total failure.

But the UI must be honest.

Layout Stability

Good states preserve:

card dimensions
button positions
heading hierarchy
scroll position
table structure
focus location

Loading and error states should not cause a jarring layout jump.

Stable dimensions make the UI feel intentional.

Accessibility

Check:

loading announced only when meaningful
errors connected to controls
empty state heading is clear
retry button reachable
focus not stolen unnecessarily
color not the only signal

State UX and accessibility are connected.

If the state is unclear visually, it is usually unclear semantically too.

Analytics

Track important states:

empty result frequency
retry clicks
error category
load time
abandonment after error
filter clears

These signals tell whether states are helping or hurting.

Empty states can reveal product or search-quality problems.

Testing Plan

Test:

initial loading
refresh loading
empty result
retryable error
non-retryable error
unauthorized state
keyboard access to recovery action
layout does not collapse

Use mocked API responses to make states deterministic.

Common Mistakes

• Designing only the success state.
• Showing the same message for empty and error.
• Removing useful existing data during refresh.
• Making retry invisible.
• Ignoring unauthorized states.
• Causing layout jumps.
• Not testing error paths.
• Using vague copy like Something went wrong everywhere.

Final Mental Model

Complete UI states are:

truthful
stable
recoverable
accessible
measured
tested

A product feels mature when even failure has been designed.