Product development insight: steps to take when you REALLY have to put the user first
It’s an unusual brief to be handed… build a product that:
- Has a small target user base
- Shouldn’t be needed in a perfect world
- Shouldn’t have aspirations for a rapid growth in demand
In this case, the brief was to create a suicide prevention app in partnership with Black Dog Institute.
This was certainly a shift from my experience building fairly business as usual type products prior. The process normally looked like this: undertake user research and gather insights, occasionally you would go additional rounds of research, but often you would just get on with the build. Working on this project with The Black Dog Institute, was the first time I truly accepted that it was vital that the user was central throughout the entire product development journey.
The importance of the problem the app sought to solve
A few suicide statistics to highlight the the importance of the problem we were solving**:
- In the last decade the rate of suicides has been increasing — the age-standardised suicide rate in Australia has increased from 10.7 per 100,000 population in 2009 to 12.1 deaths per 100,000 population in 2018 — a 13% increase
- Suicide is the number 1 cause of death for people aged between 15 and 44 in Australia. In 2019 there were 3,318 deaths from suicide.
- For every death by suicide in Australia, it is estimated that there are 30 attempts made.
Obviously there was a strong motivation to get this right. The team and I were encouraged to explore all the options available and create a solution that would help people live with and manage their suicidal thoughts. We had two specific goals: broadening the reach of the program so that it is widely adopted and accessible. And the highest imperative was that we must not increase the risk to an already vulnerable group of people.
Eight steps taken to ensure the user was front of mind
Step One: Stay close to the users (people with lived experience of suicide) throughout the entire journey.
From the initial product discovery right through the product build, we had representatives from the Lived Experience community give their direction and input. This was especially important because there was no way we could truly understand the user’s perspective otherwise. This led to different features than we had originally devised and significantly changed the user experience and interactions. An example of this was the addition of calming and distraction activities that could be used if the users were in a crisis.
Step Two: Constantly review and test assumptions and biases
In product development you’re often unknowingly making choices based on your own assumptions and biases. With this project, it was more important than ever to continually review and test our assumptions — to ensure the choices we were making, were shaped by our users’ needs. As an example, one of my early assumptions about the target users, was that they wanted to eliminate their suicidal thoughts — but this isn’t necessarily always the case. For some of these users, having those thoughts can actually be comforting because it gives them something to hold onto.
Step Three: Letting our target user needs dictate technology choices
When making choices about technology in product development, it’s common practice to segment the target audience to best understand their needs. In this case we were challenged as there didn’t seem to be an easy way to segment the target user base. Suicidal thinking can affect anyone, which meant we had to cater for a wide variety of user types — young and elderly, a mix of races and cultures, low and high socioeconomic status. This led to decisions about the solution needing to be available in poor or no network conditions (i.e. to work offline), have a simple to understand interface and to cater for a range of learning types. It also meant we needed to support users on a range of platforms and device types (potentially a broader scope than you might typically do). This led to us building a cross-platform native application using Flutter — which meant once downloaded onto the phone the user would be able to use it whenever they wanted.
Step Four: Creation of a custom set of principles to guide the build
Based on our interaction and user interviews with the Lived Experience community, we developed a set of principles that we would use to guide the solutioning. This allowed us to be considering the user even if they weren’t present. In our case our five principles were:
- Safety First
- Respect
- Empower
- Simplicity
- Build Trust
Step Five: Creation of a cross-functional team, with agile delivery practices, to optimise collaboration and handle the inevitable pivots required
Our team was a mix of DiUS consultants and experts from our partner, Black Dog Institute. It was important to have a range of skill sets as part of the core team, to be able to collaborate effectively and get to the outcome required. Core members of the team included a product owner, program designer (learning component), delivery lead, developers, experience designer, visual designer and quality assurance. Having the cross-functional team allowed us to pivot — which occurred a number of times — more effectively. The nature of the solution also meant we had some cyclical dependencies — where the learning component (program) would dictate the technology platform and the platform / program would also dictate the experience design which would affect the program. So it was necessary for this close collaboration, without which I don’t think we would have achieved a solution that was best optimised for the users.
Step Six: Employ lean principles to optimise efforts and manage inherent risk
Whilst this was an important initiative, we were still limited in terms of resources, meaning we had to make the best use of what we had — so we looked to leverage lean principles. Examples of this included: only building our requirements as needed (add the detail as needed — in case we pivoted), building in automated testing, setting up a wiki / Slack to share information, re-use any existing components built in other projects, and technical spikes to gauge the feasibility of integrations with external systems before commiting. However whilst we were trying to continually deliver, we couldn’t actually release this incrementally to our users. It was critical that we were pragmatic in our approach because we were delivering a program for which the safety of our users was of utmost importance.
Step Seven: Design and build a solution to be flexible and modularised enabling easy replication and speed to market for similar future initiatives
We were building a completely new platform so we did add effort to ensure what we built would be extendable and components could be re-usable (with minimal re-work) across future initiatives. For example, programs that would cover other mental health treatments including depression, anxiety etc. Whilst this wouldn’t necessarily improve the user experience for the current product, it should allow for a quicker delivery to market in the future.
Step Eight: Evaluate the program with data
It’s always important to use data to gauge the performance of a product. Also given safety was paramount and as part of our partner’s ethos, success will be evaluated through a peer-reviewed clinically controlled trial. So whilst we engaged with our users throughout, the only way we could truly determine success would be off the back of a trial (which would further remove any biases on the part of the delivery team). The trial is scheduled for early 2021 and we are optimistic to see positive outcomes for our lived experience users participating in this trial.
I personally found this an extremely rewarding project to work on. Whilst at DiUS we often get the opportunity to work on a range of unique products, this has been the first that truly required such an introspective view of my own assumptions and biases in how we develop products. I’m thrilled we were able to utilise our skills and expertise to successfully deliver a product, that I hope will bring a positive impact to our users.
If by reading this you need any support — reach out to:
- Emergency Australia — 000
- Suicide Callback Service — 1300 659 467
- LifeLine — 13 11 14
—
Statistics sourced from from: https://www.aihw.gov.au/reports/australias-health/suicide-and-intentional-self-harm and https://www.blackdoginstitute.org.au/research-areas/suicide-prevention/)
—
Got a question about this project or how we can help with something similar? Get in touch.
—
Written by: Joel Jamieson, Principal Delivery Lead at DiUS
Joel is a delivery lead with more than 15 years industry experience. He is passionate about trying to make products that make someones’ life better and enjoys trying to fit the pieces of the puzzle together. He cut his teeth as a developer, before seeing the light (literally) and now enjoys working with people. When off-duty you’ll find him at the beach, on the bike or nursing his latest sporting injury.
