The organisation
The client in this illustrative example is a large public-facing service. People use its website to understand eligibility, complete important tasks and find help when something goes wrong. Some are confident online. Others are anxious, short on time or using an older phone.
The service had collected page feedback for several years. A small panel at the bottom of most pages asked, “Was this page helpful?” Visitors could select yes or no and leave a comment.
There was no shortage of data. Reports showed helpfulness scores by month, page and section. Comments were exported into spreadsheets. A dashboard displayed trends in neat colours.
What the organisation did not have was a reliable way to decide what to fix.
A low score might mean that the content was unclear. It might also mean that the visitor was ineligible, could not sign in or had arrived on the wrong page. A positive score did not prove task completion. It only showed that someone had pressed yes.
The dashboard was doing exactly what it had been designed to do. It counted responses. That was also the problem. Nobody could confidently connect the counts to a service decision.
The question we helped the team ask
The initial request was to improve the feedback score. We paused there.
Trying to raise a score before understanding it can lead to cosmetic changes. A clearer heading might lift sentiment while leaving a broken journey untouched. Removing the panel from difficult pages could improve the average and make the service less accountable.
We reframed the question with the client:
What does the team need to know in order to find, prioritise and verify problems in the service?
Feedback was no longer treated as a satisfaction measure on its own. It became one signal in a wider evidence system.
We began with decisions, not fields
We asked content, product, operations, analytics and support staff what decisions they needed to make. Support knew which questions recurred, but its categories were designed to route contacts. Analytics showed exits and failed events, but not always why. Content staff spotted real problems in comments, but could not consistently show scale or urgency.
We mapped a small set of decisions the evidence should support:
- Is a problem limited to one page, or does it affect a complete task?
- Are people misunderstanding the guidance, or is the underlying service failing?
- Does the issue disproportionately affect a particular audience or access need?
- Is the problem severe enough to interrupt planned work?
- After a change, is there evidence that the task became easier?
Every feedback question needed a clear use. If a field could not help someone decide, we challenged why it was being collected.
Reframing feedback around the task
We tested a more useful sequence that stayed short enough for a tired visitor to answer.
First, the service asked what the person had come to do. Options reflected top tasks, not the internal department structure. The page and journey step were captured automatically, with privacy controls.
Next, the prompt asked whether they had been able to complete the task. If not, it offered a small number of problem categories such as:
- I could not understand what to do
- I could not find the right information
- A form or account did not work
- I need an option that is not offered
- The information does not match my situation
- Something else
An optional comment field asked what happened and warned people not to include personal, medical or financial details.
Visitors could separately consent to follow-up research. The notice explained what contact involved, storage and deletion, and that participation would not affect access to the service.
The research opt-in was separate. Contact information did not appear in operational reports.
Connecting four kinds of evidence
Feedback alone rarely tells the whole story. We helped the team build a working view that brought together four sources.
Page and task feedback
Responses showed the task, journey point and difficulty. Comments added context, but were not treated as representative simply because they were vivid.
Support contacts
We aligned a few support contact reasons with online task categories, making recurring demand visible beside the relevant journey.
Behavioural analytics
Analytics supplied evidence such as repeated validation errors, loops between guidance pages, abandoned forms and returns to the same step. These patterns helped the team check whether reported problems also appeared in behaviour.
Short research sessions
We ran short sessions around questions the other evidence could not answer. Participants with relevant levels of digital confidence and access needs attempted a task and explained what they expected.
What the combined evidence changed
One page had a poor score and many negative comments. The team assumed it needed a rewrite. Joined-up evidence showed that people arrived after failing an account step elsewhere and were using the page as an unofficial help route.
The team clarified the account error, added a recovery route and made help visible at the failure point. It also improved the content page, without expecting content to compensate for a broken interaction.
Elsewhere, feedback suggested confusing eligibility guidance. Analytics showed loops between two pages and support contacts exposed a repeated question about an exception. In research, participants understood each sentence but could not apply the rules. The fix was a clearer decision sequence with examples.
This is the value of joining evidence. It prevents the loudest comment, the biggest chart or the most senior opinion from becoming the whole story.
Building a responsible feedback loop
Collecting information creates an obligation to use it well. We defined an operating rhythm rather than leaving another dashboard.
Each week, a named service group reviewed new signals for priority tasks. It looked for agreement across sources, sudden changes and serious reports that needed immediate handling. Personal data and safeguarding concerns followed separate restricted routes.
Each month, content, product, analytics and support staff chose a few issues to investigate. Every issue had an owner, evidence summary, proposed action and review date. Teams could record a reasoned decision not to act. The system supported judgement instead of generating unowned complaints.
Changes were checked against the task measures that identified the problem. Publishing a page was not success. The team looked for fewer failures, avoidable contacts, or clearer findings in follow-up research.
People who consented to follow-up were contacted only for the research described. Their details were not added to marketing lists.
The result was a feedback loop with an end point: listen, investigate, decide, change and check.
Illustrative results: sample reporting only
- Sample result: actionable feedback records increased from 18% to 61% after task and failure-point questions were introduced.
- Sample result: avoidable support contacts for the account-recovery issue fell by 24% over eight weeks after the service change.
- Sample result: completion of the targeted eligibility journey rose from 57% to 71% among consenting analytics users.
- Sample result: repeated loops between the two guidance pages fell by 32% in the month after the revised decision sequence launched.
- Sample result: the team reduced its average time from identifying a recurring issue to assigning an owner from 19 working days to 6.
None of these sample figures proves that the feedback redesign caused the change. A publishable account would explain other releases, seasonal effects, analytics consent coverage, sample sizes and how each measure was calculated.
What this kind of work is for
A feedback button cannot replace usability research, support expertise or service analytics. It can help teams notice where to look, provided the questions relate to real tasks and the organisation has agreed what happens next.
The useful output is not a prettier dashboard or a higher helpfulness percentage. It is a service team that can hear a problem, understand it well enough to act, and check whether the action helped.
That was the standard we brought to the feedback review: fewer decorative metrics, clearer decisions and proper care for the people who took the time to tell the service what happened.
Have a similar usability question?
Tell us which journey matters, what evidence you already have and what decision the research needs to support. We will recommend a proportionate audit or research approach.