When you share a product demo while building in public, show the empty screen as well as the populated one. Explain why it is empty and give the viewer a relevant next action. First use and a search with no matching results can look similar while requiring different help, so review them as separate states.
A polished demo full of prepared records answers one question: what does the product look like once useful content is present? A new user may arrive before that point. A founder peer can give more focused feedback when the public walkthrough includes the conditions behind the blank screen and the task that should follow it.
Start with two blank screens that mean different things
Consider a fictional request tracker for small agencies. A newly created workspace contains no client requests. Later, a workspace with existing requests can also show an empty list when the user filters for a category that has no matches. Both views have zero visible rows, but the underlying situations are different.
In the first case, the user needs a route to creating or importing the first request. In the second, the user needs to understand the active filter and how to change it. Sending both people through the same welcome tour would ignore the task they are actually trying to complete.
Vercel's Geist empty-state guidance distinguishes first-use blank slates from no-results, cleared, permission and failed-load states. Use that distinction to plan what you will show publicly. The example here is an editorial walkthrough plan, not a claim that this fictional tracker has been implemented or tested.
Name the state before choosing the message
For each empty view, write a short explanation of the condition that produces it. In the fictional tracker, the first condition is an authorized user opening a new workspace with no requests created. The second is an authorized user applying a filter to a workspace that already contains other requests.
Keep permission and loading failures out of those labels. A request that failed to load does not establish that no records exist. A person without access should not be told to create the first item if the records are present but unavailable to them. Those states need their own accurate explanations.
This note can stay simple. Record the starting data, the relevant role, the action that produced the screen and the expected next step. You are making the public example understandable, not publishing internal identifiers or a complete account configuration.
Write the first-use state around the first useful action
A vague fictional message would say “Nothing here yet” above a button labelled Continue. A viewer cannot tell what belongs on the screen or what the button will do. An attractive illustration does not resolve that missing task information.
A more specific version is “No client requests yet,” followed by a sentence explaining that this list will hold incoming work. A primary action labelled “Create a request” names the next step. If importing existing requests is a supported alternative, explain that route without presenting several equally prominent choices.
Geist's guidance describes informational empty states as a place to explain a feature's usefulness and provide an action. Its component rules favor a clear primary action. Apply the principle to your actual workflow, then verify where the control leads. The wording alone does not prove that someone can complete the task.
Give a filtered-empty view a different route back
Now imagine the fictional workspace contains requests, but none match an active “Waiting for client” filter. Reusing “No client requests yet” would describe the workspace incorrectly. It could lead a user to create duplicate work because the screen hides the condition that removed the existing rows.
A suitable hypothetical message is “No requests match this filter,” with the active filter visible and an action to clear it. The user should be able to predict that clearing the filter will show the broader list, rather than adding a new item or resetting the whole workspace.
If the product supports several filters, check which ones remain active after a change. A public screenshot of one empty result may omit another constraint elsewhere in the interface. Include enough visible context for a peer to understand why the result is empty without sharing real client records.
Prepare a short walkthrough with a checkable ending
Use fictional records and a safe workspace you are authorized to show. Start the first-use walkthrough with the empty list, explain its condition, activate the named action and complete one sample request. Reopen the list so the viewer can see the resulting item in the place the message described.
For the filtered-empty walkthrough, begin with the same known set of sample requests. Apply the chosen filter, show the no-results message, clear the filter and confirm that the broader list returns. This sequence checks the specific promise made by the empty-state action.
Keep a note of what you actually observed. A recording can show that the demonstrated path worked under those conditions. It does not establish that every role, account or input works correctly. If you share only static mockups, label them as mockups and ask about the information they communicate.
Ask a peer to explain the screen before showing the answer
Show a relevant reviewer the empty view and ask what they think has happened and what they would do next. For the fictional first-use screen, they might expect incoming requests to appear automatically. That interpretation would reveal a gap if the real product requires manual creation.
For the filtered-empty view, ask what they expect the clear-filter action to change. Avoid telling them the intended meaning before they answer. If they think it deletes requests, investigate the wording and placement rather than treating a polite “looks good” as sufficient review.
I build Buildside. Its public description includes founders sharing progress and finding concrete help. A pair of clearly labelled empty states gives peers a specific review task. Their interpretation remains feedback to investigate; it is not evidence that the whole onboarding experience has been validated.
Check the interaction as well as the explanation
Inspect the action through the input methods your product supports. A visible control should be operable, have a meaningful name and lead to the described route. Geist specifically calls for real buttons or links for empty-state actions. A styled piece of text that cannot be reached or activated would undermine the guidance.
Check the state after the action too. If creating the first request leaves the empty message visible, the walkthrough has uncovered a mismatch between the content and the result. If clearing one filter leaves another active, the message should still reflect the remaining conditions.
You can document these checks without turning the public article into a test report for every interface state. State which route was examined, which methods were used and which related paths remain unchecked. Keep the claim proportional to the work performed.
Publish the condition beside the picture
Give each screenshot or recording a caption that explains the state. For the fictional tracker: “New workspace before its first request” and “Existing workspace with a filter that matches no requests.” These captions make the distinction visible even when an image travels outside its original thread.
If you change the message after review, explain the specific correction. Perhaps the first-use state now says that a person must create a request, or the no-results state now makes the active filter easier to identify. Describe the change without inventing an activation improvement that you have not measured.
For your next public demo, add the screen a new or temporarily blocked reader would actually encounter. Give it a truthful reason for being empty, one useful next action and a checkable result. The populated dashboard can still show the destination; the empty view explains how a person starts or finds their way back.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)