Nearly there

Author: Demotive

app/posts/personalised-prevention-platform/2025/09/2025-09-01-name.md

@@ -183,81 +183,121 @@ We removed these segments, instead asking a series of questions directly mapped
 
 This reductive approach led to some good evidence.
 
-Reliance on asking preference alone means any “recommendation” or even “from left field” 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.
+Reliance on asking 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.
 
-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’re running a risk of simply presenting similar options to those that may have failed the user in the past.
+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 options to those that may have failed the user in the past.
 
-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 our (systemic) opinion.
+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.
 
-### Handle the relationship between volume, variety, and granularity
+### Continuously assess the relationship between volume, variety, and granularity
 
-With 18 services in the “live” API, one or two users combined preferences that led to zero results. This led to immediate disengagement and in real life, dropoff.
+With 18 services in our prototype API, one or two users combined preferences that led to zero results. This led to immediate disengagement and in real life, dropoff.
 
 There is a strong relationship between the volume and variety of information we hold, and the ability to tune (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.
 
-Our 18 services represent a generic baseline that we know to be suitable for all 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.
+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 practice ”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.
 
-### “Engagement” can be simple
+### “Being engaging” can be quite simple
 
-Unsurprisingly the early presentation of options was not engaging, with users often mentioning how unexciting they were.
+Unsurprisingly the early presentation of options (above) was not engaging, with users often mentioning how unexciting they were.
 
-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.
+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.
 
 ![A service result listing before and after the addition of a logo](logo-addition@2x.png 'Small visual tweaks had marked effect')
 
 ### Intent is the next big challenge
 
-A big challenge for us is to figure out how and where in the overall journey we can find out what a user is actually doing.
+A big challenge for us is to figure out how and where in our overall prevention journey we can find out what a user is actually doing. We need to be able to do this in order to:
 
-It’s very easy in the abstract to miss interaction gotchas like this. We show the user the options, they pick one, then we check in later to see how it's going. Easy right?
+* 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
 
-Not so fast there. Let’s take Parkrun as an example. A potential user journey could be:
+In the simplest possible scenario, we show the user options, they pick one, then we check in later to see how it’s going. Easy right?
+
+Not so fast there. It’s very easy in the abstract to miss interaction gotchas like this.
+
+Let’s take Parkrun as an example. A potential user journey could be:
 
 1. notice Parkrun in the listing
 2. read more in the details and get interested
-3. go to the Parkrun site to find out more (leaving our site, right?)
+3. click through to the Parkrun site to find out more
 4. getting engaged and registering with Parkrun
 5. attending their first event
 
-At point 3 onwards, we will have no idea what they’re doing.
+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.
+
+Remember, it would be unwise to attempt to replicate, host and maintain information about any possible option in its entirety.
+
+There’s three potential ways to approach this:
+
+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.
 
-There’s two basic ways to approach this:
+---
 
-1. Gain a “declaration of intent” from the user.
-2. Assemble as many clues and indications as we can 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')
 
-Our initial “blocking” design was essentially built with the expectation of failure. We insisted on a declaration: “I want to do this”
+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):
 
-Wanted to test it (hey if it works then great, that would be neat) but also wanted to draw out solid reason why we should not do it. Tactics right.
+* 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 affordance to onward journeys, 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.
+
+---
 
-In order to get a declaration of intent to use an option, we’re asking for an _immediate_ commitment from the user. It’s unrealistic to demand people must commit to a change this quickly, creating a fragility at a key point for us.
+The second potential approach is the ideal: we receive information back from services themselves about usage.
 
-To create an interface that _demands_ a declaration means you have to withhold useful information (find out more about, directions, any contact details). If you have a single high importance CTA that you are massively relying on, you cannot provide routes around it, you are aiming to strongly funnel users.
+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.
 
-Risk of failure risk to the actual proposition
+However, we also must consider:
 
-All this aside, users were confused. Lots of people didn't see or understand what the CTA was for. When prompted to explain what it was answers varied from things like "it would launch the app right?" to "it would display more details" (correct).
+* informal or small scale community based options, for example a litter picking club
+* services that don’t _want_ to report on an individual level, for example any service offering anonymity of any kind
+* facilities which have zero registration or reporting, for example a public gym in a park
 
-Even if you somehow nail this (unlikely - remember the service information problem), the risk of false positives remains.
+All these examples are completely viable – the lack of “being joined up” is not a reason to exclude them.
 
-Clues and indicators both via tracking and via opportunity. None of which is a point of failure.
+In short, this approach is strong and we’d likely consider it the best, but we need to be able to handle a range.
 
 ---
 
-Without having a decent idea of even the nature of the option chosen - is it an app, in perosn, how long, what's the interval - our aboility tj follow up is hamperd or personalised that follow uto
+Finally we can work to assemble clues and indications as to someone’s during this onboarding journey.
+
+Perhaps we can gain clues in the background by using analytics to:
+
+* track and save result sets as the user explores options
+* track visits into detail pages
+* measure dwell time, scroll depth and so on in such pages
+* track outbound clicks
+
+We can also experiment more with providing opportunities for the user to communicate interest:
+
+* favouriting or liking
+* 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.
+
+
+---
 
-Think “patient reported outcomes” for example.
 
-We’ve got ideas about how to glean intent from various clues in this part of the journey, and as we produce our check-ins we’ll be stress testing them.
 
 (Epilogue) What we’re doing next
 
 - Latest work is around "the very first check in"
-- Jumping the gap between presenting the options and figuring out if something's being done
-
-- writing up something about intent in the recommnedations bit
-- writing up somethibg about service display
+- Jumping the gap between presenting the options and figuring out if something's being done - continue to explore the how
+as we produce our check-ins we’ll be stress testing them.