When it comes to health data that people gather outside of the clinical setting, there is a disconnect between patients and those who care for them. Doctors often ask patients to track certain things like their blood pressure or weight, but it’s hard to keep up with that type of tracking and there’s no great way for patients to bring the data back to their doctors.
On the flip side, some patients are tracking detailed aspects of their health and bringing the resulting data to their doctors in a variety of formats (paper, spreadsheets, and more.) It’s time-consuming for doctors to try to learn a new data format each time, and there’s no easy way of ‘crunching numbers’ written on a slip of paper. And sometimes, the data just isn’t as interesting to the doctor as it is to the patient.
Our team at Open mHealth knew that digital health devices and apps could help lessen this disconnect and make it more efficient for doctors and patients to work together around health tracking. And, Open mHealth is an organization concerned with helping digital health data (like the data from a fitbit or a connected scale) flow more easily between systems.
We set out to create a new, more collaborative way for doctors to recommend (or ‘prescribe’) digital health tracking, and for doctors and patients to be able to more easily view and understand the resulting data.
Interviews with doctors + patients
Our team initially focused on Cardiology, because of the potential for digital health data to help with early intervention. I spoke with cardiology doctors, nurses, rehab counselors, and eight patients – especially focusing on the patient experience to understand the emotional concerns around the time of diagnosis and the ‘daily routine’ of managing a heart condition.
Distillation + modeling findings
After all those conversations, I had a lot of information to sift through. I held an affinity diagramming session in my work space and used post-it notes to start to group ‘like’ concepts into larger themes.
To help communicate some of these themes and trends to my team, I drew a set of illustrations, a few of which are below:
I also developed a set of personas based on the behaviors and mindsets I was hearing about – both from doctors and patients. (Sample below – some details blurred out.)
I shared my high-level findings with my team, including key insights, pain points, and opportunities uncovered in my research. I also shared the drawings and personas with them, and they all agreed that this was a very helpful way for them to better understand our end users. The doctor on our team mentioned that the findings aligned with her experiences, which was helpful and reinforcing.
Strategy & Design Brief
Based on what we had learned from our users, I also created a ‘Design Brief’ that included guiding product principles, UX principles, the product’s personality, tone and voice, color considerations, and other branding considerations. Here is a little snippet, also blurred out just a tad!
Concept Modeling & Diagramming
I like to communicate in diagrams. I outlined the potential structure of our web and mobile products, and the developers found this very useful for stimulating conversation and structuring the back end.
A concept model of how different ‘nouns’ (person, place or thing!) are related:
A product structure diagram:
An alerting process flow:
A lot of collaborative and solo sketching happened while we were getting the product off the ground. We were trying to work through both the user interface, and possible ways of visualizing information. Here are a few examples:
Some ideas for navigation:
some mobile interface sketches:
Our team took a deep dive into the data visualization process. We did a lot of work to understand the type of data that is generated by digital health devices, and we spoke with clinicians to understand what aspects of that data are most useful. Our goal wasn’t necessarily to come up with novel ways of visualizing information; we wanted to ensure that the information was recognizable ‘at a glance’ so that the system could be instantly understandable.
An idea for dealing with thresholds, which we eventually moved away from:
UI & Interaction design
On this project I served as UX, Interaction and Visual designer. We went through many rounds of design reviews and updates on the Linq responsive website and mobile app before coming to a structure, logic and visual language that aligned with the look and feel we were going for. For example:
A few early versions of our ‘home’ screen:
And getting to something closer to what we used in the end.
Prototyping and testing
I created prototypes using UXpin for our web app and Flinto for our mobile app. We used the prototypes to demo Linq and to test the products with patients and clinicians. We conducted both remote and in-person usability testing and learned a lot about how we could improve the way the data was visualized and the general structure and navigation of the products. One thing that was great to hear over and over was that the interfaces felt very calming. This had been one of our major goals.
Creation of a ‘design system’ specification
To ensure that our UI elements were well-defined and looked and acted the same way everywhere, I took a systematic approach to outlining our design system. Always thinking responsively, I outlined the look, feel, and behavior of elements like forms, buttons, navigation items, and other responsive modules that were more specific to our web app.
I worked collaboratively with our developers and made sure they understood how each piece of functionality was meant to work. This involved co-working, creating specs and prototypes, and just generally good communication.
Linq is a product that resonates with both clinicians and patients. The next steps are to integrate more tightly with the clinician workflow and optimize the product so that it can help organizations with preventative care. Our team is proud of what we created, and we have had enthusiastic feedback from healthcare institutions.