Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Behavioral Science ›› Designing Care Through Messaging

Designing Care Through Messaging

by Samihah Azim
7 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

DesigningCare_Slider

Integral to transforming the delivery of care are deep explorations, research, and prototyping.

Quality primary care sets people up for a healthier life — critical to that is optimizing the patient experience around communication. At One Medical, when traditional messaging paradigms didn’t meet expectations, I turned to research, creative prototyping, and testing to design a better solution.

To design a solution that met our users’ needs better, I first needed to understand why communication in healthcare was broken. To do this, I did a deep dive in researching how the average American was currently communicating their health needs to their medical providers. For many people, they had to call their doctor’s office because not even email was an option. For those that had some form of messaging available to them, it was barebones and outdated to fit the needs and lifestyle of healthcare users today. We weren’t content with the status quo, we wanted an experience that was central to how our members took care of their health and reflected how our medical providers took care of our members — elevating the quality of care and delivering it in a way that’s personalized and tailored to a member’s lifestyle. This led us to reimagining what messaging meant and the “job” a user would hire messaging for in context to their health.

The Research Journey

To start, we needed to understand how, when, and why someone would communicate with us. We had an existing Patient Journey Map that we populated with post-it’s to indicate pain points in communication, potential pitfalls in lack of transparency, and delightful moments in experiences. This informed some of the problems we would need to solve for.

Messaging Platforms

Deep analysis of various existing messaging platforms.

I took the additional step of dissecting various messaging clients that were both consumer and enterprise-facing but were not exclusive to the healthcare industry (many thanks to the countless friends and colleagues I inundated with messages on these platforms!). We didn’t want to redesign the wheel completely— messaging is a problem that numerous companies have solved for, so we wanted to understand what design patterns were being used, what would make the most sense for One Medical member needs, and what “next generation” messaging meant in that context.

 Initially, we hypothesized that a team communication structure would likely make the most sense for us to look into further — we could have private “channels” set up for our members depending on who they wanted to reach out to. I ran a bodystorming exercise (also known as, “experience prototyping” — and an inexpensive way to quickly surface problems) where I had one of our iOS engineers play the part of a One Medical member. I was the automated bot that triaged inquiries. One of our web engineers played the part of a medical provider, and an engineer on another team played the part of a second provider. We quickly found some major holes in the experience. If the bot collects important information and a provider jumps into that room, does it create a new room? How did the medical provider gain that important information? When the user spoke to the second provider, where did they come from? Would it be awkward to the user if someone just started chatting with them out of the blue about their inquiry without any context on how and why they know the information that they do?

Prototyping Outside the Proverbial Box

We had to test this out further, but we wanted to learn quickly in the least resource-intensive way possible, while maximizing on our learnings. This is where we got really creative with our prototyping, using Slack to prototype our hypotheses. Our Product Manager set up a session where we found three One Medical team members outside of the Product Development team to hop on Zoom (a video conferencing tool) with us so we could observe the experience during our test. We had a script and a few scenarios to follow. What we learned was that a communication tool based around the team collaboration experience is great for organizations, but for our needs, the model of having multiple channels could potentially mean unnecessary cognitive load and confusion for our users — and potentially our medical providers.

Behavior Patterns

Organizing information as it relates to user behavioral patterns (photo is intentilnally blurred).

We took our learnings to further refine the Slack model to fit our constraints, but we also wanted to explore other approaches to solve messaging in the context of healthcare. Going back to the (figurative and literal) drawing board, we came up with three potential approaches:

  1. Allow users to create as many channels as they’d like (analogous to Slack or Hipchat).
  2. We provide a limited number of channels that a user can direct their messages to based on their needs (Eg: any available provider, their specific care provider, etc).
  3. We only have one input channel which gets triaged appropriately to the necessary team.

Myself, and the other designer on the consumer-facing team then worked on creating wireframes and prototypes for each of these approaches. Using Engineering time to build each of the three options wasn’t a viable solution, so it made the most sense for us to use Invision to prototype and design the prototypes for the web experience. We also had prototypes in Principle for iOS to get a sense of what the interaction on mobile would feel like.

Getting the Whole Team Involved

On usability test day, I invited everyone on my team, as well as team members from the other product teams to hop in, observe, and share notes with us. We had participants hop on Zoom, and share their screen so the observers in the room could take notes. Each participant tested two of the three solutions. One of our key learnings that affected each of the solutions is that it was difficult for participants to suspend disbelief on using a prototype because the text box wasn’t interactive. The need to test a messaging product with an interactive prototype that felt more real was a key learning that we brought into future usability tests.

