Remedy

Empowering patients by providing them with faster access to health care!

ROLE - PRODUCT DESIGN LEAD

Works with the company’s Founder and President to understand customer problems, create the vision for the product and create product hypotheses to measure success, while keeping the company's goals in mind.

Creates user flows, prototypes of different fidelities, assets (logo, icons, graphics for app and online ads, etc.) and UIs based on user centered research and stakeholder interviews while validating each through multiple iterations of user tests.

PROJECT DURATION

June 2019 - Present

Summary

Our parent organization, Two Point Conversions has been in the health care space for the last 30 years. While they have been serving large hospital businesses like Mercy Health, Bon Secours, etc. by archiving their patient data, I was brought in as the company's first UX hire to help conceptualize a product that would be used by patients!

While we were aware that health care in the US was very unaccessible, we wanted to dive deep into the patients journey to figure out what all the pain points were and see if they had a need for such a product.

The Problem

HEALTH CARE IN THE US IS NOT ACCESSIBLE

Release of Information (ROI) is a document that allows the patient to decide what personal medical information they want to release from their file, who they want it released to, how long you can release that information and under what statutes and guidelines it is released

The existing process for ROI is slow, costly and inefficient.

Process Overview

Solution

A mobile app that allows users to easily and securely share their medical information with doctors before visiting them.

Remedy on the App Store (Version 1 was launched on the 3rd of April, 2020)

Phase 1: Discover

OVERVIEW

The goal for the Discovery phase was to connect with our stakeholders. We wanted to talk to them and really understand their journey and all the problems they had with it.

Stakeholder Map

RESEARCH METHODS

SYNTHESIS METHODS

CO DESIGN WITH STAKEHOLDERS

Consolidating all our research, we learned that a patient's health care journey can be broken down into 8 stages, from before they fall ill to when they fall ill and eventually recover.

This information was consolidated into a user journey diagram on our white board, and we invited stakeholders (including health care providers, industry experts, receptionists and patients) to come help fill in the diagram with what they thought we had missed out.

We noticed that our stakeholders were brilliant people and experts in their field, but a lot of them were relatively uncomfortable with technology. The illustrations were added to help alleviate this issue and to make the co design exercise more accessible for our stakeholders. This worked like a charm! Our co design sessions were super immersive and we learned a lot. Here are some of our key insights.

User Journey Diagram used for Co Design

KEY INSIGHTS

User Journey Mapping - Key Insights

PERSONAS

We used the information from our research sessions to create personas for our two main stakeholders - doctors and patients.

Provider and Patient Personas

THE PROBLEM REDEFINED

Out of all the key insights we decided to pursue #8

How might we encourage patients to fill our their medical information?

THE 5 STAR HEALTH CARE EXPERIENCE

I came up with a fun activity where me and the rest of the team (people who were being introduced to design thinking methods for the first time) had to come up with an imaginary over the top health care experience that they would rate it more than 5 stars on Yelp or Google Reviews!

This was inspired by Airbnb's 11 star experience, approach to creating products that I heard about on Masters of Scale

We asked everyone to focus on booking an appointment and visiting the doctor because this was the area that received the most insights (density of sticky notes). Here are some snippets from their 5 star stories!

... After getting back home the family has questions that you never thought of, and I give them them the notes that the doctor sent with me to address their questions. Anonymous, 5 Star Co Design
... On my first appointment with the GP, I got a message an hour before the appointment that the doctor was running an hour late, so I was able to use that time to catch up on work around the house instead of waiting in the waiting room. Anonymous, 5 Star Co Design
... I am a 45 year old man with a liver condition, a heart murmur, and type-2 diabetes ..... I was able to easily authorize coordination between the members of my team in advance, because communication between them is critical for a complex situation like mine. Anonymous, 5 Star Co Design
... After my last appointment, the app conveniently notified me of the results of my tests instead of having to go through the process of calling my doctor for the lab results and worrying if my condition has gotten worse or if the injections have had a negative affect on my body. Anonymous, 5 Star Co Design
... They choose to pay for their copay fee using Apple Pay through the same online portal to minimize human interaction. Less than a minute later, a doctor calls the patient’s name and their appointment begins. Anonymous, 5 Star Co Design

CONCEPT EXPLORATION

