Simple & Pretty — Product design & strategy for startups
The supportive way to take control of your own health
How we helped OCN envisioning a functional medicine digital approach to treating chronic conditions
Mapping the experience of chronic patients for OCN.
Project summary
We helped OCN inform their product strategy with in-depth UX research insights on their target users, their business needs and capabilities, and available market opportunities. After gathering UX and business requirements, we then assisted them in defining and scoping their product experience, team and strategy, so they could understand what they would build, and how they would build it.
Project background
When we joined the OCN team, they knew they wanted to create a digital health service that applies Functional Medicine to treat people with severe chronic conditions.
Their small team contained some medical practitioners and a former patient, so they already had ideas for solutions, largely based on digitising the existing model used in clinics.
They asked us to help envisioning their product and its offering. Before we did anything, we had much to learn about Functional Medicine and chronic conditions, as we didn’t have previous knowledge or experience in the space.
Project goal
Create a digital product which delivered similar (or greater) patient value, as in-person clinic-based treatment, with less cost to both the practitioner and patient. The service will improve patients’ understanding of gut-related conditions and symptoms and will provide potential for greater use of non-drug therapies.
Requirements
• Service must prove patient health improvement
• Generate user engagement
• Monetise or gain investment quickly
Challenges
• Limited Budget
• Creating a compelling solution
• Short runway
• No product team in place
• No existing process for the team to collaborate
• Preconceived solutions
How we gathered requirements.
The greater understanding we had about the problem space, the faster we were likely to design a more effective solution, reducing the risk of building the wrong thing. We started by putting together a research plan with the team that included the high-priority questions that they wanted to find answers too.
Research plan for OCN in Google docs.
We agreed on objectives, methodologies, timings and what resources they had available to us. We then conducted discovery research to identify who their target users were and what they needed from a service like this.
We looked into Healthpath’s business goals, needs and capabilities to solve for their audience.
We learned about the existing market offering to identify unique competitive advantages for their solution.
Problem exploration
For this project we needed to understand more about being a sufferer of a chronic condition and a patient —Who they are, how their experiences differed, the goals they have, the motivations that drive them, what they need and what frustrations get in their way. We wanted to know more about their health healing journey and how far through it they were.
Over 4 weeks, we worked closely with the product team and a functional medicine clinic in London, we conducted team workshops and interviews with practitioners and business stakeholders, to help them form a vision for the company and the product. It also allowed us to learn more about Functional Medicine and its comparison to existing treatment methods.
We conducted one-to-one user interviews with existing and new patients with chronic conditions, to understand it from the patient side. To gain more insight, we analysed the clinic’s database of 800+ patients' anonymised surveys.
Combined, this allowed us to map the full patient journey and understand user needs and pain points.
Judit affinity mapping, to identify patterns in OCN target users’ needs and pain points.
Research insights
We were moved by what we learnt from practitioners and patients. It seemed that many people were suffering from chronic conditions, many gut-related, and the pain and problems that brought were disrupting their home and work lives.
Many were out of work, and on and off a cocktail of expensive pharmaceutical drugs and not seeing improvement beyond the duration of taking the drugs.
According to Gutscharity: 1 out of 3 of people in the UK say they suffer on-going IBS symptoms. 70% of them say IBS is a “debilitating” medical condition that occupies their lives daily. However, due to cost and embarrassment, mostly only the sufferers of the most severe cases actually seek medical advice.
Functional Medicine introduces a more effective and healthy treatment for the long run. However, it requires the patient to make permanent lifestyle changes, the more severe and complex the symptoms, the bigger changes that are required… Not just pop another pill.
However making the needed lifestyle changes were difficult for most, and results slow. Even if they were motivated to make the required changes, they often eventually reverted back to their problematic lifestyle behaviours, feeling they weren’t making progress, misunderstood, under-supported and under-informed.
While one-to-one sessions with the practitioner seemed to really help them, it was too impractical or costly to get sessions at a physical clinic, as frequent or for long enough, as they needed to make and retain the lifestyle changes.
Identifying user types
With all the user data and insights we gathered from practitioners, clinic surveys and patient interviews, we identified patterns and commonalities to group users into types.
We identified that these different user types (personas) weren’t defined by gender, age or demographics. The key differentiators were severity and complexity of symptoms, length of the healing journey, impact in life and self-determination. We started by grouping them in 3 types, with their own specific motivations, needs and pain points.
UX strategy recommendations
The product team initially wanted to target the high severity, complex condition user type, as it most reflected the majority of their patients (50% of the clinic’s practitioners’ cases were complex, 30% moderate and 20% of their patients had none or soft symptoms).
We encouraged the product team to focus on the soft and moderate symptoms-types first, as this increased Healthpath’s target audience, and helping them achieve their goals would be easier.
This would hopefully provide proof of concept to show quick patient improvement and therefore user engagement, which would turn into faster monetisation.
Once we could prove the solution improves people’s health, it could expand the service to help people with complex conditions over time.
While patients in the higher severity, complex condition group would likely invest more for an effective solution, it would take more time and resources to design and build a service that could assist them in improving their health.
Focusing on specific user types helps designing the right thing for users and it also enables the product team to reduce project scope and make milestones more achievable.
It’s important to distill as much as possible what’s the most value the service can provide with the least cost and effort. This is especially important when time and money are constrained.
Solution requirements
Gathering 's solution requirements, while mapping the user journey.
With a better understanding of the problem space, the market opportunities and what both Healthpath and their target users needed, we established the solution should:
• Improve the user symptoms/condition/health
• Provide on-going support and community
• Provide guidance and education throughout the whole healing journey
• Enable users to track symptoms and see their progress
• Is very affordable for the basic service
• Has premium services e.g. Lab tests, practitioner sessions, supplements etc
Defining the solution
The next step was to define the product specifications: its unique value proposition, core features, intended audience, competitive advantage and UX requirements so we could translate these into a viable product.
Gathering product specifications helps everyone in the team know what we’re building and how we’ll be building it.
Understanding Heathpath’s business internal capabilities, team’s competencies and skills, enabled us to:
• Define a solution that fulfils both business and users requirements
• Identify team’s members key skills and roles required to build their product
Solution mapping
We then started translating the business and user requirements to functionality and user flows, distilling as we went. It’s easy to turn a mole hill into a mountain, so we prioritised the functionality based on importance to achieving users goals vs the time and cost of creating. We then grouped the functionality into ‘Must have’, ‘Should have’ and ‘Nice to have’.
Mapping OCN’s MVP.
Due to budget limitations, only the ‘low time and cost’ functionality items in ‘Must have’ would be built for the MVP. We could then plan the remaining ‘Must’ and ‘Should’ have functionality into project milestones, which are the foundation of the product roadmap.
This is intended to evolve during the project based on user feedback, testing and analytics, as we understand and learn more, but provides team focus and alignment.
Defining the functionality for the MVP meant we could refine the user flows and start creating the experience breakdown, exploring and outlining the service structure, interactions, information architecture and content requirements.
Healthpath’s MVP experience breakdown in Google Docs.
Delivery
We completed the definition phase by presenting the product specification document, product milestones, experience breakdown, key user flows and service structure to the team follow by in-depth Q&A. This allowed Healthpath to understand what they would build, how and most importantly why.
The team, the process and the tech-stack
With an understanding of the tech requirements and team capabilities, combined with the solution vision, we made recommendations on both the tech-stack and the skillsets the team required.
To build their service, we recommended Healthpath to utilise hosted tools and services, with free/low-cost starter plans, with the ability to scale with growth.
This would allow them to build out their tech-stack faster, allowing more time to focus on refining the experience, without wasting resources in building custom solutions, before they had reached their market and could monetise.
We suggested that they use Ionic for a common front-end codebase, allowing them to build their web service and then move to native apps, specifically iOS and Android faster.
Firebase for the back-end, which provides many common, expensive to build, required services like real-time database and cloud functions, allowing for chat and dynamic activity feeds to be created rapidly.
The content should be held in headless CMS such as Contentful, this would allow the content to be separated from the front and back-end, allowing Healthpath to build a more custom tech stack as they grew, without trapping or having to port all of their content.
This meant they would need a full-stack developer (a generalist in front and back-end coding), experienced in server-less architecture, using tools such as Firebase and Ionic. This first developer could lead the creation of the MVP, and when needed, could help with recruiting the next developer the team needed.
To help hire the people the team needed, we set up an automated and lean recruitment process, linking RemoteOK job posts and responses to Slack and adding candidate information to a google sheets via Zapier.
This allowed us to easily view, compare and select which candidates to interview and recommend for the role, with minimal effort and without a recruiter. We did this for the developer, a copywriter and an illustrator.
To collaborate efficiently with the team, we setup Slack for communication, Trello for planning and management, Google Drive for document storage and collaboration, Sketch for designs, Invision for prototypes, Abstract for design version control and design collaboration and UsabilityHub for user testing.
We encouraged regular team stand-ups with core team, and weekly catchups with full team. All work files were available to all relevant people, so collaboration and commenting could occur more easily, with least rework.
