Our assumptions regarding willingness of users to take the blood test at home
7 August - 20 August
Four beta sprints are scheduled to implement a beta version of the service. This will entail two streams: a continuation of the user led design process carried out in the alpha phase and a SCRUM process to deliver digital elements robust enough to support the delivery of a live beta service to approximately 4,000 users.
Alpha service
We were able to put six more people (friendlies) through the alpha service allowing us to explore in more detail the process of collecting results from the lab and notifying the users. We knew that our partner clinics would handle positive results but also decided to restrict access to any result data to those with "Clinician" privileges.
Mapping admin permissions
One of our alpha testers provided an insufficient blood sample for the labs to test, allowing us to check our process for handling this eventuality but also confirming our feeling that collecting the blood was not an easy task.
User research
Outside of the alpha testing we also videoed a few people taking the blood test at home and interviewed them about the experience. Our previous research had suggested that online instructions would be a good idea but watching people try to follow them whilst actually taking the sample proved otherwise. That said, we did gain a much clearer understanding of what people need to know and at what point in the process by iterating much faster with online instructions than we could have done with printed versions.
We revisited our service map or funnel to reassess the riskiest pain points for users moving through the service.
Our alpha "funnel" with pain points identified and highest risks identified with red dots.
From this we clearly identified the willingness and ability of users to gather an adequate blood sample at home as the biggest risk to us getting people successfully through the service. We tried to quantify this in the diagram below.
Click here to see the assumptions above projected onto visitor numbers to the Camberwell Clinic.
Out in the local community we interviewed people to understand this further and concluded that we should focus on clear printed instructions and provide a video to watch before ordering. The video should serve two purposes; to allow those unlikely to manage the test to understand what was involved before ordering a kit (thus preventing wasted time and kits) and to give others the reassurance that it was possible.
Beta service
The theme for this first beta service sprint was Environments and basic admin, getting everything set up for test driven development and rebuilding the basic admin features prototyped during alpha such as orders and clinic management.
We fleshed out the stories in the backlog and began to put together detailed acceptance criteria in advance of our tester joining in beta sprint 2.
To manage and maintain the system when Unboxed finishes the beta build, we began the search for a full-time SH24 Ruby developer in the hope that they can join the team in the final sprint.
Beta sprint 1 demo, retrospective and planning ceremonies.
Information governance and safeguarding
TextMagic was agreed as our SMS provider for beta due to their European location as recommended by the Trust IG leads.
We started looking in more detail at some of the issue raised by the safeguarding advisors, specifically how to handle concerns about young people using the service.
We secured an NHS.net email account for secure communications between SH24 and our NHS partners at the clinics and the trusts and our SSL certificate details were finalised allowing all data to be encrypted on the website.
Alpha form with SSL information displayed
Our alpha code had been deployed on Heroku but the beta version will need to be hosted on our N3 enabled server before we can put members of the public through the service during this beta phase.
Branding
MultiAdaptor delivered two possible routes for implementation and testing during the beta phase. Our chosen route can be seen here.