We then began rapidly ideating a number of concepts before narrowing in on a select few before creating user flows, user stories and storyboards to define user requirements. We voted on the concepts and decided to experiment with 2 concepts. This would give us enough breadth to experiment with ideas and interactions without straying away from the problem we were solving for.

#1 - APPOINTMENT SCHEDULER

A mobile app that allows patients to book appointments with nearby doctors, and fill out medical forms and share health records with these doctors prior to the appointment.

Appointment Scheduler - Initial Storyboard

#2 - DOC2DOC

A "social network" for patients and health care professionals that allows stakeholders to access and share their medical health information between each other.

Doc2Doc - Initial Storyboard

DESIGN PROCESS (TESTING IN LOW FIDELITY AND REFINING)

While the Appointment Scheduler prototype, tested well enough for us to receive valuable feedback to iterate upon, our testers found it difficult to understand the low fidelity Doc2Doc interface. We quickly decided to break the rules and create a digital (higher fidelity) version of Doc2Doc to fix this problem.

APPOINTMENT SCHEDULER - PAPER PROTOTYPE

Appointment Scheduler - Paper Prototype

DOC2DOC - DIGITAL PROTOTYPE

Doc2Doc - Initial Prototype

KEY INSIGHTS

Our feedback, for Doc2Doc was generally very negative. We took that as great news and decided to focus completely on the Appointment Scheduler opportunity.

1. People visit the doctor very rarely - The Doc2Doc concept is relevant to a niche group of patients who visit the doctor periodically - based on old age, chronic illness, etc.

2. The healthcare paradox - People care about their health but don't want to think about it, until they are sick. When they are sick they are in no condition to do anything additional about it.

3. Medical information is sensitive - Healthcare practices are apprehensive about a third party handling their patients medical information, and being liable if anything goes wrong.

4. The competition - It's public knowledge in the healthcare space that massive players including Google and Microsoft tried building their own version of a centralized health system, and failed. This makes doctors skeptical.

Phase 2: Define

OVERVIEW

The Discovery phase gave us clarity regarding, which opportunity to pursue. The goal for the Definition phase was to consolidate this information and use it to create measurable business goals to drive design, development and sales of our product.

OBJECTIVE & KEY RESULTS

Create a MVP by June 2020. An MVP is the smallest version of our product that can validate our Growth and Value hypotheses, and be used by potential patients and providers unsupervised.

1. Value Hypothesis - Will patients share at least one unit of medical history through Remedy?

2. Growth Hypothesis - Will health care providers recommend Remedy to their patients?

GO TO MARKET STRATEGY - GOOGLE DESIGN SPRINT

We wanted to focus on a go to market strategy before design began, so that we could incorporate it in design and not have to build our strategy around design. We needed to answer questions regarding branding, colors, design principles and product voice and we wanted answers as quickly as possible. The solution was to run a Google Design Sprint.

SPRINT PHASE 1: UNDERSTAND

COMPETITIVE ANALYSIS

We analyzed other companies in the space in an attempt to find patterns in what they were doing.

Source: https://appinventiv.com/blog/cost-to-develop-doctor-appointment-app-like-zocdoc/

LITERATURE REVIEW

We looked at analogous spaces to help influence our design thinking process. Here are some of the things we looked at for inspiration.

1. Hospital Waiting Rooms - Adding the perception of space by keeping things like cups and magazines in order, large lightly colored walls, etc. act as calming elements and help reduce stress.

2. Transparency - By letting patients see waiting times through wait-time boards, and doctor statuses helps reduce anxiety

3. Biophilia Hypothesis - A glimpse of the outdoors with windows can feel like a reprieve from the stress indoors. And as with artwork depicting nature and actual plants, it gives people something familiar to look at, and familiarity provides a feeling comfort.

SPRINT PHASE 1: DEFINE

PRODUCT MENTAL MODEL

We used the above information to help guide our next phase - the Definition phase. We consolidated the information and built a word cloud with ideas using which people were defining the space.

BRANDING PHILOSOPHY

A parent taking their child to the hospital puts on a brave face and constantly tries to convince their child that everything will be alright! We wanted to be that parent for all patients using our app!

SPRINT PHASE 3-5: SKETCHING TO VALIDATION

