Healthcare platform design for providers and patients

I was hired by startup to create a mobile and responsive application to improve pre-operative procedure preparation — all the things that need to happen before and after a medical procedure. I led a small team to conduct and deliver the user research, strategy and experience design for this new product.

The product would later be called eProtocol. Before beginning, we created a detailed list and understanding of the project goals. Sometimes it’s easy to jump right into solutions with the client or team, but this can be very troublesome and add confusion. One of the goals was to make these multiple user systems (two products) one for healthcare providers to monitor patients, and another for patients to engage with providers. We aligned the value/benefits between the two of these two user types. Multi-user systems can get very complex fast.

We recruited and interviewed eight former patients who had recently undergone this type of procedure. Our first goal was to understand the current pre-operation process since we will be asking the end users of this new product/service to modify their behavior. The interviews were recorded and the notes and findings summarized into a Journey Maps for sharing with the client team.

When working with a Journey Map, we want to summarize the information we do know to be representative of the many people we’ve spoken to during the interviews. One Journey map is sufficient for a unique group of users. In our case we also added a standard graphical model (top) of origination — or where patients started into the funnel from — some came from primary care, some came from specialists, etc… These entry points were very important (depicted it at top of the Journey Map) since these are the first touch-points of the patient experience we were modeling but improving upon.

Application Architecture

After research, we looked at other applications and frameworks across industries. We were also looking for parallel experiences which may be adapted to the needs of patients. In our case and for this procedure we were looking at an older audience and that had big implications on the approach to design. From our research there were enough participants (and from 3rd party research) that did not have the latest smartphones and were not super savvy users — the application had to be simple with fewer screens.

Once the team was in agreement of some directions we filled in the blanks and began discussing content requirements, screen navigation (Android and iOS), interactions for different features, and messaging for patients. We were to design two applications, one native app for iOS and the future version for Android, then the larger Provider application view to manage the patients.

Prototyping and design

We began prototyping our experience to share with the team. This is a very important step — we are beginning our explorations into what it would be like for patients and providers. Prototyping is a fundamental tool I know is critical to getting the experience right. First it helps the designer work through the details and learns early and often, and second, it becomes a communication tool for the team.

Detail design

With the prototype and overall interactions established we began on the details for the platform — in this case, we started with iOS. By the way, we did have some challenges on the project including new management and technical disagreements which altered the design further along. This forced us to modify some of the application — it happens.

We used vector graphics for icons and the user interface elements we included in our UI-Kit. From our experience Sketch was built from a production perspective so it is fantastic at producing what you need for mobile development, in other areas not so much, or it takes getting used to.

A UIKit is a combination of many of the graphical elements. It’s a great resource for getting a one-stop view of the different patterns and designs. We consolidated the iconography and translated screens for various applications into one Sketch file. After the assets, we worked with developers to implement and modify. In the end, the client was not successful and closed doors about a year later.

The product offered the ability to save costs for healthcare providers by introducing efficiencies. This reduced cancellations that many doctors and practices were scheduled 4–6 weeks out — time and money that would be lost. It was also for the patients, research showed that the better a patient is informed and prepared, the better the outcomes of the procedure.