What should a feedback button say?

Why the label does more work than the design

A visitor sees a feedback button once and decides in a second whether to click it. The label answers two questions: is this for me, and what happens if I click? A vague label makes people hesitate. A specific label sets the expectation before the panel opens.

The floating button in the Escuta Produto widget reads "Feedback" in English and in Portuguese, next to a speech bubble icon. That works as a default. The word is short and familiar, but it names a thing rather than an action, so the visitor still has to guess what the form will ask.

Verbs or nouns: which reads better?

A verb tells the visitor what they will do. "Send feedback" says they will write something. "Report a bug" says they will describe a problem. A noun such as "Feedback" or "Ideas" names a place to go. That is fine for a help menu, but it is weaker on a button that sits on top of the page.

Use a verb when the button appears near a task that can fail, such as an export screen or a settings page. Use the noun when the button lives in a global corner and the visitor only needs a way to write to you.

Keep labels to two or three words. Long labels get cut off on phones and make a page look crowded. Start with the verb, and drop words such as "our" or "the" that add nothing.

Let the page choose the feedback type

The widget form asks for a type: Bug, Idea, Praise or Other. You can skip that question by preselecting the type from the element that opened the form. Any element with the attribute data-escuta-open opens the panel, and the attribute value sets the type:

<button type="button" data-escuta-open="bug">Report a bug</button>
<button type="button" data-escuta-open="idea">Suggest a feature</button>

This turns one generic button into labels that match the page. For example, a help article about exporting data can offer "Report a problem with export" as a bug, while a team page can ask for ideas.

Page	Button label	Type it opens
Export screen	Report a problem with export	Bug
Feature overview	Suggest an improvement	Idea
Finished onboarding	Tell us how it went	Praise

Two details matter. An element with data-escuta-open and no value opens the panel without changing the type. The panel starts on Idea when the page loads, and it keeps the last type chosen until the visitor reloads. If someone picks Bug, closes the panel and then clicks the floating button, the form still shows Bug. Make sure that is what you want, or set the type explicitly on every trigger.

Localize the label, not only the words

The text on the floating button is fixed. It reads "Feedback" in both languages, and no attribute changes it. The form around it does switch with data-locale, so a Portuguese page shows a Portuguese panel behind an English button. If that mix bothers you, hide the default button and use your own translated label.

Write each label for the language a visitor reads, not as a word-for-word translation. "Report a bug" becomes "Reportar um bug" in Portuguese, and "Suggest a feature" becomes "Sugerir uma melhoria". Translated text is often longer, so test both versions beside the other buttons on the page.

Replace the default button

When you need your own label, hide the floating button and place your own trigger. Set data-trigger="none" on the script tag:

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

Then put any element with data-escuta-open where you want it, such as a help menu, a footer link or a settings row. Keyboard users reach it like any other button. When the panel closes with Escape, focus returns to the element that opened it, so the flow stays predictable.

If a button needs a script handler, you can call the widget directly with EscutaProduto.open({ kind: "praise" }). The call works after the script has loaded, and the queue form covers calls made before that.

Pick wording you can keep

Labels change more often than people expect. Choose words that still make sense after a redesign, and avoid product names that might change. Put the label in your translation files next to the other buttons, so one person can update all of them in the same review.

Keep a short list of every trigger label on your site, with its page and its type. When a new page adds a button, the list shows whether the wording already exists somewhere else, and whether the type it opens matches what the page is for. A spreadsheet with three columns is enough for most sites.

Once the labels are set, check the form itself. The widget docs list every attribute, and how to make a feedback widget accessible covers the keyboard and screen reader path for a custom trigger. For the wider question of when to ask, see how to collect customer feedback.

How to set this up in Escuta Produto

Start with the default. Watch which type visitors pick from the floating button for a week, using the type counts on the product dashboard. If most messages on a page are bugs, add a bug trigger there. If praise dominates a page, a praise trigger may fit better. Then hide the default button with data-trigger="none", add your labelled triggers with data-escuta-open, and check the inbox to confirm each one arrives with the type you expected.