| Author: Abdullah Ahmed | Category: UI/UX Design
A project manager opens a report and sees “No data.” The report might contain no records, the filters might exclude everything, or the data service might have failed. The same message hides three different situations and leaves the user unable to choose a useful next step.
Empty states, errors, and notifications explain the relationship between a person's action and the system's current state. Good feedback helps people understand what happened, what remains uncertain, and what they can do next. It should be designed with the underlying workflow rather than added as generic text after implementation.
Name the state before writing the message
Distinguish an empty collection, no search matches, missing permission, loading, unavailable data, and failed processing. These states may look similar in a simple component but have different causes and recovery paths.
Define the state in terms the application can establish. If the service timed out, the interface should not claim there are no records. If a submission's outcome is unknown, it should not claim the action failed completely.
Create a small state map for the important journey. Include what triggers each state, which information is available, and which actions are permitted. This gives designers and developers a common basis for message and control behaviour.
Review the map with support staff. They often know the questions users ask when a status is unclear and the information needed to resolve it. Their input can prevent an attractive message from being operationally unhelpful.
Make first-use empty states useful
A new workspace may legitimately contain no projects or records. Explain what belongs there and provide the appropriate first action. The message should help the user begin the task that brought them to the product.
Tailor the action to the person's role. An administrator may create the first record, while an invited user may need to wait for an assignment or contact a workspace owner. Do not offer an action the user cannot perform.
Use examples sparingly and label them clearly. Sample data can teach the product, but users should not mistake it for actual business information. Provide a clear way to remove or distinguish demonstrations.
Avoid filling an empty state with promotional copy unrelated to the task. The space is an opportunity to explain the workflow, not an obligation to display a large illustration or lengthy onboarding message.
Explain no-results states through the current query
When filters or search produce no matches, preserve the search terms and active filters. Show which criteria are in effect and offer useful ways to revise them. Users should not have to remember what narrowed the result.
Distinguish no matches from unavailable search. A failed request needs retry or support guidance; a valid empty result needs query refinement. Mixing them can send users through unnecessary changes that cannot solve the problem.
Suggest alternatives only when they are supported by the product. Clearing filters, correcting a likely term, or broadening a date range may help. Avoid presenting arbitrary recommendations that do not relate to the user's intent.
Test the state with realistic queries and permissions. A user may see no records because access is limited, and the explanation should respect information boundaries while remaining useful.
Write errors around correction and consequence
An error message should identify the problem and the next useful action. For a field, explain the required correction in familiar language. For a service failure, explain what the user can safely retry or how to obtain help.
The W3C guidance on error identification addresses identifying and describing detected input errors in text. Use that principle with the form's actual behaviour and the needs of its users.
Avoid blaming language or vague apologies that replace useful information. “Choose a date after the start date” is more actionable than “Invalid input.” Technical details can be available to support through a safe reference without dominating the user message.
Explain consequences when they matter. If an upload failed and nothing was saved, say so when known. If some records were processed, identify the partial result and the remaining work.
Preserve effort during recovery
Keep appropriate form input after validation failure. Direct the user to the relevant problem and allow correction without repeating unrelated work. For longer forms, combine a useful overview with field-level messages.
Plan session expiry and navigation interruptions. Some information can be safely retained, while sensitive content may require different handling. The product should have an intentional policy and explain important limitations.
Test recovery from the moment the problem occurs through final completion. A well-written message does not help if the next action clears the form or returns the person to an unrelated page.
Consider repeated failures. After several unsuccessful attempts, the user may need an alternative route or a support reference. The application should not trap them in an identical loop with no new information.
Distinguish failure from an uncertain outcome
A network interruption after submission can leave the client unsure whether the server completed the action. The interface must avoid encouraging a duplicate payment, booking, or message when the original may already exist.
Coordinate with backend safeguards and status lookup. A stable operation identifier can help the application check the result or resume safely. The message should reflect what the system actually knows.
Use wording such as checking the result only when the application is genuinely doing so. If a manual review is required, explain that path and what the user should avoid repeating. Do not hide uncertainty behind a confident success or failure label.
Include this case in acceptance testing for consequential actions. It often reveals a gap between interface design and transaction handling that a normal success demonstration misses.
Choose notification channels by urgency and persistence
A small transient confirmation can suit a low-impact completed action. A problem requiring attention may need to remain visible near the relevant work. A critical interruption may justify a stronger presentation, but should not be used for ordinary information.
Decide whether the user must act now, later, or not at all. That decision should guide placement, persistence, and available controls. Avoid using one toast component for every type of event.
Consider whether the user is currently viewing the affected record. A background export completed elsewhere may need a persistent notification centre or another agreed channel. A brief message on an unrelated screen may be missed.
Coordinate in-app and external messages. Users should not receive conflicting status from email and the interface. Define which system owns the notification and what evidence triggers it.
Make feedback accessible without unnecessary interruption
Important status changes need to be perceivable by the interaction methods users rely on. W3C status-message guidance explains relevant considerations for assistive technologies without automatically moving focus.
Use focus movement deliberately. A dialog requiring a decision differs from a routine save confirmation. Unexpectedly moving focus can interrupt the task, while never moving it can leave a user unaware of a blocking problem.
Do not rely only on colour, sound, or motion. Include readable text and appropriate structure. Test increased text size, keyboard use, and the actual assistive-technology behaviour of the implemented components.
Give users enough time to perceive and act on important information. A disappearing error that contains the only recovery instruction is difficult to use. Persistence should match the message's consequence.
Design partial success as a distinct state
A bulk import may create some records and reject others. Show the completed and unresolved counts accurately, with a route to inspect failures. Avoid a single success banner that conceals remaining work.
Explain whether retry applies to all records or only failed ones. The implementation needs safe identity and processing rules so the recovery action does not duplicate successful work.
Provide a useful error export or summary where appropriate. Include enough context for correction without exposing unnecessary sensitive data. Staff should be able to connect each issue to its source record.
Test mixed outcomes with realistic volume. A design that works for two failures may become unusable for several hundred. Consider filtering, grouping, and staged resolution according to the task.
Keep notification volume manageable
Repeated low-value messages can teach users to ignore the system. Review which events deserve interruption, which belong in history, and which need no explicit notification beyond a visible state change.
Group related events where doing so preserves meaning. An import producing many similar warnings may need one summary with detail rather than a stream of individual alerts. Critical exceptions should remain distinguishable.
Offer preferences where they support the user's role and the business requirements. Some operational notifications may be necessary, while optional updates can be configurable. Make the consequences of muting clear.
Measure missed actions and support confusion alongside message engagement. A notification being opened does not establish that it was useful or understood. Evaluate whether the intended work happens.
Use a content pattern library
Document recurring message structures, terminology, and examples. Include the state, consequence, action, and support reference where needed. Keep examples connected to actual product behaviour.
Allow meaningful variation. A deleted draft and a failed payment require different tone and detail. Consistency should help users understand the system, not force every situation into the same sentence.
Plan for localisation. Avoid messages assembled from fragments that become awkward in another language, and provide context for translators. Layouts should accommodate longer text without hiding controls.
Review message changes with developers when they imply a different guarantee. Replacing “request received” with “completed” is a behavioural claim, not a harmless copy edit.
Distinguish destructive confirmation from routine feedback
A confirmation step can help when an action has significant or difficult-to-reverse consequences. It should identify the object and effect clearly. A generic question asking whether the user is sure provides less protection than a specific explanation of what will happen.
Do not add confirmation to every ordinary action. Repeated unnecessary dialogs can train users to approve without reading. Where an action is safely reversible, an undo option may be more useful, provided the application genuinely supports it.
Explain the limits of undo. Restoring a draft and recalling an external message are different capabilities. The interface should not imply that a completed external effect can be reversed if the system can only make a compensating change.
Test the confirmation with realistic names and scope. A bulk deletion should identify the affected set and count, not merely the last visible row. Users need the information that would reveal a mistaken selection.
Coordinate the message with server-side checks. The state may change between opening a confirmation and submitting it. The backend should still validate the action and return an accurate result.
Give support references a useful purpose
A safe reference number can help support staff locate a failed operation without asking the user to reproduce sensitive information. The reference should connect to the relevant diagnostic record and be easy to copy.
Keep the primary message understandable without the reference. Users should know whether to retry, wait, correct input, or contact support. An opaque identifier is supporting information, not the explanation itself.
Test the support handoff. Can the receiving team locate the issue, determine the actual state, and identify a permitted next action? A reference that points to an inaccessible log does not complete the recovery journey.
Review what diagnostic information is retained and who can access it. Error handling should not create an unnecessary store of credentials or personal data. Capture the evidence needed for the task under the approved operating policy.
Use recurring support patterns to improve the product. If the same reference category appears repeatedly, investigate its cause or make the recovery route clearer. The goal is fewer unresolved interruptions, not simply better tracking of them.
A message review exercise
For each important message, ask a reviewer to identify the actual state, the consequence, and the next safe action. Then compare those answers with the implementation. Any mismatch is a design or engineering issue to resolve.
Repeat with a participant who has not seen the feature before. Familiarity can hide ambiguous wording. A message is effective when the intended user can interpret it in context, including during a stressful interruption.
Use the same truth in every channel
A notification centre, email, and record detail page should describe the same underlying event consistently. If one says an export is complete while another says it failed, users cannot know which to trust.
Identify the authoritative state and how each channel receives updates. Consider delayed messages and later corrections: an old email may remain in the inbox after the job has been retried successfully. Provide a route to the current record where useful, and avoid wording that suggests a historical message is a live status display. This is a data-flow decision as well as a writing decision.
Test the ambiguous report screen
Return to the report displaying “No data.” Create separate tests for a genuinely empty period, filters excluding all records, insufficient permission, loading, and an unavailable data service. Define the explanation and action for each.
Have participants use the screen without knowing which case they are in. Ask what they believe happened and what they would do next. Their answers should align with the actual state and safe recovery path.
Repeat with keyboard navigation and increased text size. Check that messages remain associated with the relevant controls and that a loading transition does not leave focus in a confusing place.
Start with the states that currently generate repeated questions or risky retries. Clear feedback is complete when people can understand the result and continue safely, including when the system has not produced the outcome they expected.
Author
With over 15 years of diverse experience spanning front-end and back-end development, UI/UX design, project management, integration, testing, and ongoing support for business applications, I specialize in transforming ideas into seamless digital solutions. I’m committed to leveraging my expertise to drive innovation and contribute meaningfully to the tech community.