Rename, revise posts, ready for review

Author: Demotive

app/personalised-prevention-platform/2025/09/gauging-intent/blocking-example.png

@@ -7,7 +7,11 @@ tags:
 - prototyping
 ---
 
-A central piece of our proposition (and that of prevention strategy in general) is the idea of a cycle.
+A central piece of our proposition (and that of PPS strategy in general) is the idea of a cycle. Our team is exploring how me might work as a “connecting capability”:
+
+* introducing users to relevant next steps based on what we can know about them (finding support)
+* encouraging them to make a start (take action)
+* then checking in to see how things are going (maintain a healthier lifestyle)
 
 {% from "nhsuk/components/images/macro.njk" import image as nhsukImage %}
 {{ nhsukImage({
@@ -17,100 +21,68 @@ A central piece of our proposition (and that of prevention strategy in general)
   caption: "The segments of the cycle we’ve been exploring"
 }) }}
 
-So far we’ve explored a user’s very first contact with our service – [introducing and onboarding,](/personalised-prevention-platform/2025/04/onboarding-users/) followed by [presenting opportunities.](/personalised-prevention-platform/2025/09/presenting-opportunities/) At this point we have one goal. We want to understand just enough about someone to suggest relevant opportunities that meet their needs.
-
-Next we need to be able to support people in maintaining their activities.
+We’ve explored a user’s very first contact with our service – [introducing and onboarding,](/personalised-prevention-platform/2025/04/onboarding-users/) followed by [presenting options.](/personalised-prevention-platform/2025/09/presenting-options/)
 
-A big challenge for us is to figure out which (if any) opportunities a user intends to take up, now that we’ve presented them. We need to be able to do this in order to:
+This post examines how we figure out which (if any) opportunities a user intends to take up, now that we’ve presented them. How can we know if someone has:
 
-* check in with someone in a structured and personalised way – we approach the user with a “subject”
-* match feedback to options in order to improve our recommendations to all users
-* provide feedback to services themselves
-* get a better picture of outcomes
+* downloaded and started to use an app, for example Active 10?
+* attended a community event, for example a Parkrun?
+* used a public facility, for example an outdoor gym?
 
-How can we know if a user has:
+We need to be able to do this in order to:
 
-* downloaded and started to use an app?
-* attended a community event?
-* used a public facility?
+* check in with someone in a personalised way – we can approach the user with a “subject”
+* understand what is working for someone and what isn’t
+* examine feedback to improve our recommendations for all users
+* understand which options are popular
+* potentially provide feedback to services
+* get a better picture of outcomes
 
-In the abstract this seems farily straightforward. We show the user options, they pick one, then we check in later to see how it’s going. Easy right?
+In the abstract this might seem straightforward. We show the user options, they pick, then we check in later to see how it’s going. Easy right?
 
 Not so fast!
 
-Let’s take Parkrun as an example opportunity. A potential user journey could be:
+Let’s take Parkrun as an example. A user could:
 
-1. noticing Parkrun in the listing
-2. reading more in the details and getting interested
-3. clicking through to the Parkrun site to find out more
-4. getting engaged and registering with Parkrun
-5. attending their first event
+1. notice Parkrun in our listings
+2. read more in our details and become interested
+3. click through to the Parkrun site to find out more
+4. get engaged and register
+5. attend their first event
 
-From point 3, we have no idea of what the user does next. The click through does not represent “starting” or “choosing”, we can only infer it represents a desire to find out a bit more about something before making a decision.
+At point 3, we have no idea of what happens next. The click through does not actually represent “starting” or “choosing”. At this moment we can only infer it represents a desire to find out more about something before making a decision.
 
----
-
-Guess what? It’s not news to state (see previous post about presenting opportunities) that “things are not joined up”. There is no consistent underlying capability that allows us to rely on “knowing via tech” what a user has decided (or not) to do next.
-
----
+Things are not joined up, particularly where options we might present could be varied. There is no consistent underlying capability that allows us to completely rely on “knowing via tech” what a user has decided (or not) to do.
 
 ## Can we gauge intent?
 
-## How we tested
-
-### Details of a particular option
-
-For pages showing details, we moved from:
-
-* a blocking approach requiring a declaration of intent
-
-to:
-
-* a non-blocking approach to getting clues to intent
-
-{% from "nhsuk/components/images/macro.njk" import image as nhsukImage %}
-{{ nhsukImage({
-  classes: "app-media--full-width",
-  src: "service-detail-iterations@2x.png",
-  alt: "Screen grabs displaying 2 iterations of a details page from left to right.",
-  caption: "2 iterations of our details page"
-}) }}
+As we’ve been prototyping, we’ve been considering ways we could get an indication from the user what they intend to do.
 
-## What we learnt
+### Interface experiment: asking for a commitment
 
-### Intent is the next big challenge
+We created an interface where a user would pick an option: “I want to do this”.
 
+![Example Couch to 5k screen](blocking-example.png)
 
+Logically, for this approach to work, we needed remove all other ways to continue. For example links and contact details were not displayed.
 
-Remember, it would be unwise to attempt to replicate, host and maintain information about any possible option in its entirety.
+In our research sessions, we noted a lot of inconsistency in understanding this interaction. When prompted to explain, answers varied from things like “it would launch the app, right?” to “it would display more details so I could register”.
 
