How to Use a Was This Helpful Widget

By the time you finish you will have a feedback widget configured so that the useful part - what the reader types after voting No - reliably reaches a person who can act on it. The vote itself is the least valuable output. It is self-selected, sparse, and it measures the reader's mood at the moment they gave up as much as it measures your article.

Before you start

Decide where responses will land and who reads them, before you turn the widget on. A feedback control with no destination collects negative comments for months and teaches your readers that nobody is listening. If nobody has an hour a week for this, the widget is worse than no widget.

Check your privacy notice too. A free-text box invites people to paste account details, order numbers and occasionally passwords, so the responses need the same handling as support tickets.

Steps

1. Ask a question with one interpretation.
   "Was this helpful?" conflates several things: a reader who found the answer but resented the effort, one who found nothing, and one who found the answer and disagreed with it all answer differently. "Did this answer your question?" narrows it to something you can act on.

2. Put it at the end of the article, inline.
   A floating widget interrupts; a footer widget catches people at the natural decision point, when they have either finished or given up. Both moments are informative, and neither is served by a modal.

3. Open a free-text box after a negative vote, and make it optional.
   One field, no label beyond "What were you looking for?", no required fields. This text is the entire value of the exercise. Everything else is decoration around it.

4. Never require an email address to submit feedback.
   Asking for contact details converts a two-second action into a decision about privacy, and response rates collapse. Offer an optional field for a reply instead.

5. Capture context automatically with every response.
   Article URL, timestamp, the search query that led there if you have it, and the device type. A comment saying "this doesn't work" is unusable alone and often obvious once you know which article and which route.

6. Route responses to a human, weekly, with a fixed reviewer.
   A shared inbox with no owner is where this dies. One named person, one recurring half hour, a note of what they changed.

7. Read the comments and ignore the ratio.
   Three people describing the same missing step is a bug report with three witnesses. A few points of movement across a few dozen votes is noise, and treating it as a signal will send you rewriting an article that was fine.

8. Set a written trigger for action.
   For example: two or more comments naming the same gap in one month means the article gets edited that month. A rule decided in advance stops the queue turning into a reading exercise.

A thumbs-down with no follow-up question tells you something is wrong and nothing about what.

Common mistakes

Treating the percentage as a quality score. Only a small and unrepresentative fraction of readers vote, and irritation motivates voting more than satisfaction does. The score tracks the emotional temperature of your traffic mix, which changes when a feature breaks or a campaign sends new users to an old page.

Comparing scores between articles. A "payment failed" article will always score below a "what's new" page, because the first is read by people having a bad day. Ranking articles by helpfulness score mostly ranks them by how upset their readers were on arrival.

Collecting votes nobody reads. This is the standard failure. The widget is installed in an afternoon, the reading habit is never established, and eighteen months later there are four thousand responses that nobody has ever opened.

Asking more than once per session. A modal on arrival plus a footer widget plus an exit survey trains people to dismiss all three. One ask, at the end, at most.

Removing the widget after a run of bad scores. The scores were never the point, and switching it off deletes the only channel where a reader can tell you what was missing without opening a ticket.

When this stops scaling

This instrument fails at both ends of the volume range, which is unusual and worth planning for. Below roughly a thousand views a month on an article, you will get a handful of responses and no statistical signal whatsoever - treat each comment as an individual bug report and never compute a rate. Above a few hundred responses a month across the help centre, reading every one stops fitting into anybody's week, and the weekly review degrades into sampling the most recent page.

The middle band where this method genuinely works is narrower than most teams expect. Past it, the practical move is to stop depending on readers volunteering feedback and start capturing the questions your help centre could not answer directly - search queries with no result, and questions asked of any assistant sitting in front of the documentation. Those arrive without anyone choosing to fill in a form, so they are not filtered by irritation. SupportPages records them per help centre. That is a different signal from a helpfulness vote rather than a better one, but it has the advantage of not depending on goodwill from someone who is already stuck.