Using empty states to collect product feedback

Why an empty state is a moment of intent

An empty state is what a user sees when a list, report or dashboard has no data yet. The screen says "no invoices", "no reports" or "nothing here". Most teams treat that screen as a gap to fill with a generic call to action. It is also a rare moment when the user's expectation is visible. They came to the screen for something, and the screen did not give it to them. That mismatch is valuable.

A user who sees an empty invoice list may expect to see invoices from an import they did not finish, invoices from a different account or a filter they forgot to clear. Each of those expectations describes something about the product that you can learn from. A question at that moment captures the expectation while it is still fresh.

Ask only when the empty state is a surprise, not when it is the normal first screen for a new account. A user who has never imported anything is not confused by an empty list. A user who imported last week and sees nothing now is.

Write the empty state copy as a question

Most empty states explain what would fill them. Add a second line that asks what the user expected. The copy is short and specific: "No reports yet. Were you expecting to see something here?" The question invites an honest answer, and it does not sound like a survey.

Keep the main call to action where it is. The feedback prompt sits beside it, as a secondary option. A user who wants to create a report should still see the create button first, because that action helps them more than writing feedback.

Avoid the words "survey", "rate" or "help us improve". They make the moment feel like homework. The best prompt uses the user's own situation: "Were you expecting reports from last month's import?" That question is specific enough to get a useful answer.

Connect the button to the widget

Use the widget without its floating button, so the prompt appears only on the screens you choose. Set data-trigger to none on the script tag, then add a button with data-escuta-open on the empty state. The value preselects the type. For this moment, idea fits most cases because the user is describing what they expected, which is usually a missing or unclear capability.

<script src="https://escutaproduto.com/widget.js" data-key="pk_your_product_key" data-trigger="none" defer></script>

<section>
  <h2>No reports yet</h2>
  <p>Were you expecting to see something here?</p>
  <button type="button" data-escuta-open="idea">Tell us what you expected</button>
</section>

If the empty state is built with a framework component, keep the attribute on the element that the user clicks. The widget listens for clicks on that attribute, so the button can live inside any component.

Tag the screen in metadata

The widget saves the page URL automatically, but an empty state often lives at a URL shared with other states, such as a list page that shows a different message after a search. A screen name in metadata makes each answer specific. Set it before the form opens, using a short name that matches your code.

document.querySelector("#empty-reports").addEventListener("click", () => {
  EscutaProduto.setMetadata({ screen: "reports-empty", importStatus: "none" });
  EscutaProduto.open({ kind: "idea" });
});

Use only details that help you understand the expectation. A screen name and a simple status are useful. A full list of the user's data is not needed, and metadata has a 4 KB limit anyway. Keep the data minimal, because everything in metadata is stored with the feedback item.

Read the answers as missing features and unclear copy

Empty state answers fall into two groups. The first group describes a feature the user expected and did not find. Those answers become ideas, and you can count distinct users who asked for the same thing. The second group describes confusion: the user thought data should be there, but the import or filter that would have produced it was unclear. Those answers point to copy or onboarding changes, and they are often cheaper to fix.

Read the screen name alongside the message. If many answers come from one screen, the screen is the problem. If answers come from many screens about the same missing thing, the problem is probably a missing feature. The guide to prioritizing bugs and feature requests explains how to look for the underlying problem in a request that sounds like a feature.

Keep the prompt from nagging

An empty state is seen many times by the same user, so the prompt must not repeat on every visit. Show the feedback button on the empty state, but do not open the form automatically, and do not add a second prompt to the same screen. If a user has already answered, the button can stay visible for the next time they need it. Repeated requests make people feel that the product is asking the same question over and over.

Respect the moment as well. A user who has just signed in for the first time and sees an empty dashboard is still deciding whether the product is for them. Give them the create action first, and keep the feedback prompt quiet. The onboarding feedback guide covers how to ask during setup without interrupting it.

Adding an empty state entry point in Escuta Produto

Find the empty states that users actually see after the first week. Add one button to each, with data-escuta-open set to idea, and set the screen metadata on click. Check the inbox after a week, and read the answers for that screen together. Escuta Produto has no tags, so the screen name in metadata is the grouping key.

Use the widget docs for the attributes and the open method. If your screens are rendered by a framework, the Next.js guide shows where the script goes in the layout so every page can use the same entry point. For the wider case for asking inside the product, see what is in-app feedback.