Design a Mobile Patient Portal

 

Background

I was asked to design a new mobile patient portal app for iOS. We had an existing web-based patient portal that I could leverage, but the intent was to redesign the app completely. I was given a pretty aggressive timeline of 6 weeks from initial research through final specs.

 
Screen Shot 2018-08-11 at 12.19.33 PM.png

Research

  1. All great interface design begins with research, and this project was no exception. Prior to the project kicking off, my team and I had already done about a year of qualitative and quantitative research, so we had a pretty good idea what our patients required. 
  2. My first step was to document what the patient needs would be. I did a quick affinity of research insights and created the needs structure shown to the left. 
  3. I emphasized areas we were currently supporting and areas that the patient found particularly important so we could prioritize features correctly in the first releases of the interface and have good discussions with product management around them. 
  4. I also pointed out two areas that were "blue ocean" opportunities for future roadmap conversations. 
 
Screen Shot 2018-08-11 at 12.18.48 PM.png

INformation Architecture Round 1

  1. Once I have user needs identified, I like to use them to help determine what the high level IA should be. 
  2. I placed anything information related into two primary areas, your record and health information. Your record would include data and health information related directly to the patient, whereas health information would be general information that any patient could use. 
  3. I placed high priority needs under a take action area. This way the patient could have instant access to those items. 
 

Storyboard

  1. With the first draft of the IA complete, I brainstormed a few task flows such as reviewing testing results on a whiteboard.
  2. I then storyboarded on the whiteboard what a typical experience would be like for a new patient logging into the portal and then going through each of those task flows.
  3. I was able to then bring all of those different flows into one storyline and created a final storyboard. 
  4. I reviewed this storyboard with developers, along with the AI above, to ensure the functionality and workflow could be supported for our first release. 
 
Screen Shot 2018-08-11 at 12.21.12 PM.png

INformation Architecture Round 2

  1. With the storyboard approved, I created a revised Information Architecture that now structured the areas into mobile tabs, pages, and dialogs.
  2. This diagram also captured the interconnections between each page. 
  3. This IA was reviewed by developers as well as in-house physicians for feedback and approval. 
 

Final Comps

  1. As I was creating each of the artifacts above, I was also creating comps to start getting ideas about the overall visual style, lay-out and to "pressure test" whether or not the overall structure made sense on a tiny screen! I'm not a huge believer in wireframes, because I believe visual design can have a huge impact on the perception of interface controls, etc. As a result, I have a tendency to do what I would consider medium to high-fidelity comps... but quickly. 
  2. I reviewed these comps with many people in-house - developers, designers, physicians, sales, marketing and leadership - to get feedback and suggestions. 
  3. I also reviewed the comps with a few patients to do "guerrilla" prototype testing.
  4. Taking all of this feedback, along with the IA and the storyboard above, I quickly and iteratively created final comps for each screen. I've included the primary screens to the left, but several more screens were created as well.
  5. The most innovative feature was the timeline (Image 2). It really resonated with patients because it matched their mental model regarding how they think of their health - by time!  Our product management team was also excited because it was something they hadn't see a lot of our competitors do. 
  6. The other innovation was the take action toggle (image 7). This was developed before iOS had force touch, but the concept was the same. If the patient held down the icon in the right hand corner, other quick actions would appear. Whatever was selected from this fly-out menu would then become the icon in the righthand corner. This would allow patients who mainly used refill prescription to have it remain persistent in the righthand corner at all times.
  7. I purposively placed the take action functionality in that corner, because I knew it would be the quickest for users to find. Users always seek corners, particularly on mobile devices.
  8. While the quick toggle was liked, we didn't end up using that functionality because it was difficult to implement given the timeline and patients were somewhat confused by it in testing. 

Overall, I achieved my 6 week timeline for this project and the patient portal was successfully launched.