I had the opportunity to join a team of designers creating an iOS application for NextGen– a healthcare technology giant. As a visual designer my primary role was translating the results of the efforts of the designers into an interface that adhered to strict iOS standards.
Bachelors Informatics; Masters, Human-Computer Interaction
Bachelors Informatics Specializing in Software Engineering
Bachelors Cognitive Science, Human-Computer Interaction
Interaction & Visual/UI Designer
User Centered Design
In the past complex applications were developed and released with little user inquiry. Users then needed extensive training and had to adapt their workflow to the software.
Companies that are rooted in the old way of developing applications can be slow to embrace design thinking. We experienced friction from within when we introduced the User Centered Design process.
All of the designers stayed true to the User Centered Design Process. A design partnership with a nearby orthopedic practice was formed. Armed with research plans they started gathering requirements, doing early prototyping and testing, and observing the physicians to help understand the context in which the iPad application were to be used.
The designers started to identify common issues and themes. They were able to produce research communication tools that highlighted office roles, everyday tasks, and pain points. They identified key stages in the physicians workflow and turned it into a common loop. On the other end Nicole was also able to create a journey map of the patient which gave a detailed perspective of what the patient is experiencing before, during, and after their visit.
Translating Findings into an Appealing Interface
It was my job to understand all of the results of the testing, prototypes, interviews and higher level research findings to drive the higher fidelity designs.
Honoring Research When Making Important Design Decisions
The primary screen of the application is the Now Screen. Listed are the current appointments and times. How did we distill the screen to just patients in the office ready and waiting to be seen by the physician?
We went through many different revisions. Initially, we listed the past and upcoming appointments that weren’t in the office yet. We weren’t happy with the visual clutter and lack of focus.
An “Aha!" moment occurred when we realized that that the answer was in our Follow the Light Loop research document. When the light turns on the only patient the physician is thinking about is the one they need to see Now.
We moved the past and future patients into their own respective screens. An idea we may have never thought of, or could have justified if it weren’t for our research. And that is how the appointment screen morphed into “Now”.
Self Imposed Constraints
We adhered to the primary themes in the iOS human interface guidelines to meet the user’s expectations. The references to iOS might look uninspired, but we wanted the interactions and UI to feel natural to the user.
Viewing a document is a great example. There is the real life model of viewing a document when you hold it in your hands. And then there is the iOS conceptual model of interacting with a document. Tap to hide the nav bars and give a black background, pinch and zoom, move the document around. Double tap to fit the document on the screen. Single tap to bring the menu bars back. We didn’t want to force the user to learn new gestures when iOS already has an established paradigm.
Settling Design Disputes
The patient Facesheet is everything the physician needs to know about the patient in 30 seconds or less. When I was working on one of the many iterations of the Facesheet we came up with the idea of horizontally scrolling the documents to save screen real estate.
Jordan felt that the document thumbnails being cut off by the edge of the screen needed to provide more affordance. He suggested an arrow with a drop shadow to promote horizontal scrolling. I agreed but felt that cutting off the content would be enough and keep the UI free of embellishment.
How did we settle this design dispute? By guerrilla testing. We handed the iPad loaded with this hi-fi prototype to people around the office and asked them simply what they thought and to answer using the think aloud protocol. To prevent skewing the results we agreed to not ask questions that would direct the test subject to the documents section.
The first three users we tested naturally scrolled horizontally on the documents section (sans arrow). After the fourth did the same Jordan gave me the nod and we walked backed to our desks, and that is how we went with the cleaner design.
We put every aspect of the UI was under this type of scrutiny. More importantly, we could question each other's design decisions and we were ready to defend and solve the disagreement with objectivity. “Because I’m the ________ designer!” wasn’t enough justification.
Make it Smaller
The usage context for the iPhone would be different than the iPad. Physicians don’t want to appear to be on the phone while interacting with the patient. We wanted to solve the problems physicians had outside of the office. Below are some concepts of our high level ideas.
We turned the Now screen into a higher level appointments screen. The physician now sees an overview of their day through out the different practices.
Notifying Front Desk
The physician can be aware of the time it would take to get to the practice and if they’re running late they can conveniently notify the front desk.
If the physician is waiting in line somewhere they could easily view, and approve or reject their ever growing PAQ list.
Make it Bigger
The iPad was targeted towards physicians. The iPhone concept would work for them when they were out of the office. But what about all of the other roles in the practice? We started to discover the need for a multi-platform suite of applications to solve the two pain points we kept running into: communication and collaboration. Solve these two and not only do you help the users, but you help the patient receive quality care.