In a university course-registration portal, students see the same 'No courses' message for an empty plan, filters matching nothing and a failed catalog request — what is wrong, and how should the collection's empty states be designed?
answer
- why is it empty
- first use, no results, cleared
- an error is not an empty result
- keep filters visible and undoable
- say the count out loud
basics
~20 sOne message hides three different causes, and the error case is false. Design each state separately: explain first-use and offer the next step, show and relax filters for no results, and show an error with retry when data failed.
solid answer
~50 sAn empty collection has several causes, and each needs different words and actions. A **first-use** empty state, such as an empty course plan, explains what will appear here and offers the next step, 'Browse courses'. A **no-results** state after searching or filtering echoes the query and active filters, offers to remove them one at a time, and may suggest near matches such as another term's sections. A **cleared** state, like no pending waitlist requests, is a positive confirmation. A **failed request** is not empty at all: showing 'No courses' tells students a course is not offered when the portal simply does not know, so it needs an error with a retry. In every case, keep the collection's header and filters in place, and announce the result count — WCAG treats 'No results returned' as a status message.
go deeper
Recall that an empty collection should explain itself and offer a next step, and that an error must never be shown as 'nothing found'.
Explain the distinct states — first use, no results, cleared, no access, error — and what each shows, including echoed filters and relaxations for no results.
Diagnose collapsed empty states in a real product, separate errors from empties, and make zero-result counts reach screen readers as status messages.
Make empty and error states a system component with written rules, so every team distinguishes causes and no product ever reports an outage as 'no results'.
## Why one message is a defect An **empty state** is what a collection shows when it has no items to display. Treating every empty collection the same way hides the *reason* it is empty, and the reason decides what the user should do next. In the scenario, three very different situations produce the same 'No courses': - a new student's **course plan** is empty because they have not added anything yet; - a **search with filters** — 'Computer Science, Friday, 4 credits' — matches no sections; - the **catalog request failed**, so the portal has no idea what exists. The third is the most harmful: it asserts something false. A student can conclude that a course is not offered this term and plan around it. ## The states a collection spec should define | State | Cause | What to show | Primary action | |---|---|---|---| | **First use** | Nothing added yet | What this collection is for, in one or two sentences | 'Browse courses' | | **No results** | Query or filters exclude everything | The query and active filters, and why nothing matched | Remove a filter, clear all, or try a suggestion | | **Cleared** | The user finished everything | A short positive confirmation | Often none, or a link onwards | | **No access yet** | Registration window not open, or permission missing | When or how access opens | Link to dates or to request access | | **Error** (not empty) | The data could not be loaded | That loading failed and whether anything was saved | 'Try again' | ## Anatomy of a good empty state 1. **Headline** that names the situation: 'No sections match your filters'. 2. **Explanation** of why, in plain words, without blaming the user. 3. **Action**: the one next step that moves the user forward. 4. **Optional illustration**, which is decorative and gets no text alternative. ## Designing the no-results state - **Echo the query and filters** so users can see what they asked for: 'Computer Science · Friday · 4 credits'. - **Offer to relax constraints one at a time**, ideally showing how many results each removal would give: 'Remove Friday (12 sections)'. - **Suggest near matches**: the same course in another term, or sections with a waitlist. - **Keep the filter controls visible and editable**; never replace the whole screen with the message. - **Distinguish 'no results' from 'nothing exists'**: a department with no courses this term is a different message from a filter combination with none. ## Announcing the state WCAG 2.2 SC **4.1.3 Status Messages** (Level AA) covers messages about the results of an action that do not move focus. Its Understanding document names 'No results returned' and '18 results returned' as status messages, while the list of results itself is not one. So the result count — including zero — should reach screen-reader users without moving focus, and the empty-state headline should be the text they hear. A search that silently shows an empty region leaves a screen-reader user unsure whether anything happened. ## Keeping errors honest - An error state says loading **failed**, not that there is nothing. - It keeps whatever **partial data** is trustworthy and marks what is missing. - It offers **retry**, and a way onward if retry keeps failing. - It never reuses empty-state copy, even when both happen to render nothing. ## Making it a system rule Because every product team builds collections, the design system should ship an **empty-state component** with slots for headline, explanation, action and optional illustration, plus written guidance naming the states above. The coded branches that decide which one to render belong to the application; the words, structure and rule that an error is never shown as empty belong to the system.
- Should a no-results state automatically drop filters and show something instead?Not silently. Showing results the student did not ask for, without saying so, makes them believe those results match their filters. It is fine to say 'No Friday sections — here are 4 on Thursday' with the relaxed filter named and easy to restore. The user stays in control of what they are looking at.
- What should an empty state show when the user lacks permission to see the items?It should say that access is the issue, not that nothing exists — for example, 'Registration for spring opens on 3 November' or 'Only advisers can see this list'. Showing a plain empty collection would mislead in the same way an error shown as empty does, and the user would have no path forward.
saying these in an interview costs you the question
- A failed request can safely show the no-results message
- One generic empty message is enough for every collection
- An empty state should replace the filters so the message stands out
- Screen-reader users can infer zero results from silence
- Quietly dropping filters to avoid an empty page is always helpful