Patient Intake
I was the lead product designer for a new feature that would allow patients to electronically submit their information, eliminating the need for paper and reducing data-entry errors. This feature increased the product attach rate from 16% to 50%.

My Role

Researcher- I conducted user interviews, desk research, journey mapping sessions, and research synthesis which allowed us to scope our MVP and prioritize the problems we wanted to solve.

Interaction and Visual Designer- I created concepts with low-fidelity mockups, interactive prototypes, and the visual design.

Front-end Engineer- In addition to working with our engineers to implement the requirements, I also worked on production code to help engineers meet our deadline.

Product Manager- I contributed to product strategy, aligning stakeholders, and developing a roadmap for this feature. I also set up key performance metrics that we wanted to hit with our MVP.

User Problem

Typically new patients have to complete a bevy of forms that provide consent, insurance information, and key data about their medical history and demographics. This is all often done manually at the doctors’s office on the day of the appointment. From there, the completed forms are manually entered into the practice management system by the front office manager within the practice, creating double work and potential room for error. The information collecting during this process is the foundation for the patient record that is captured within the electronic health record (EHR) system.

Business Problem

Our sales team was losing deals due to our gap in patient intake functionality especially since all our competitors already had this feature.

Who are our users?

Small medical practices (targeting family medicine, internal medicine, mental health, physical therapy, occupational therapy)

Research

The first thing I start asking my team is “What is it that we want to learn?” I document all our questions as well as assumptions that need to be validated. From this list of questions, we decided on the most appropriate way of going about answering some of these questions.

Discovery Research

We scheduled 12 interviews with different customer types (ex. Different sized practices, specialties, etc.). We also sent out a survey for questions where we would benefit from a larger sample size. I also did quite a bit of ‘desk research”, one of my go-to research methodologies. This consists of online observations which is almost as good (sometimes even better) than ethnographies. The central premise of ethnography is that you can learn what your users do when they’re not aware that you’re looking. Desk research enables me to observe and analyze what my users are already doing without me even having to leave my chair. I found a handful of medical practices that had posted their intake forms online and another handful of out-of-the-box forms that new practices were adopting. This gave me insight into the types of information various practices were asking their patients.

Insights from Discovery

  • A majority of practices require medical information such as past medical history, medications, and allergies. This, however, is not common across all specialties.
  • There is a set of information that practices ask their patients depending on the practice’s specialty. For examples physical therapists may want to ask questions around pain in a specific part of their body.
  • There is typically a review process that takes place once the patient submits their paper forms. This is done by two different roles in the practice, but it may by one person. The front-desk staff needs to review all the basic information like contact information and insurance information. The nurse, clinical assistant, or provider will want to review the medical information before the provider sees the patient for their visit.
  • Practices want to review everything that goes into a patient’s chart because the chart is the “source of truth”.
  • The practice needs to ensure that they have an up-to-date copy of the driver’s license and insurance. This is because when billers send out claims to insurance companies, they may need to verify some of the information by reviewing the driver’s license or insurance card.

Defining MVP

The goal of the business was to launch an MPV that would prevent our sales team from losing deals to patient intake. We limited our MVP to only collecting basic information, demographics and insurance information since this was common to all our target specialties. This would ultimately:

  • Reduce time spent by the front-desk staff manually entering patient’s information
  • Minimize number of errors from manual input by the front-desk staff
  • Enable the practice to check insurance eligibility prior to appointment
  • Reduce time spent in waiting room for the patient
  • Improved care due to more complete and accurate data entry by patient and office staff

Once we got this out the door we would tackle the medical information along with the specialty-specific information.

Concept Testing

Once we felt like we had a good understanding of the problem at hand, I put together low-fidelity concepts using Balsamiq. The goal of this exercise was to:

  1. Identify different workflows that would enable physicians to send intake forms, patients to submit forms, and the appropriate staff to review and merge the information received.
  2. Prioritize problems we wanted to solve.
I chose five customers based on role, specialty, and practice-size. I walked them through the various concepts and had them them think out loud to help me validate my job stories and potential solutions.

Prototype Testing

Once I validated my concepts, I created high-fidelity mockups in Sketch and created interactive prototypes using Craft and Invision. There were three experiences that I was testing:

  • Front-desk staff creating an appointment and sending out intake forms
  • Patient receiving an email with a link to complete intake forms and completing the intake forms
  • Front-desk staff reviewing and merging intake information

At this time we had a team of two designers supporting a product team of six people and I did not have the bandwidth to run usability tests myself. I recruited six sales consultants and asked if they could help in testing these flows. They were more than happy to do so, especially since they would already be on a call with prospects. I walked them through my Invision prototypes and taught them how to test it with potential customers. One week later, I collected their feedback and made the necessary changes. The feedback was very positive, customers felt like this feature would work with their existing workflows. There were a couple of small issues that came up that I was able to resolve in my iterations.

This is a pre-recorded demo that I sent to the sales team to show them the functionality I wanted feedback on:

Success Metrics

As we were scoping MVP and creating the roadmap for this new feature, we set up success metrics for ourselves. This is critical to our agile process for several reasons:

  • Present solid evidence that this feature is going to have a significant ROI
  • Use the results as tools to define, measure, and change our users’ behaviors
  • Know when a feature is fully “complete”

I also worked on putting together a post-launch plan along with events we wanted to track to help us understand usage.

Final Designs

Sending intake forms to a patient

View Interactive Prototype

Merging Information into Patient's Chart

View Interactive Prototype

Completing and Submitting Intake Forms

View Interactive Prototype

Overcoming Challenges

There was a lot of turnover over the course of this project. The lead engineer, our VP of product, and our Director of Engineering left halfway through this project.

An engineering squad with two new engineers took over the work for this project. Because we were short on engineering resources, I jumped in and helped out with implementing and cleaning up some of the UI.

We also did not have a designated QA team to test the feature, so the PM and I spent a lot of our time testing the functionality. I also had my engineers add me as a reviewer to their pull requests so that I could test the functionality and approve the UI implementations before they merged their code. This prevented a lot of back-and-forth changes from taking place once the code was already pushed.

Post Launch

The PM for this project left 1 week after we launched. As a result, I became interim Product Manager for this project. I wanted to ensure that we didn’t stop working on the feature after we launched MVP. I’ve been conducting feedback sessions with customers to understand how they are using this feature and what is still missing. I’ve been meeting regularly with the sales team to understand how the product is being pitched, how customers are reacting, why customers aren’t purchasing the feature, and what is still missing. I also put together a post launch survey that is linked from within the app so that users can provide their feedback as their starting to use this new feature.

All of this data has helped me iterate on the roadmap for this feature.We are currently working on launching phase 2 of this feature beginning of next year so stay tuned!

Check out the press release and our marketing page on Kareo’s Patient Intake feature!