Remedy Mobile — Designing for healthcare

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


Product Designer


June 2019 - Jan 2020


Shipped Remedy Mobile in Jan 2020. Received positive feedback from Doctors and started work on the Web App for Doctors


2 Engineers, Executive, Business Development (Sales and Marketing) and Legal Teams


Our parent company, Two Point Conversions is a data archiving company. We work with large hospitals like Mercy Health that have legacy data that is 50 years old. We convert this data into more modern formats and store it securely.


Two Point Conversions is a company that collaborates with Large Hospitals and archives their legacy data. Sales Cycles are long and to generate a new potential revenue stream, we want to see if we can open our services to not only hospitals but also patients.

We have over 30 years of experience building HIPAA compliant infrastructure which gives us a competitive advantage.

The Problem


Healthcare in the US is fairly inaccessible. In Chicago, a patient needs to wait on average 19 days before they can see a doctor.

The Solution

A mobile healthcare platform for patients and doctors, called Remedy which includes an iOS app for patients and a Web app for health care providers. This portfolio piece focuses on the iOS app.

An iOS app that allows patients in Chicago to provide healthcare information like their insurance information and their visit reason and allows them to book an appointment from a list of available doctors essentially on the same day.

Skip ahead to the Final Design →

Research - Empathize with the Patient


The goal for this step was to perform generative research, denounce my assumptions and understand the journey a patient in the US goes through, from the time they are sick to the time they feel well.


Objective - Understand in detail the journey of a patient in the US from when they fall ill, to when they get well again.

Key Result - Draw a patient journey map


image illustrating all the different research methods I used to understand the patient's journey when they fall sick which are 5 interviews with doctors, 1 focus group with members of a large hospital, 40+ interviews with recent patients, 3 interviews with medical receptionists, 21 interviews with internal stakeholders, guerilla interviews with industry experts at HIMSS conference 2019 and secondary research

Research Methods used in the Discovery Phase

Photographs taken at HIMSS conference 2019

Guerrilla research at the HIMSS Conference 2019

8 Step - Patient Journey Diagram

What we found is that the patient journey consisted of 8 steps. The first step is 'Pre-Illness' when the patient is healthy and before they fall ill. 'Post-Illness' is when the patient has completely recovered from their illness.

8 Step - Patient Journey Diagram

Define the Problem

Defining the Scope of the Project

We used the key insights from the interview notes and attached them to the patient journey map, so that we could visually analyze which particular areas had the most issues.

Patient Journey Map from Interview Notes

It became apparent that there are 2 stages in the patient journey where patient's face the most pain.

  1. (Step 4) The process of booking an appointment and
  2. (Step 5) The visit itself. Our goal was to identify what was causing the pain and how to solve it.


From the interview notes, we conducted an Affinity Diagram study and came to the conclusion that there were 3 areas that contributed to the problem. If we could solve these we could bring the time time it takes to book an appointment to less than 1 day.

Problem Spaces - From Affinity Diagram

Problem 1: Searching for a doctor is inefficient

Today when a patient is looking for a new doctor, they try to get a recommendation from a social contact. When this is not available, people search for doctors online using Google Search or through services like Yelp.

This involves a lot of trial and error, because none of these services provide live doctor schedules, or updated insurance information, or other important information like whether that doctor accepts new patients or not.

Initial Prototype

We started out our prototyping phase by creating low fidelity prototypes that would help users filter our database of doctors based on:

  1. The reason they are sick (aka. Visit Reason)
  2. Their Insurance information

Search Screen - Initial Prototypes

Insurance Search is unintuitive

I realized that our designs were really difficult to use because there isn't a universal format for insurance cards like credit cards. On top of that people have multiple insurance cards on them most of the time.

Also, Insurance information can be broadly broken down into Insurance Carriers. Each Insurance carrier contains Insurance Providers.

... Verbiage doesn't make sense. User Tester
... I have multiple insurance cards ... Which one of these texts do you want me to enter? User Tester

Update screens to match existing mental models

Instead of giving users the freedom to enter their 'Insurance Carrier + Insurance Provider', we realized that users prefer in this context restricted freedom. So we decided to match existing mental model and create 2 steps - force users to enter their insurance carrier first, and then let them select their insurance provider.

Search Screen - Iterations

Final Flow - Further improving task success rates

As we continued testing, we still noticed a percent of people making errors when asked to search. We were able to solve this by breaking up search into two parts. 1) Search for Doctor and 2) Search for Insurance

Similar to insurance, we learned that patients don't know what illness they have. Their current mental model encourages them to search for the doctor's specialty (which they know), and then get them to choose from a list of potential visit reasons filtered by previously selected specialty.

Search Screen - Final Flow (~100% Task Success Rate)


Iteratively updated Design System based on Usability Test results

Problem 2: Searching for available appointment slots is not possible

The current user flow involves a lot of trial and error, because doctor availability information is not publicly available. Some practices share their operational hours however real time schedules are unavailable.

Initial Prototype

We started out our prototyping phase by creating low fidelity prototypes that would help users select an appointment on a day/time they are available.

Appointment Screen - Initial Prototypes

User feedback

We experimented with a progress flow UX however it proved to be complex to use. Unlike with the Search module, users valued flexibility and freedom here.

... This (appointment progress UI) should be more flexible. I might not be in a position to fill out a medical form. User Tester
... If I book 4-5 recurring appointments, I'll have to scroll a lot to access the final appointment's information. User Tester

Appointment Screen - Iteration 2

Users found that using a modal to display upcoming appointments was unintuitive. Many users could not understand what was going on and didn't realize that they were in the 'Appointment Confirming' state.

We added an animation to each of the appointment cards while they were in the 'confirming' state, to further indicate to the user that these appointments were still being processed.

More than 90% of our users brought up this issue during testing.

Appointment Screen - Iteration 3 (~100% Task Success Rate)

Appointment Confirmation State Animation

Final Hi-Fidelity Interactive Prototype

Task: Confirm an appointment and with Dr. Amanda

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 Remedy to play the part of the parent for everyone using Remedy!

Remedy Branding - Initial Versions

User Feedback

Our user testers perceived these versions of our illustrations as too playful and indicated that they might not trust the app.

Remedy Branding

Designing our MVP - CONCIERGE MVP

We realized that we didn't need to build a backend or a provider-facing application to test these hypotheses. When a patient booked an appointment, one of us on our team would manually call the requested practice and book an appointment on behalf of the patient.

By eliminating the backend, and the complexities that came with it we brought down the time to ship our Mobile App and start testing by 6 months at least

Concierge MVP


Screenshot of the Remedy mobile app that can be downloaded from the iOS App Store.
Screenshot of the Remedy mobile app that can be downloaded from the iOS App Store.
Screenshot of the Remedy mobile app that can be downloaded from the iOS App Store.
Screenshot of the Remedy mobile app that can be downloaded from the iOS App Store.

Remedy Web for Doctors

During the pandemic, we saw an increase in provider side demand for the app. Doctors were having to close their practices, and rapidly change their schedules because their patients were holding off visiting doctors.

Visual Design

The process for Remedy Web was similar to Remedy Mobile, in that we used a human-centered philosophy. The requirements were not ambiguous, and the 'Jobs to be done' were a reflection of the jobs to be done in the mobile app in a different format. So one difference, is we could bypass the 'Discovery' phase and jump straight into Ideation.

Remedy Web Portal for Providers

Product Design Roadmap

Some of the concepts that are currently being tested with users and if validated will be next in line are:

  1. Contactless Check-In for patients
  2. Integrating Remedy with Providers' EHR and Health Systems and allowing patients to access their medical records through the Remedy Mobile