Explain UI feedback and implement immediate feedback for API calls

What's really being asked

This question evaluates whether you understand Jakob Nielsen's visibility of system status heuristic as an engineering requirement, not just a design platitude. Interviewers want to see that you bridge UX principles with concrete frontend architecture decisions, particularly around asynchronous state management and network latency.

The full answer

Four things in order. First, a crisp definition of feedback as real-time communication of system state that keeps users informed and in control. Second, a technical strategy for immediate local response before the API resolves, such as optimistic UI updates that assume success and allow rollback, disabled buttons with loading spinners to prevent duplicate submission, or skeleton screens that indicate activity. Third, the resolution phase where the UI transitions to a success state like a checkmark or toast, an error state with retry options, or a rollback to the previous state if the call fails. Fourth, accessibility and performance considerations such as ensuring screen readers announce state changes and avoiding layout shift during the transition.

The mistakes people make

Three red flags stand out. One is describing only the API call without any local state change, leaving the user staring at a frozen screen. Another is conflating feedback with generic loading overlays that block the entire interface rather than targeting the specific element being interacted with. A third is ignoring failure paths entirely, as if every network request succeeds instantly.

What usually comes next

Interviewers often push deeper by asking how you would handle race conditions if the user clicks rapidly, how you debounce or throttle the action, how you retry failed requests, or how you keep feedback accessible for users on slow networks or assistive devices.

A concrete example

Imagine a user clicking a Save button on a profile form. The button immediately disables and shows a spinner while the label changes to Saving. Simultaneously, the form fields enter a read-only state to prevent edits during submission. If the API returns 200, the button swaps to a Saved checkmark for two seconds before reverting to Edit; if it returns 500, the button re-enables, fields become editable again, and an inline alert appears with a Retry action. This sequence communicates each state change within milliseconds so the user never doubts whether the system registered the click.