You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>Alpha is where you try out different solutions to the problems you learnt about during discovery.</p>
15
+
<p>Spend alpha building prototypes and testing different ideas. And do not be afraid to challenge the way things are done at the moment: alpha is a chance to explore new approaches.</p>
16
+
<p>You do not have to prototype the user’s entire wider journey.</p>
17
+
<p>You might not even want to prototype all of the transaction or element you’re working on: often it makes sense just to focus on the areas you think will be most challenging. This lets you do the minimum you need to test your riskiest assumptions.</p>
17
18
</blockquote>
18
19
<figcaption>From the <a href="https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works">GOV.UK Service Manual</a></figcaption>
19
20
</figure>
20
21
21
-
We’ve completed our first round of prototyping and user research, an exploration into ideas around ‘onboarding’.
22
-
23
-
We’re building prototypes to explore further and test our hypotheses.
24
-
25
-
Some parts of these prototypes could make it into a real product, and some elements are designed purely to provoke conversation in research sessions.
22
+
Amongst other things we’re building html prototypes to explore and test our hypotheses, and have just completed our first round, concerned with ‘onboarding’.
26
23
27
24
## What we did
28
25
29
-
We aimed to explore users’:
26
+
Our main areas of interest in this round were:
30
27
31
-
- understanding of what our potential proposition might be
32
-
- assumptions about consent and sharing their information across services
33
-
- needs for information and guidance balanced against service finding, and how to supply it within an ongoing transaction
34
-
- personal priorities versus what we (the system) are telling them
35
-
- barriers — the things that get in the way of making lifestyle changes
36
-
- preferences — the things that make services more appealing
37
-
- expectations of what that might be returned as results after going through the process
28
+
- do users understand what the service is and how it could help them?
29
+
- how do users react to being offered the option of guidance versus going directly to services?
30
+
- how willing are users to share their data to be matched to services, and what assumptions about data do they make?
31
+
- how do users feel about the platform recommending areas to focus on versus their personal priorities?
32
+
- do users retain focus on their health goal during an onboarding journey?
38
33
39
34
To help us explore these topics, we built a mock journey that represented just the initial stages a potential journey:
40
35
@@ -44,164 +39,220 @@ To help us explore these topics, we built a mock journey that represented just t
44
39
45
40
We also made the following assumptions:
46
41
47
-
- our scenario starts as a high height-to-waist ratio
48
-
- users are already registered and logged in
42
+
- our scenario starts from an NHS.UK calculator
43
+
- users are already somehow digitally registered ‘with the NHS’
49
44
50
45
<figureclass="govuk-!-margin-top-7">
51
46
<imgsrc="prototype-flow.png"alt="Diagram depicting the prototype user journey using sequential screen grabs from left to right."style="width: 92vw; max-width: 960px;">
52
47
<figcaption>The prototype journey from left to right, from calculator result to a ‘finding services’ loading screen.</figcaption>
53
48
</figure>
54
49
55
-
Our prototypes are built in code (html, css, and javascript only when needed) in order to give users hi(gh?)-fidelity and ‘real feeling’ stuff [omg rewrite]. Working in code means we can iterate and edit extremely quickly. Each prototype gets a few rounds of crit from the whole team. Er, maybe this is a waste of space.
50
+
We ran 6 sessions with people who live in deprived areas of England (within the top 20 areas on the Index of Multiple Deprivation), and have more than one of the following health risk factors:
56
51
57
-
We ran 6 interview sessions with people from our initial target [audience?population?er?]
52
+
- overweight
53
+
- smoker
54
+
- heavier drinker
55
+
- inactive
58
56
59
57
## Exploring the prototype with users
60
58
61
59
### Entry point into the platform
62
60
63
-
As an example entry point we’ve used results from the <ahref="https://www.nhs.uk/health-assessment-tools/calculate-your-waist-to-height-ratio">calculate your waist to height ratio</a> tool. This represents one potential route (amongst many) into the platform.
61
+
As an example entry point we’ve used results from the <ahref="https://www.nhs.uk/health-assessment-tools/calculate-your-waist-to-height-ratio">calculate your waist to height ratio</a> tool, and added a call to action. This represents one of many potential routes into the platform.
62
+
63
+
64
+
65
+
#### In research:
64
66
65
-
67
+
We know using a health assessment or calculator result does have the potential to inspire action.
66
68
67
-
Any findings?
69
+
However if risk is the trigger to take action, that risk needs to be well understood.
68
70
69
71
---
70
72
71
73
### Start page
72
74
73
-
After using the call to action, the user then hits a fairly traditional start page pattern. It’s a bit personalised in that it offers examples that make sense for a journey coming from the waist to height ratio results.
75
+
The user then hits a fairly traditional start page. It’s mildly personalised in that it offers examples that are related to the waist to height ratio results.
74
76
77
+
75
78
76
-
79
+
#### In research:
77
80
78
-
Any findings?
81
+
The start page was well understood. Our claims of a service fitting in with people’s lives and subsequently checking in were positively received.
79
82
80
-
We then show a login spinner and a 2 second redirect. We do this to reinforce the illusion that the user has, at some unspecified point, already logged in. This allows us to avoid protracted discussion along the lines of ‘how could it know that?’ in the sessions.
83
+
This is a good start in describing the PPP service. Creating smooth links between multiple potential entry points and the service may be more challenging.
81
84
82
-
85
+
<!--
86
+
---
83
87
84
-
Any findings?
88
+
Next we show a login spinner for a couple of seconds. We do this to reinforce the illusion that the user has, at some unspecified point, already logged in. This is to avoid protracted ‘login’ discussion in sessions.
89
+
90
+
91
+
-->
85
92
86
93
---
87
94
88
-
### Do you want know more about the benefits of reducing your waist size and getting to a healthier weight?
95
+
### Do you want know more?
89
96
90
-
The next part of the prototype is aimed at gaining insights and prompting discussion about the _relative_ value of information and guidance.
97
+
This part of the prototype is aimed at gaining insights about the _relative_ value of guidance as opposed to finding services.
91
98
92
99
We do this by asking a simple question: do you want know more about the benefits of reducing your waist size and getting to a healthier weight?
93
100
94
101
We’re offering to ‘send you some guidance’, and giving the user the option of saying yes or no.
95
102
96
-
103
+
97
104
98
-
<!--
99
-
105
+
#### In research:
100
106
101
-
102
-
-->
107
+
Participants split 50/50 on those opting for guidance versus those going straight to services.
108
+
109
+
Those going straight to services were either time poor or sceptical about the quality of any guidance.
110
+
111
+
Those opting for guidance still expected to get help finding services.
103
112
104
-
Any findings?
113
+
We think it’s possible to offer guidance materials as just one part of an onboarding process. We could do more to explain what that guidance might consist of to combat cynicism.
105
114
106
115
---
107
116
108
117
### Can we use these details about you?
109
118
110
-
Using a fairly realistic barrier, we explore users’ assumptions and expectations about consent and data sharing across the system. Our page presents a forced consent to use a basic set of details in the platform.
119
+
Next we explore what users think about consent and data sharing across the system. Our page presents a forced consent to use a basic set of details in the platform.
111
120
112
-
121
+
113
122
114
-
Any findings?
123
+
#### In research:
124
+
125
+
All participants were happy to share the example details (with the caveat that this is in a research setting).
126
+
127
+
Half expected the NHS to already have these details, all were happy to provide any missing information.
115
128
116
129
---
117
130
118
131
### Changes you want to make to stay healthy
119
132
120
-
A simple way to explore personal priorities versus what we (the system) are saying is to allow people to choose. We display recommended changes based on the user’s journey (in this case height-to-waist-ratio related), but offer more.
133
+
One way to explore personal priorities versus what we (the system) are saying is to allow choice. We display recommended changes based on the user’s journey (in this case height-to-waist-ratio related), but offer additional options.
121
134
122
-
Potentially, from this point onwards, a platform could be starting to build up a profile in the background of a person and their goals.
135
+
123
136
124
-
137
+
#### In research:
125
138
126
-
Any findings?
139
+
Almost all participants selected one or more additional option.
140
+
141
+
Most were happy that the service was making initial recommendations, but felt it was good they still had the choice of other things.
127
142
128
143
---
129
144
130
145
### What do you want to do first?
131
146
132
-
How do people feel about selecting one priority to tackle first?
147
+
How do people feel about selecting one single priority to tackle first?
148
+
149
+
From the perspective of onboarding, it’s often best to design for as little friction as possible, reducing complexity. A platform could retain all selected goals in the background, but take the user through the initial journey with a single goal.
133
150
134
-
As part of onboarding, it’s often [better] to design for as little friction as possible, reducing complexity. A platform could retain all selected goals in the background, but take the user through an initial journey with a single goal.
151
+
135
152
136
-
153
+
#### In research:
137
154
138
-
Any findings?
155
+
Often participants prioritised their own additional changes first.
156
+
157
+
Overall these interactions seem to achieve a good balance between the platform making suggestions, while leaving room for personalisation.
139
158
140
159
---
141
160
142
161
### What do you find hard about making healthy changes?
143
162
144
-
Both desk research [hat tip to Southwark?] and our discovery probes noted that asking people what might get in the way brought them much more on board. People often know what they _should_ be doing, and reasonably enough can be put off by being given the same advice repeatedly [our cohort?] something something demotivating.
163
+
During our discovery we noted that asking people what might get in the way brought them much more on board.
164
+
165
+
People often know what they _should_ be doing, and reasonably enough are put off by being given the same advice repeatedly. A platform that takes into account people’s barriers when recommending services could stand more chance of success.
145
166
146
-
A platform that takes into account people’s barriers as far as possible when recommending services would be another way to reduce the friction and pain points currently experienced by users. Less friction means less drain on the motivation to act to change stuff [write betterer]
167
+
In this interaction we wanted to test how people react to having only a fixed number of barriers to choose from, and what they thought about being asked about barriers at all.
147
168
148
-
Something we wanted to test in this example was how people react to only having a fixed amount of barriers to choose from, and why they might be being asked about them at all.
169
+
149
170
150
-
171
+
#### In research:
151
172
152
-
Any findings?
173
+
Participants weren’t sure why they were being asked what they found difficult when trying to make changes. Few thought it would be for their benefit (i.e. to recommend the right services), with some thinking they were being asked purely for statistics. Nobody questioned the items in the list.
153
174
154
-
[did any user mention the list being incomplete]
175
+
We need to work harder to convey _why_ we are asking about barriers.
155
176
156
177
---
157
178
158
179
### Preferences
159
180
160
-
It’s fair to assume that gathering a user’s preferences will allow us to better match them to potentially helpful services.
181
+
161
182
162
-
Conceptually by using ‘facts’ about someone (for example their age, height and weight, and home postcode), we can match a set of services that a person will be _eligible_ for.
183
+
By using ‘facts’ about someone (for example their age, height and weight, and home postcode), we can match a set of services that a person will be _eligible_ for.
163
184
164
-
Gathering preferences then allows us to reorder or reduce the service selection further. [reducing friction]
185
+
Gathering both barriers and preferences could allow us to reorder or reduce that set to make it more _suitable._
165
186
166
-
Our prototype asks a simple series of questions without branching or logic, to understand how adding preferences changes a user’s understanding or expectations of what will be delivered to them [I cant write today]
187
+
Our prototype asks a few questions, to understand how detailing preferences affects a user’s understanding or expectations:
167
188
168
-
189
+
- Where would you like any services we recommend to happen?
190
+
- Would you prefer to do things yourself or be coached by someone?
191
+
- Do you prefer to do things on your own or with other people?
192
+
- Would you prefer to use a service in person (face-to-face) or remotely (using a website or app)?
193
+
- Are you OK to wait if a service does not start straight away?
194
+
195
+
<!--
196
+
169
197
170
-
198
+
171
199
172
-
200
+
173
201
174
-
202
+
203
+
-->
175
204
176
-
205
+
#### In research:
177
206
178
-
Any findings?
207
+
All participants were able to make a clearly reasoned choice for each preference option.
179
208
180
209
---
181
210
182
211
### Find services based on what you’ve told us
183
212
184
-
In a fairly standard pattern we then play back what the user has told us.
213
+
Similar to the start page, we end on a fairly standard pattern playing back what the user has told us.
214
+
215
+
185
216
186
-
217
+
#### In research:
187
218
188
-
1. Playing back all the user’s goals to them could be a negative moment of overwhelm reducing motivation
219
+
There’s potential that playing back _all_ the user’s goals to them as the first thing could reduce motivation, so we need to look at how we play back this information in the right way.
189
220
190
221
---
191
222
192
223
### Finding services
193
224
194
-
We end on a loading spinner. This bookends the prospective onboarding process, and allows us to find out
225
+
We end on a loading spinner. This bookends the prospective onboarding process.
226
+
227
+
228
+
195
229
196
-
what users expect to happen now
197
-
what kind of services they expect to be returned
198
-
whether the original impetus has been retained [this is not clear]
199
230
231
+
- what users expect to happen next
232
+
- whether focus is retained on users’ health goal during the initial onboarding
233
+
Half of the participants retained focus on the health area they wanted support with
234
+
A couple kept the focus on the initial weight support, but forgot about the extra options they had selected
200
235
201
-
236
+
---
237
+
238
+
## Conclusions
239
+
240
+
Some parts of these prototypes could make it into a real service, and some elements have been designed expressly to provoke conversation in research sessions.
241
+
242
+
Overall we can create a comprehensible and usable onboarding journey, and less friction means less drain on a user’s motivation.
202
243
203
-
Any findings?
244
+
We need to work harder to:
245
+
246
+
- ensure smooth jumps from entry points into the service
247
+
- establish the proposition quickly and effectively
248
+
- explain our interest in what people find difficult when attempting healthy changes
249
+
250
+
We need to create a fast and simple set of interactions to provide guidance to users without interrupting the flow.
251
+
252
+
Probably the biggest challenge thrown up by the research sessions is the need to onboard people without them losing focus on what brought them to the service in the first place. The journey needs to work hard to remain concise and maintain a strong relationship to the _subject_ that brought the user to it.
204
253
205
254
---
206
255
256
+
At this point we may well leave onboarding where it is in favour of a different part of the potential service journey. We’ve tested ideas, gotten insights, and made our notes for taking things further or doing things differently.
0 commit comments