Community workshop to scope a feedback component

[kellylee-gds]

This workshop brought together service teams to explore what an improved GOV.UK feedback component should look like. Across the exercises, several consistent themes emerged about what both end users and service teams need from feedback mechanisms, why those needs matter, and what an MVP should include.

What users need

Qualitative and quantitative insight

Service teams emphasised the need to gather both types of data to understand service performance. During the workshop one of the participants quoted: “I need to obtain both quantitative and qualitative feedback so that we have a good view to assess the effectiveness of our service.”

Service teams also told us their end users want simple ways to respond, such as ratings, so they “don’t have to write a wordy response.”

Right timing to give feedback

Service teams highlighted that their end users don’t want to be interrupted during a service journey.

Several noted, “I need to not be asked to provide feedback during my service journey, so I don’t become distracted.”

This is inline with what we found in our desk research on where some teams tried out having feedback at the end of a service and seeing 300+% increase in response rates. Another one quoting of receiving much more valuable feedback on their service.

Purpose, value and trust

Service teams told us that their users want to understand why feedback is being collected, what will happen to it, and whether it will be acted on. While having the confidence that their data is protected.

Comments from end users included:

• “I need to know that someone has received my feedback so that I don’t feel like I have wasted my time.”
• “I need to understand what a service will do with my feedback.”
• “I need to understand why a service wants my feedback, So I can decide whether to give it.”
• “I need to understand that I won't (or possibly will) get a response to my feedback. So that I understand the limits to the process”

Comments from service teams included:

• “I need to make sure personal identifying information can not be entered, So that my service is secure”
• “I need to know the user's (anonymous) tracking ID, So that I can understand their journey or behaviours in that session”

Clear and accessible

Service teams told us that their end users need to easily spot where to leave feedback and choose a method that works for them. This includes accessible options and the ability to leave more detailed follow‑up if needed.

We also found similar evidence in our desk research with service teams quoting “users having banner blindness”.

More quotes from the workshop on end user needs:

• “I need to have different feedback options,So that I can provide feedback in a way that is accessible to me”
• “I need to spot the feedback link, So that I know I can give feedback”
• “I need to give a rating, So that I don't have to write a wordy response”

Service team needs:

• “I need to explore adopting the Design System feedback component, So that user expectations of how to provide feedback is consistent across GOV.UK”
• “I need the user to understand the right avenue to leave feedback in, So that we don't miss anything”
• “I need to gather feedback without causing friction, So that the end user can complete their journey”

Analytics and operational needs

Service teams need feedback to be actionable:

• Knowing which page feedback came from
• Ensuring actions are countable in analytics
• Understanding barriers to response
• Linking feedback to anonymous session data

Capacity and adoption

Service teams want to understand whether they have the capacity to analyse feedback and whether adopting a standard component will help them avoid bespoke solutions.

Must‑haves for MVP

From the affinity sorting and voting on user needs, the following features emerged as essential:

• Ability to collect qualitative feedback
• Clear, visible entry point for leaving feedback
• Accessible options for different users, including assistive technology
• Feedback that does not interrupt the service journey
• Basic analytics: countable actions, page location, anonymous tracking
• Clear explanation of what feedback is (vs. support)
• Quick access to feedback data for service teams

Next steps

The Design System team will review the outcomes of the workshop, and prototype some designs which meet the needs expressed.

We will then look to test an mvp iteration in a small number of services, working closely with the service team to gather insights and feedback on how it is performing. If you'd be interested in taking part in the beta test, please reply to this thread.

[benaldo1975]

Hi Kelly

I'm sorry that nobody from the Service Manual and Service Standard was able to attend, in the end...

In case it's not too late, the feedback we get from that component might be more useful to us if:

• There were contact details (although this could backfire if they then expect liaison!)
• Can we get email or zendesk ticket when a comment is left within /service-manual, rather than having to search Feedex?
• Any more info about what they were using the Service Manual for would be useful. "I came to try and understand X but Y wasn't working or doesn't make sense..."

many thanks!

Ben

[kellylee-gds]

Thanks Ben!