SKETCHES AND PROTOTYPE - ITERATION 1

Sketches and Prototype - Iteration 1

SKETCHES AND PROTOTYPE - ITERATION 2

Sketches and Prototype - Iteration 2

SPRINT PHASE 6: VALIDATION

After Phase 4 or the Decision phase, we had two types of prototypes. The first one was a more rough, hand drawn version. We were really proud of this prototype because it was in line with all our ideas of creating a friendly, warm and approachable product and most importantly cost of development was really low.

Unfortunately, it didn't test as well as we hoped. Our users found it difficult to trust because it was perceived as too playful and childish.

So, even though the digital illustrations would cost more to build, we decided to go with it. We do only what our users want!

DESIGN PRINCIPLES

Aesthetic Integrity - Aesthetic integrity represents how well an app’s appearance and behavior integrates with its function. Remedy is used by people who are feeling unwell. Demonstrate respect and empathy for their time and attention through thoughtful and elegant craftsmanship.

Clarity - Eliminate ambiguity. Enable patients to see, understand and act with confidence.

Efficiency - Streamline and optimize workflows. Intelligently anticipate needs to help patients perform tasks better, smarter and faster.

Consistency - Create familiarity and strengthen intuition by applying the same solution to the same problem

PRODUCT BRANDING

This helped us answer questions related to branding, color palette, typography, illustration and iconography.

Remedy Branding

Phase 3: Design

OVERVIEW

The goal for the Design phase was to come up with a hi-fidelity mockup to hand over to the development team.

RECAP OF OUR GOALS

Create a MVP to validate our Growth and Value hypotheses by June 2020

1. Value Hypothesis - Will patients share at least one unit of medical history through Remedy?

2. Growth Hypothesis - Will health care providers recommend Remedy to their patients?

DESIGN PROCESS

We used the above information to help guide our next phase - the Definition phase. We consolidated the information and built a word cloud with ideas using which people were defining the space.

APPOINTMENT SCHEDULER - PAPER PROTOTYPE

Appointment Scheduler - Paper Prototype

APPOINTMENT SCHEDULER - MEDIUM FIDELITY PROTOTYPE

Appointment Scheduler - Medium Fidelity Prototype

HI FIDELITY DESIGN

1. Search for nearby doctors

Patients can log into the app and search for near by doctors based on their symptoms and insurance provider

2. Search from a list of doctors

Patients can search for available doctors based on flags such as whether the doctor is accepting new patients, whether they support video appointments - this was a change incorporated as a result of the virus.

3. Provide your availability

Learn more about the doctor on their profile page that includes their biography, education history, experience, cancellation policy and more after which you can provide them with your availability.

4. Provide medical information

Fill out any medical forms in the app and share it securely with your doctor before your appointment. That way you won't have to fill out the form at the hospital and the doctor will be able to see you as soon as possible.

Since we securely store this form on our end, you can share the same form the next time you visit the same doctor, or the next time you visit a doctor that requires similar information.

USABILITY TEST FEEDBACK AND ITERATIONS

We used the above information to help guide our next phase - the Definition phase. We consolidated the information and built a word cloud with ideas using which people were defining the space.

1. Search screens are not intuitive

I asked potential patients who signed up for usability tests to complete the following task, 'Book an appointment with Dr. Amanda because your mouth hurts and it's probably a wisdom tooth'.

Patients found it difficult to navigate our search screen. I had previously opted for a less screens, less clicks approach, but changing this increased task completion rate.

The new approach made users go through a fixed flow. They would first select the type of doctor they would see, then choose from a list of potential reasons.

2. Appointment screens are not intuitive

It's not clear what happens after you book an appointment. Do you have to wait for someone to approve it, or does it happen automatically?

Initial appointment screens allowed for patients to book only 1 appointment at a time

3. Quantitative Needs Validation of File Sharing Idea

I decided that it was too risky to implement a fully fleshed out file sharing feature without being sure that there was an urgent need for it.

I added an experiment explaining the feature, as a means to validate its need

4. Care Team

Based on feedback, we decided to scrap the 'Care Team' module. It was a nice to have, but we could validate our MVP hypotheses without it.

Phase 4: Build

OVERVIEW

The goal for the Build phase was to bring the design to life, and create a our technical MVP to be used by our users unsupervised by us.