Usability Testing

Usability Testing Day – we invited the wider Product Development team to observe our sessions.

We also learned that while many people know what the credentials M.D. signify, they didn’t know what PA-C or NP was. However, these acronyms gave a sense of trust to participants that they were communicating with a medical professional and someone qualified to give clinical care — when no credentials were present, it caused ambiguity on who the participant was communicating with and broke trust. Additionally, the images of the providers next to their names solidified the sense of trust and humanized the experience. For a healthcare product, designing for trust and humanizing the experience is core to everything that we do, so this was important.

Option 1: our learnings from previous user research sessions (body storming, and using Slack as a means of prototyping) taught us that we needed to iterate from learnings from previous sessions if we were to learn anything new. The version we tested was a version that incorporated learnings from the previous prototype testing sessions. What we learned is that perhaps the biggest positive from this option is in most instances, the user knew who they would send a message to— we also learned that this was more of a nice to have than need to have. A negative was that the pane that held all of the messages caused confusion, and creating a new message wasn’t particularly intuitive.

Option 2: this is where we had a finite number of channels that a user could hop into based on the topic of their question. This option had positives and negatives. The biggest positive takeaway was that the context of the messages were very clear based on which room the participant was in. Perhaps the biggest negative takeaway was the friction in navigating between channels to get medical care or questions answered — it was unclear when to use each of the specific channels.

Option 3: this option was the least confusing. The UI was easily understood, groupings of messages in chronological order worked well, and the solution fit well with the long-term vision of delivering care through messaging. However, we found not letting people choose their recipient and forcing messages to go to a general queue first, wasn’t an optimal experience and caused frustration.

Designing the Messaging Experience

We chose to lead with the format of Option 3, but incorporated the best aspects of Options 1 and 2 as it made sense. This version of messaging that I researched, prototyped, tested, and designed, is available to all members in all markets. The first of our incorporated learnings has already rolled out. We saw that patients needed to know if a provider was out of the office and wouldn’t be able to respond to their message (this is especially helpful when communicating with the Primary Care Provider). So I designed a solution that let the user know when a medical provider was out of the office so that it helps them decide who to send their message to.

Integral to transforming the delivery of care are deep explorations, research, and prototyping.

iOS Experience

The first two are of the iOS experience where we notify users when their PCP is out of the office. The second two screens are of the Android experience.

Web Messaging

Secure Messaging on web

This article was originally published on Medium.

 

post authorSamihah Azim

Samihah Azim ,

Samihah is a Product Designer at Lyft where she sits at the intersection of business goals and designing experiences impacting local communities. Prior to Lyft, she was designing for local commerce at Postmates and crafting high quality, affordable patient-facing healthcare experiences at One Medical. In her free time, she mentors for the State Department program, TechWomen, enjoys powerlifting (seriously!), and cooking. She wholeheartedly believes in constantly learning and going after your goals. She tweets as @samihah

Tweet
Share
Post
Share
Email
Print

Related Articles

Consistency is helpful as a tool for designing user-friendly experiences. Until it isn’t.

Article by Robert Stribley
The Tyranny of Consistency

The article critically examines the role of consistency in design. It argues for a nuanced approach that prioritizes clarity and user experience over strict adherence to consistency norms.

Share:The Tyranny of Consistency
5 min read

How health-centered design can save lives across the world.

Article by Michalina Bidzinska
Hey Siri: call an ambulance
  • The article delves into the limitations of current voice assistants, emphasizing Siri’s language constraints in emergencies.
  • The author advocates for a paradigm shift towards health-centered design, urging designers to prioritize features that can save lives, particularly for the increasing number of seniors living alone.

Share:Hey Siri: call an ambulance
8 min read

Generating AI images in multiple languages leads to different results.

Article by Yennie Jun
Lost in DALL-E 3 Translation
  • The article critically examines OpenAI’s DALL-E 3, the latest in AI image generation.
  • The author sheds light on the model’s prompt transformations, revealing language-specific variations, and biases, and a nuanced exploration of how this technology navigates issues of diversity and transparency.

Share:Lost in DALL-E 3 Translation
11 min read

Did you know UX Magazine hosts the most popular podcast about conversational AI?

Listen to Invisible Machines

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and