Ask users for feedback

[sarawilcox]

Guidance on feedback mechanisms (components and patterns) and feedback survey questions (content).

See EPIC: Ask users for feedback: feedback mechanisms and questions

The Common Components team in NHS.UK is carrying out a discovery that will inform this guidance.

[sarawilcox]

Update September 2023 - the work of the NHS.UK Common Components team

[sarawilcox]

The Add or Correct Your Contact Details service recently carried out usability testing of an end-of-transaction feedback survey form.

More details in the GitHub issues for EPIC: Survey mechanisms and questions.

[teodorapreda2]

The NHS App team have conducted a Discovery into the in-app feedback mechanism from July - November 2023. We are currently in the technical solution implementation phase.

In our discovery, we have identified five main user personas:

• NHS App user (that leaves the feedback)
• NHS App user researcher (that analyses the feedback)
• NHS App product manager (that prioritises backlog based on feedback)
• Clinical safety team (that reviews and responds to clinically unsafe responses)
• Customer resolution (service management T1/T2/T3) team (that reviews and responds to technical issues)

When redesigning the screens for the surveys, we looked into:

• improved accessibility
• clear signposting
• content to remind users of what the survey is about
• existing or new design patterns from other NHS or external teams
• technical constraints

Some of the main insights we gathered through our research were:

• users are more inclined to look for feedback at the bottom of a page or on the Homepage; some users also went to the Account and Settings area of the App (following a mental model from other services and apps)
• users are expecting the feedback survey to be opened on top of the page they were on (following a mental model from other services and apps)
• some users are confused by the similarities in the in-app feedback survey and the technical error contact form. They are often using the incorrect forum to leave technical errors, that are not monitored or responded to by the suppor team.
• users liked the combination of a visual rating (stars) with a in-line text value as it made it clear what the rating means
• most users will not bother with also leaving App store rating if their experience with the App is positive; prompting them at the end of the journey did not seem to make any difference
• when we tested a maximum or a minimum character limit for the free text field, most users were not pleased and felt discouraged to continue leaving feedback as they felt limited
• majority of participants understood they would not get a response and did not expect one after completing the feedback survey. Some mentioned the desire to have the ability to leave their contact information.
• participant were ok with their login data being captured as part of the feedback submission and it did not deter them from completing the journey
• users were able to navigate through the radio buttons to decipher where the correct place to leave their feedback was
• users had no issue understanding the difference between the ease of use question and the overall experience question
• most users expressed their wish to get to the free text field as quickly as possible. Although we won't have any front-end validation rules to stop users from submitting personal, medical or clinically unsafe content, we have rules in place in the back-end to redirect those types of tickets to the relevant teams

Proposed design solution highlights:

Notes:

1. Entry point: this component needs to fit across stationery and transactional screens and be accessible and inclusive. We designed a hybrid link component with a blue background to differentiate it from all other action links we currently have on the App.
   • Banner link, that opens a fixed overlay (full OS sheet) over the page the user was on. *The NHS App also has a web instance. We have tested this banner link design on website as well. We are currently defining the interaction pattern on web, as it poses different challenges to the native app.
   • Account and settings, permanent home under a Support sub-section. If accessed through here, the survey will open as stand-alone pages and a normal-flowing form.
2. Redirect screen: adding friction in the journey to help users find the correct forum to raise their feedback or technical issues
3. What did you do today Order of choices In the previous UR round users expressed that some services were more important than others so should be higher on the list. We recorded the options based on analytics of which areas were the most frequently used.
4. Ease of use scale
5. Rate your overall experience
6. Add more details about your experience

Web considerations The NHS App currently can be accessed via a native mobile app, and through the web. This means that when we design new interactions or functionality, we need to consider how a user would interact in both a native and a web environment, to match the user expectation, mental models and UX and accessibility best practices.

As seen across other examples from NHS or GOV.UK issues, it is a lot of technical effort to make a modal or overlay accessible on web. Therefore, we have decided that the survey will open in a new page entirely for the web environment.

Qualtrics is the third-party supplier for the feedback survey and response analysis. Our discovery and solution was also looking at the backend processes, updating the topic models for enhanced and contextualised TextIQ and smart workflows (using different topic models to automatically

[michaelgallagher]

just flagging for visibility that the app team has had some serious challenges to work through with our in-app feedback mechanism related to clinical safeguarding and our duty of care.

the issue is that if a user submits content in the free text field that indicates that they may harm themselves or are in danger, there is an open question about what our responsibility is toward them (given that we can identify them, because they are logged in).

there will need to be some work in the near future to determine how we mitigate this, whether that be through more substantial warning content before they leave feedback, some form of content analysis (e.g. keyword tagging) and issue triage, both, or something else.

the reason i'm flagging this is because it does feel like there should be a shared approach to the content design here, as i'm sure this effects more teams.