AI for Planning Clear Empty State Content
As of 2026-10-19 · the AZET team. This article offers a fictional interface exercise for fun and reference. We are sharing an editorial method, not announcing product functionality.
No items yet can describe several different situations. A person may have opened a collection for the first time, searched with an overly narrow term, or applied a filter that hides every item. Giving all three situations the same sentence leaves the reader to work out which one they are in.
An empty state is the content shown when a view has no items to display. For this exercise, the job is to explain that condition and offer a next step supported by the interface. You can use an assistant to compare drafts after you define the state. The definition is the part that deserves the most care.
Start with an imaginary collection
Imagine a small app for collecting descriptions of interesting doorways. Its fictional interface has a collection view, a search box, and a district filter. Do not assume it includes importing, recommendations, sharing, or any other function. The exercise becomes more useful when the feature list stays small.
Write three state cards. The first says the collection contains no saved entries. The second says the collection has entries but the search has no matches. The third says a district filter hides all entries in the current view. Those are different reasons for the same blank area.
For each card, write what the person can do next. In this fictional design, they can add a description, change a search term, or clear a filter. A button label that points to an unavailable action is a content defect even if the sentence sounds inviting.
Match the message to the condition
Here is a hypothetical starting point:
| State | Heading draft | Available next step |
|---|---|---|
| New collection | Your doorway collection starts here | Add an entry |
| Search has no matches | No entries match this search | Change the search |
| Filter hides entries | No entries in this district view | Clear the district filter |
These drafts are deliberately plain. They distinguish the reason the view is empty. You can refine the voice after that distinction survives review.
Notice what the table does not establish. It says nothing about whether information was deleted or whether a service is unavailable. Those conditions need their own state definitions. Do not let an assistant fill a blank screen with a message that assumes one of them without evidence.
Ask for alternatives with a fixed action
A useful prompt is:
Draft two empty-state options for each supplied state card. Keep the reason for emptiness distinct. Use only the action named on the card. Return a heading, one supporting sentence, and an action label. Flag any missing information instead of inventing a feature or a recovery claim.
Give the assistant the cards and the terminology used elsewhere in the interface. If the app calls each saved object an entry, avoid switching to memory, item, or discovery simply to make the wording more colorful.
Compare alternatives on meaning first. Ask whether someone can tell why the view is empty and whether the action fits that reason. A charming sentence that tells a reader to add an entry when they only need to clear a filter creates unnecessary work.
Review the first visit without inventing social proof
A new collection can feel sparse. That is not a reason to fill it with fictional testimonials, usage counts, or example entries presented as personal data. If you include sample content, label it as a sample and decide how it differs visually from saved work.
For the doorway exercise, a single clearly marked example description might explain the format. The wording should also make clear whether the example is part of the collection. Otherwise, a person may try to edit or remove something that was intended only as guidance.
Keep the introductory instruction small enough to act on. An empty state should not require reading the whole product manual before adding one entry. Put optional explanation somewhere the interface actually supports, and verify that the destination exists before referring to it.
Read the states as a sequence
Review what happens before and after each message. Begin with an empty collection, add an entry in the fictional walkthrough, search for a term that does not match, and then clear the search. The words should describe each state consistently without implying that the saved entry disappeared.
This is a paper exercise until you test a real interface. Record whether your review covered written mockups, rendered screens, or actual interactions. Those observations answer different questions. A copy review can establish that the state labels are distinct; it cannot establish that the product selects the correct label at runtime.
Keep a decision note for ambiguous cases. If search and filters can both be active, decide which information the reader needs and which clearing actions exist. Do not assume that one generic reset button is implemented.
FAQ
Should an empty state always include a button?
Only when an appropriate action exists. Some views are informational or depend on another person. Clear explanation is better than a button that has no meaningful destination in the current design.
Can I reuse one message across several screens?
Yes, when the condition and next step are actually the same. Compare the state cards before reusing the words. Similar visual layouts do not necessarily mean similar reasons for emptiness.
What if the content is still loading?
Treat loading as a separate defined condition. An empty collection message can mislead if entries have not finished arriving. The copy and implementation should agree on when each message appears.
Following the maker's work
This content exercise is not a documented AZET interface-design feature. The October 3, 2026 maker introduction is our product source here: it describes an AI assistant and an early-access waitlist, without verifying today's live state. For the AZET waitlist, visit azet.io.