-There’s three potential ways to approach this:
+![Screen grab showing an I want to do this primary button](blocking-ui.png 'Our experiment required a declaration')
 
-1. Gain a commitment from the user that they are going to take up an option that we’ve presented.
-2. Receive information back from services themselves.
-3. Work to assemble clues and indications as to intent during the user journey.
-
----
-
-We felt we needed to work to disprove the first approach in order to counter repeated querying moving forward.
-
-![Two screenshots, one showing an 'I want to do this' button, and the other showing app links and a 'what do you think?' question](intent-iteration@2x.png 'From blocking to gathering clues')
-
-We started with an initial “blocking” design, insisting on a commitment: “I want to do this”.
-
-In sessions, there was inconsistency in users’ understanding of the interaction. When prompted to explain, answers varied from things like “it would launch the app, right?” to “it would display more details” (correct).
-
-Here’s why such an approach like this isn't realistic and won’t work for users (or us):
+Aside from causing confusion, an approach like this isn’t realistic because:
 
 * We’re asking for an **immediate** commitment from the user.
 * That commitment is required before the user has access to all the information they may need.
 * Demanding commitment this quickly creates unreliability at a key point, risking false positives.
 * To create an interface that requires a declaration means you must remove all other ways to continue, creating friction in exactly the wrong place.
 * There is literally no user need here, we’re making the user do the work to join things up for us.
 
----
+The drawbacks of this approach are self-evident, but we felt we needed to demonstrate very clearly the fundamental difficulty (and problematic nature) of relying on the user and interface to do the work of joining up for us.
+
+### Process: background reporting
 
-The second potential approach is the ideal: we receive information back from services themselves about usage.
+A second potential approach does the work behind the scenes: we receive information back from services themselves about usage.
 
 A reporting approach benefits from being reliable and removes unnecessary work from the user to join things up. It’s definitely something to explore, particularly with options that offer online referral or registration.
 
@@ -122,11 +94,11 @@ However, we also must consider:
 
 All these examples are completely viable – the lack of “being joined up” is not a reason to exclude them.
 
-In short, this approach is strong and we’d likely consider it the best, but we need to be able to handle a range.
+In short, this approach is strong, but we need to be able to handle variety.
 
----
+### Approach: gathering clues
 
-Finally we can work to assemble clues and indications as to someone’s during this onboarding journey.
+We can also work to assemble clues and indications as to someone’s intent.
 
 Perhaps we can gain clues in the background by using analytics to:
 
@@ -141,21 +113,20 @@ We can also experiment more with providing opportunities for the user to communi
 * asking the user what they think of an option in-page
 * include tools to send or share option details
 
-Using multiple techniques puts us in the realm of probabilities and likelihoods. This is more realistic and reflective of what we know about people’s lived experiences. It also prevents us from building a dependency on false points of truth.
-
-
----
+![Screen grab showing multiple links including a 'what do you think' question](clues-ui.png 'We can encourage but not rely on user interaction')
 
-## What we’re doing next
+Using multiple techniques puts us in the realm of probabilities and likelihoods. This is more realistic and reflective of what we know about people’s lived experiences. It also prevents us from building a dependency on false points of truth.
 
-Our next piece of work is around the first conversation we’ll have with a user after they’ve been presented options – the very first check in.
+## Intent is the third big challenge
 
-At the point of our first check in, someone has onboarded, potentially setting up some goals, barriers, and preferences along the way. Hopefully they’ve been presented with one or more options that are interesting and engaging.
+So far we’ve assembled three big challenges:
 
-Our next task is to engage the user and introduce a bit more of our interface for what we hope is an ongoing conversation. Importantly we need to jump the gap between presenting options and figuring out if something’s being started.
+1. curating a good selection of local and national options
+2. understanding how to recommend those options based on user input (and what we might already know)
+3. gleaning what a user decides to do based on those options
 
-Wouldn't it be good if, as we introduce users to the interface surfaces and tools that make up this dialogue, they didn't have to do a ton of planning and entering of information in order to even get set up? You know the vibe right?
+## What we’re doing next
 
-The vibe we want is akin to tripping on a paving stone then catching yourself - oh look, it's all here and it makes sense! We’re going for people who aren’t necessarily highly motivated, so we need to always be extremely mindful of _friction._ How can we work really hard so our users don’t have to?
+We’re thinking about the first conversation we’ll have with a user after they’ve been presented options. At the point of our first check in, someone has potentially set up some goals, barriers, and preferences. Hopefully they’ve been presented with one or more relevant options that are interesting and engaging.
 
-And so when we're initiating our conversation, the first sally in our dialogue, wouldn't it be nice if we had an idea of what we wanted to talk about? What if we were able to talk about the things we'd made the user aware of? What if we could have an idea of what was interesting to them, what they might be considering doing?
+The first check in the primary point where having knowledge of a user’s intent becomes crucial. Otherwise what will we talk about?

app/personalised-prevention-platform/2025/09/gauging-intent/blocking-ui.png

@@ -185,7 +185,7 @@ There is a strong relationship between the volume and variety of information we
 
 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.
 
-Having a localised layer also allows us to practise ”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.
+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.
 
 ### “Being engaging” can be quite simple