ARCHITECTURE SUMMARY

We used the above information to help guide our next phase - the Definition phase. We consolidated the information and built a word cloud with ideas using which people were defining the space.

Remedy High Level User Navigation

PROGRAMING LANGUAGE

Some of the Frameworks we explored included Native, Flutter, React Native, Ionic and Cordova.

We decided to go with React Native. The variables that influenced our decision making could be categorized into User-Centric and Team-Centric. Some of these variable included:

User-Centric Variables

  1. Maintaining a native look and feel
  2. UI consistency across iOS and Android
  3. Time to market

Team-Centric Variables

  1. Learning curve for developers and development costs
  2. Total number of code bases to manage
  3. Available online documentation
  4. Competitive Analysis - What do other companies do?

DESIGN SPECIFICATION LANGUAGE

To enable effective and efficient communication between developers and design, all mockups were designed around an 8 unit spacing guideline framework.

Every element on the screen would be spaced and sized in numbers divisible by 8. By implementing this in the code itself and writing the application around it, we would be sure to decouple development and design.

Spacer Guidelines - Examples

LESSONS LEARNED

The Onboarding Flow - Lazy vs Traditional Registration

Somewhere along the line I forgot that we were building a MVP and not a product. One example of a module, that I would have designed differently is the Onboarding Flow.

The Remedy App, used Lazy Registrations for Onboarding. We allowed new users to experience the app, and book an appointment before having to create an account. The reason? Lazy Registrations provide a better UX and we would definitely see as good or a better onboarding success rate. What I didn't take into account - Lazy Registrations require you to store different user states and so, is more costly to develop.

The flaw here is the MVP should have been designed ONLY to test our value and growth hypotheses. What if a traditional registration had delivered a good onboarding success rate as well? We'll never know.


Concierge MVP - Appointments Backend

We decided that since we would be working with a small number of early adopters only, after launch - we could get away by replacing the entire Appointments backend with humans. Every time we received an appointment request, I would manually call the medical practice, book the appointment and change the required attributes in the backend, manually. This would bring down engineering time by 3-4 weeks, and we would still validate our MVP hypotheses.


Designing Workflows in Small Batches and not Large Batches

When we first began work we worked in large batches. for example, I would work on hi fidelity screens and hand them over to Dev and then they would begin working on the front end, and once that was done, backend work would begin.

This was a very costly process. There were instances when I would fail to communicate design effectively and we would only realize this once front end work had begun. As a result, we would have to stop front end, and I would have to go back to square one, re-do my designs and re-submit to the development team. This is one of the reasons the spacer guidelines framework was even built!

We changed our entire workflow to e completed in smaller batches - where work happened in parallel. We began to do work "just-in-time". In case an error was detected, we could detect it a lot earlier and there would be less waste.

Phase 5: Sell

STAKEHOLDER VALUE PROPOSITION MATRIX

We estimate customer (patient/provider) willingness to buy by plotting target persona vs target persona action.

Willingness to buy criteria:

  1. Not usable
  2. Usable but with no obvious benefits
  3. Nice to have. The end user will appreciate these benefits although they are not strategic to the organization sponsoring the purchase
  4. Should have. The end user receives strategic benefits, although these benefits can readily be achieved by other means as well
  5. Must have. The end user receives benefits that are strategic to the sponsoring organization and cannot be achieved by any other reasonably comparable means.

Stakeholder Value Proposition Matrix

VALUE PROPOSITIONS RESULTS

Use the following value propositions in sales pitch depending on campaign

Campaign targeting Providers and Patients - "Receive appointment reminders"

Campaign targeting Providers - "Strengthen online presence"

Campaign targeting Patients - "Receive appointment reminders"

PRICING

Pricing will be based on value to the Practice. Value is determined by estimating the net increase in revenue a new acquisition brings through our app brings to the Practice, and the LTV of that new patient. This ensures that we receive the greatest possible revenue for our product, to counter our high CACs.

In the long run,

  1. We can charge patients based on storage space utilized for storing medical records (Enterprise revenue)
  2. We can charge providers for new patient acquisition (Subscription revenue)
  3. We can charge providers for higher ranking in the search screen (Ad revenue)

Price Simulation Model for Small Practices