Overview
Juno is a secure clinical messaging app for parents providing access to information and advice about their child’s health from Paediatric clinical specialists. The project started in April 2020 as part of Pando OKRs and after six months of development, it has become a completely new product with its own challenges, users and needs.
The goal of this project was to identify a monetisable problem for Pando to solve which incorporates patients. We had to research all possible healthcare problems globally and what Pando has to offer, with a focus on how to bring patients on to the platform.
I’m going to explain to you the whole process we followed, the challenges we found and the lessons we learned from a product design perspective until we launched this service.
1. Generative Research
If I have to mention a crucial part of this project, it was absolutely the well-defined and structured generative research our UX Researcher led. We were immersed on it during the first three months and it helped us to understand user problems and transform them into opportunities for solutions and innovation.
This type of research helps you when you don’t even know what problem to solve for your users.
We divided this stage into three phases: problem ideation, problem prioritization and assets desirability, feasibility and viability of solving each problem.
1.1. Problem Ideation
We identified stakeholders and problems, known or hypothetical, in order to generate a list with all possible stakeholders that could get value from Pando and therefore they might pay for a solution. After this diverging exercise, the list ended with more than 50 problem statements.
Afterwards, we assessed Pando’s weaknesses and most valuable features to converge and put our feet on the ground and to know which of those problems it was uniquely positioned to solve. This lightweight filtering reduced our list in 29 viable problems.
1.2. Problem Prioritization
With the full list of potential problems, it was time to prioritize between all of them and we kept the same strategy. We gathered more information to understand better the user problems (diverge) and we applied a matrix framework where we scored each problem (converge) by its painfulness, scalability and timeliness.
There were 7 which scored most highly and we selected 3 to carry forward into the next phase.
1.3. Assets DFV
We were very excited to arrive at the last phase of the research without almost any problem during the process and with three clear problem statements. On this phase, the goal was to get only one valuable patient-facing problem to solve based on their desirability, feasibility and viability.
We dept diving again into the problem space with more research and more interviews to learn everything we could about of the three problems (users, behaviours, pains, context..). This gave us the right context to think about potential solutions for each problem.
We scored again all of the solutions for each problem based on the impact it could have on the users, the confidence and the ease it could transmit to the user. Once we had a solution for each we would experiment to assess if the solution was desirable, feasible and viable. That was the initial plan.
2. Idea Development
The first problem arrived when we finished the research. The plan was to test quickly the three solutions through Pando to find a signal of the desirability, but the scope of the project changed because of the global pandemic. We were forced into make a final decision and to choose the final one. Time is short.
The chosen problem was: “As a new parent, I need a medical opinion when I have a concern about my baby's health, but I feel guilty taking up a doctors time when it is potentially nothing to worry about.”
And its solution: “A patient sends a question via app/website, and they have an async message-based conversation when the/a paediatrician is available to respond.”
Our next milestone was to launch it and capture data to learn from Juno MVE (Minimum Viable Experience) so we continued with our design process to build it properly. The ideation stage started.
2.1. User Stories and User Journeys
We created user stories and user journeys from parents and clinicians in order to understand the needs to be met in MVE. For example:
As a parent, when I reach out to a paediatrician, I need to get a timely response.
As a paediatrician on call, when someone needs advice about their child, I need to be notified.
The user journeys gave us a global vision of the processes. It showed us where bottlenecks and pain points were, and our goal here was to transform these problems into opportunities.
Once we had the ideas to solve the MVE problems we reviewed them to see if they meet user’s needs and what was not directly helpful and could be removed. This was a kind of Affinity diagram where we put everything (needs, problems, ideas, insights,…) on the table and we voted for what we were going to build for the launch.
3. Prototyping and Validation
MVE defined, engineers started preparing the battleground with technical implementation, we continued with product sessions to define data needed to measure the progress of goal/metrics and setting deadlines (internal testing and public launch).
My favourite part of the process started now, prototyping and testing. It was time to transform those requirements into designs, test them with real users and iterate if it was necessary.
3.1. User Flow
Before jumping into any design tool we like to recreate the steps the user must follow to achieve their goal. In this case for parents, their goal was to feel reassured and receive clinical advice for their children. From the paediatrician side, they needed to be able to respond with understandable medical advice in a timely manner. User flows are very helpful to know everything you are going to need for each screen, they save a lot of time when you have to design it and they improve in-app usability.
3.2 Prototype
Something we learnt from the testing sessions is to define the scenarios to test before start designing the prototype in order to only design what we will need.
Some people prefer to start prototyping with sketches but for me, it takes more time than doing it on a medium-high fidelity because of two reasons: we used native components for the apps so this gives us a lot of speed building but also designing it. The other reason is since we moved into Figma at the beginning of the year our design processes and speed improved considerably too.
3.3. Usability Testing
Another challenge appeared once we finished Juno’s prototypes, remote usability testing. We were used to jumping into hospitals and chasing clinicians for testing our prototypes, but this year because of the COVID we decided to avoid it for safety reasons and to run them remotely.
Although we were very well prepared it was a simple prototype without crazy tasks, it was our first time testing on remote and we learnt some important lessons about technical issues, misunderstandings and low bandwidth.
We tested the prototypes with 6 parents, a nice testing sample, and 6 paediatricians too. Overall the results were good and it went very smooth with limited usability issues.
3.4. Branding
In the meantime, we started thinking about the app visual identity and to define the brand attributes. Brand attributes are adjectives that represent the essence of the brand that allows the users to consistently identify themselves on the product.
Our Visual Designer created a vibrant, optimistic & well-balanced colour palette. He created also a very original logo that represents in a simple way a parent holding a child but if you look at it twice you can recognise a love heart shape. The tone of voice was defined by the Copywriter in conjunction with the Visual Designer using the brand attributes as a starting point and it must be applied everywhere we had text to keep the consistency across platforms.
4. Launch
Estimating a launch date seemed easy for us. In this case, it was a bit optimistic after all, and because of that, we needed to postpone the launch date a few times in order to meet parents and paediatricians needs. This doesn’t mean we did it wrong, it’s just we didn’t add any contingency time for unexpected events and that caused some delays on the project scope.
There were some relevant aspects of this stage that I would like to mention because they played an important role: the pre-launch planning, growth marketing and success metrics.
4.1. Pre-Launch
How did we prepare for the launch? It became a marathon because of the many steps we had to take. Recruitment, onboardings, information governance, safeguarding courses, internal launch, public launch. You won’t realise how many things you need to handle until you have the launch checklist.
These steps don’t appear in any product case study, but they refer to the orchestration and optimization of people and processes we had to follow in order to amplify design's value and impact at scale. That’s what people currently call DesignOps and it was absolutely necessary to bring quality to our product.
In addition to all the technical assessment we did, we set up a landing page before launching Juno with a waiting list where parents could join to know when the product would be live. This list gave us a clear signal of desire by the parents and the estimated amount of users we could have once we would launch it.
4.2. Growth Marketing
Juno is a B2C business so we required to suit a growth model for it. We learnt a lot about pirate metrics like the AARRR method for tracking product marketing and management campaigns but what we really learnt is we needed to have a plan.
You can’t leave anything to the fade of my product has a high-quality and we are solving a relevant problem. It doesn’t matter if it’s called AARRR or RARRA. You have to set up a plan for your customers with drivers to lead them through your funnel and with the right metrics to measure the success.
4.3. Success Metrics
Broadly speaking, we needed to demonstrate that we can attract and retain engaged users for a period of lifetime value that equals or surpasses the cost of acquisition.
We filled the app full of analytics events in order to monitor everything we could since the beginning. We needed to track the usage, funnel conversion rates, satisfaction rating and the time of response. All of them shape our success metrics in terms of quantitative data.
The qualitative data will appear from clinician's and parent's interviews that we will do after launch. It will complete the design process and thanks to it we will be able to keep evolving the app from a new perspective with new problems a needs.
5. Lessons learned
Where there is a problem there is a lesson to learn and we learnt a lot during this six-month project:
Roadmaps are a great tool but sometimes on a startup environment, you need to adapt quickly to changes on your scope without generating any drama through it. This is the way.
Planning is a tough task because you have to understand first what you need to forecast and during this understanding, you could lose precious time. If you find any blocker, solve it quickly or it could delay the whole process later.
Time estimations are a good way to way to forecast a project scope, even if you put yourself in the worst scenario but not having a concrete estimation could generate a lot of suspense and stress in your team.
Launches are always associated with high-stress levels because you want to be sure everything is ready and everything is going to work. Plan it ahead in order to get confidence and to reduce the stress in case of unexpected events that appear in the radar.
Remote testing is fun too. Everything that could fail it will fail and because of that you need to be fully charged with patience and kindness. Your testers will appreciate it.
Juno is now launched and live and it means a huge milestone to Pando’s team. We should be proud of the research and development we accomplished in record time and always following the process and keeping the “move forward” attitude that recognises all of us.
