Designing honest loading and empty states for a rank-checking interface

This article was prepared with AI assistance. It proposes a design checklist for a hypothetical rank-checking interface; it does not describe a deployed product, a user study, or measured performance results.

A search measurement interface often looks simple in its successful state: a query, a result, and perhaps a page address. The harder design work starts when the interface has no result to show. A request may still be running, the current filters may hide available records, or a check may finish without finding the expected page within its scope. Treating those situations as one blank panel makes the interface difficult to understand. This article proposes a small state vocabulary that a product team can review before building the screen.

Begin with what the application actually knows

Write a sentence for each state before choosing an icon or illustration. An idle screen can say that no check has been requested. A loading screen can say that a request is in progress. A completed check can display its result alongside the conditions used. A failed request can say that the application could not complete the check. These sentences express different facts. The implementation should preserve those differences rather than deriving all display copy from whether a result array currently contains items.

For a hypothetical tool, define idle, validating, loading, completed, failed, and cancelled as separate review cases. Your real application may need different cases, but every additional state should answer a concrete user question. Avoid adding categories merely because a state diagram can accommodate them. Ask what the user can do next, what information remains trustworthy, and what the application cannot yet conclude. This exercise turns an empty screen into an explicit product decision that designers, developers, and reviewers can discuss together.

Keep a previous result attached to its original request

Consider a user who checks one query and then starts a second check. If the first result remains on screen, label it as the previous result while the new request runs. Otherwise, the user may read an old page address under a newly edited query. One practical layout is to show the submitted query and its conditions inside the result card, while keeping the editable form above it. The card then describes the observation that produced it rather than whatever text currently occupies the form.

Choose a clear rule for replacing that card. You might retain it until a new request succeeds, or replace it immediately with a loading panel. Either choice needs deliberate copy and a review case. If you retain it after a failure, explain that the attempted check failed and the displayed card belongs to an earlier successful request. Do not silently present the earlier card as a fallback result for the failed request. Preserving useful information is helpful only when its origin remains visible.

Separate missing results from request failures

A request failure describes the application's attempt to obtain information. A completed check without the expected page describes an observation made under the check's conditions. The interface should not use the same headline for both. For example, a failure message could explain that the check could not finish and offer a retry. A completed observation could identify the query and scope, then state that the expected page was not found within that scope. The wording should match what the actual method supports.

Avoid turning limited observations into claims about the whole search ecosystem. A hypothetical interface should not infer that a page has disappeared everywhere merely because one check does not return it. Place relevant limits near the result instead of hiding them in a distant help page. If your method checks a bounded set of results, describe that boundary honestly. If a condition is unknown, display it as unknown. The product specification should identify which statement is supported by the available data before anyone writes reassuring or alarming copy.

Give loading messages an end condition

A spinner alone tells the user very little about the task. Pair the loading state with a plain description of the submitted action and make clear whether the user can edit the form, start another request, or cancel. These are product choices rather than universal rules. For a simple interface, preventing a duplicate submission while the same request is active can make the workflow easier to reason about. If parallel requests are supported, provide a way to tell their results apart.

Review what happens when a request takes longer than expected. Do not display a percentage unless the application actually measures progress in a way that supports it. A message such as waiting for the check to finish can be more honest than a fabricated progress bar. Decide how the request reaches a failure or timeout state, and what the user sees at that transition. If cancellation is available, distinguish cancelling the interface workflow from any server operation whose cancellation cannot be guaranteed by the client.

Treat status announcements as part of the interface

Dynamic text should be reviewed with assistive technology as well as visually. MDN describes the ARIA status role as an advisory live region with implicit polite announcement behavior. It also advises against moving focus to that region simply because its content updates. See the MDN status role reference for the underlying behavior. A team's implementation should still be checked in the browsers and assistive technology combinations relevant to its audience.

A practical review case is to submit a check using the keyboard and listen to the resulting announcement. Can the user tell that a check has started and later finished without losing their place? Does the application repeat the entire result table when only a short status message is necessary? Keep the announcement concise and let users explore detailed results in the ordinary page structure. The goal of this review is a coherent interaction, not the presence of a particular attribute in an inspection tool.

Make recovery specific to the problem

A retry button is useful only when retrying has a plausible purpose. If the query is missing, the message should identify the missing input and help the user return to it. If the request failed after valid input, preserve that input so the user does not have to reconstruct it. If active filters produce an empty view of stored records, explain that the filter selection is responsible and offer a clear route to adjusting it. These cases should have different recovery actions.

Avoid generic instructions that send every problem to a support channel. A short message can state what happened, which information remains available, and what the user can try. Do not promise that retrying will succeed. For a persistent failure, you can provide a reference identifier if the application supports one, while keeping technical diagnostics out of ordinary copy. Review whether a proposed recovery action causes duplicate requests or accidentally discards the previous observation. Recovery should be tested as a workflow rather than reviewed only as a button label.

Review transitions, then record decisions

Create a compact review matrix covering an initial visit, a valid submission, invalid input, a slow request, a failed request, an empty filtered view, and a second submission after a successful result. For each case, record the visible statement, available action, preserved information, and focus behavior. Use invented example queries and explicitly label them as fixtures. This makes the review repeatable without exposing customer data or suggesting that the fixture represents actual search behavior.

Finish by recording the decisions that could otherwise remain implicit: whether previous results stay visible, whether cancellation is supported, which conditions appear on a result card, and which empty states have their own messages. Assign an owner to unresolved questions. A clear interface state is a small contract between the application and its user. It says what the application knows at that moment and offers an appropriate next step. That contract is worth designing before polishing the successful result screen.

Project context

We share these interface notes from the SEOLOK account. The SEOLOK rank-checking project provides the context for this proposed checklist; this article does not claim that the described states have been tested in the deployed product.