Skip to content

Commit cc413cd

Browse files
authored
Merge pull request #247 from NHSDigital/presenting-options-to-users
Presenting options to users (PPP) SHIP IT
2 parents cc49254 + 02a14eb commit cc413cd

File tree

7 files changed

+203
-0
lines changed

7 files changed

+203
-0
lines changed
113 KB
Loading
Lines changed: 203 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,203 @@
1+
---
2+
title: "Presenting opportunities to take action"
3+
description: "Presented with useful and relevant options, do people feel encouraged to take up activities?"
4+
date: 2025-10-01
5+
author: Mat Johnson and Roz Strachan
6+
tags:
7+
- prototyping
8+
---
9+
10+
11+
Hello! We’ve undergone a mild rebrand. We’re now known as the Weight Management team, still under Personalised Prevention Services.
12+
13+
Before this we were the [Personalised Prevention Platform (PPP).](/personalised-prevention-platform/) At least for now we’ll continue to post under PPP to reflect the ambition for the project.
14+
15+
Our underlying thinking remains the same:
16+
17+
1. We can reach the right people.
18+
2. We can encourage people to act to improve their health.
19+
3. We can help people to discover services that meet their needs.
20+
4. We can understand enough about the user to suggest what might be effective.
21+
5. We have permission for a life-long dialogue.
22+
23+
But we’ll be focusing on just one part of the prevention journey to start with: weight management.
24+
25+
Our [previous post](/personalised-prevention-platform/2025/04/onboarding-users/) talked about how we've been exploring how we introduce our service to users, and find out a bit about them, through an “onboarding” process.
26+
27+
In this post let’s look at the next stage: presenting useful and relevant options.
28+
29+
## Why present options?
30+
31+
Everyone we have spoken to told us they believed they could be doing more to maintain their health. However they remained largely unaware of the range of help **already available** to them.
32+
33+
We’re seeing this in findings across personalised prevention services (PPS).
34+
35+
We’re confident that any given individual can be presented with a range of options that could be well suited to them. For example:
36+
37+
* apps people use by themselves, for example Active 10
38+
* in-person group programmes, for example an exercise class
39+
* regular community events, for example Parkrun
40+
41+
We wanted to test how we might present next steps in a clear and actionable manner.
42+
43+
Our prototypes were rooted in four underlying themes:
44+
45+
### 1. What’s the value of presenting a range of options?
46+
47+
There are limits to personalisation, especially in prevention. We can’t create the perfect path for each person – and we shouldn’t try to. The best approach is helping people choose what works for them from relevant opportunities.
48+
49+
Can we provide:
50+
51+
* enough choice that each person finds at least one thing they want to try?
52+
* a small enough selection that people don't feel overwhelmed?
53+
54+
### 2. What’s the minimum viable information about an activity we can use?
55+
56+
It’s not news to state that service directories represent “hard yards”. The underlying work of assembling and maintaining information about services (of all shapes and sizes) has been repeatedly “discovered”. However it’s also not news to state that we need this information to underpin all sorts of transformational capabilities.
57+
58+
We need to work out where and how we’ll get information about the services we want to show users in a pilot area.
59+
60+
We’ve made some interesting experimental inroads with some help from the AI Health Coach team (thank you!), asking can algos and agents:
61+
62+
* rapidly assemble a “starter for 10” of relevant local services based on set criteria?
63+
* represent a more sophisticated “automated link checker” maintenance approach to changes in information?
64+
65+
Looking forwards, we need to bear in mind that other services might find the type of information we’re collating valuable too. How do we design our data for re-use as agnostically as possible?
66+
67+
On top of this, it’s critical to acknowledge that the mechanics of some next steps could be complex, even if their central proposition is not. For example any given option could have multiple:
68+
69+
* eligibility criteria
70+
* channels of delivery
71+
* ways to join – such as a choice of memberships
72+
* ways to use – such as access to different features based on membership
73+
74+
It follows that rather than attempt to recreate and maintain lots of complex content, we need to be able to do “just enough”. We must start lean in terms of how much information we display, and aim to meet essential needs first.
75+
76+
What is just enough for someone to:
77+
78+
* understand the proposition?
79+
* know how to start?
80+
* be engaged?
81+
82+
### 3. How well does filtering work?
83+
84+
If we acknowledge personalisation can only go so far, logically we need to create mechanisms to allow users explore beyond the initial set of options we present.
85+
86+
Do people understand the connection between the:
87+
88+
* questions we’ve asked?
89+
* results themselves?
90+
* available filters in the results listing?
91+
92+
How easy is it for the user to explore all available options?
93+
94+
## How we tested presenting options
95+
96+
### Expanding the prototype user journey
97+
98+
We extended our user journey into how presenting options might work. We continued to iterate our onboarding segment, swapping out chunks to try variants or different approaches.
99+
100+
{% from "nhsuk/components/images/macro.njk" import image as nhsukImage %}
101+
{{ nhsukImage({
102+
classes: "app-media--full-width",
103+
104+
alt: "Screen grabs displaying 3 iterations of our user journey. Each journey is shown from left to right. Each iteration appears below the previous.",
105+
caption: "3 iterations of our user journey"
106+
}) }}
107+
108+
[Open a large version of this image (4.5mb)](user-journey-iterations-xlarge.jpg)
109+
110+
### Listing options
111+
112+
For listings, we gradually moved from hard coded selections matched to participants’ local areas, to an API returning only national services derived from the [Better Health](https://www.nhs.uk/better-health/) website.
113+
114+
This enabled us to:
115+
116+
* continue to test our “local is high value” hypotheses
117+
* test a real dataset with real filters
118+
119+
{% from "nhsuk/components/images/macro.njk" import image as nhsukImage %}
120+
{{ nhsukImage({
121+
classes: "app-media--full-width",
122+
123+
alt: "Screen grabs displaying 3 iterations of a results listing from left to right.",
124+
caption: "3 iterations of our results listing"
125+
}) }}
126+
127+
### Details of a particular option
128+
129+
For pages showing details, we moved from:
130+
131+
* minimal and highly atomic content
132+
* zero imagery
133+
134+
to:
135+
136+
* looser content retaining a strong structure
137+
* minimal imagery
138+
139+
{% from "nhsuk/components/images/macro.njk" import image as nhsukImage %}
140+
{{ nhsukImage({
141+
classes: "app-media--full-width",
142+
143+
alt: "Screen grabs displaying 2 iterations of a details page from left to right.",
144+
caption: "2 iterations of our details page"
145+
}) }}
146+
147+
## What we learnt
148+
149+
### Blend national and local
150+
151+
Since [discovery](/personalised-prevention-platform/2025/03/discovery-summary/) we’ve continuously proved that presenting a blend of national and local has real value for people. Throughout our sessions people asked if the options were real (they all were), and then make notes to look them up afterwards.
152+
153+
“National” and “local” are false distinctions, very visible to us, as we operate within organisational structures.
154+
155+
But where a thing “comes from” is irrelevant. You can be interested in Active 10, interested in your local Parkrun, and interested in the public gym in your local park.
156+
157+
### Strike a balance between needs and wants
158+
159+
Earlier onboarding prototypes included goal and priority setting segments, along with asking about barriers – things that could get in the way.
160+
161+
We tested removing these segments, instead asking a series of questions directly mapped to filters in the results listing, for example:
162+
163+
![A question page asking 'how do you like to be taught or coached?' alongside a column of filters displaying the same]([email protected] 'Onboarding questions mapped to filters')
164+
165+
This reductive approach led to some good evidence.
166+
167+
Matching onboarding questions to listing view filters didn’t seem to cause any overt issues, and generally people understood how to change the initial set of options presented.
168+
169+
However, reliance on preference alone means any recommendation aspect is negated. We’re in pure service finder territory, and we’ve left no room for the unexpected or left-field that might spark engagement.
170+
171+
Some people told us they were basing their preferences on past experience – but that past experience was rooted in activities that had lapsed. So arguably we have a risk of presenting similar or identical options to those that may have failed the user in the past.
172+
173+
We’ve proven that we need to become more opinionated in the options we present. These options must be mapped to a user’s declared goals, priorities, barriers, and preferences, but also weighted by “systemic” opinion.
174+
175+
### Continuously assess the relationship between volume, variety, and granularity
176+
177+
Generally people understood the connection between our onboarding questions, the initial set of options, and the associated filters.
178+
179+
With 18 services in our prototype API, one or two users combined preferences or filters that led to zero results. This led to immediate disengagement and in real life, dropoff.
180+
181+
There is a strong relationship between the volume and variety of information we hold, and the ability to filter (or “personalise”) a set of results. If you only have a few options to offer, you can only offer so much granular control in your interface. This balance needs to be continuously assessed, particularly at lower volumes.
182+
183+
Our 18 services represent a generic baseline that we know to be suitable for all geographic areas and a wide range of people. In our pilot we expect to layer local offerings on top of this baseline, and so our volume and variety increases. With an idea of that increase, we get a better idea of how much granularity we can introduce.
184+
185+
Having a localised layer also allows us to make sure there are no “dead ends”. If our base selection is generic, then a minimum set of options would include all relevant generic options. For example a user’s priority to “exercise or move more” would at the absolute minimum return the Active 10 and Couch to 5k apps.
186+
187+
### “Being engaging” can be quite simple
188+
189+
Unsurprisingly the early presentation of options was not very engaging, with users often mentioning how unexciting they were.
190+
191+
![A service result listing before and after the addition of a logo]([email protected] 'Small visual tweaks had marked effect')
192+
193+
What was surprising was how effective deliberately small tweaks were. The addition of a only small amount of imagery – in some cases only a logo – along with a looser content structure alleviated any further comment.
194+
195+
---
196+
197+
## What’s next?
198+
199+
In prototype land, we continue along our user journey – checking in with people to see if any of our options are of interest to them, and introducing the basic elements to help with our “life-long dialogue”.
200+
201+
In pilot land, we’re starting to assemble the user journey for onboarding and presenting opportunities, distilled and iterated from various prototypes.
202+
203+
61.1 KB
Loading
384 KB
Loading
261 KB
Loading
4.28 MB
Loading
192 KB
Loading

0 commit comments

Comments
 (0)