designing
scroll
This case study is intended as part of a live presentation.
Want the whole story? Let's chat.
vision
Increase patient access to care with a collaborative inbox for HIPAA-compliant communication.
users
Research Tools
-
LogRocket
-
Mixpanel
-
User Surveys
-
User Interviews
-
Expert Panel
-
Focus Groups
-
Medical Journals
problems I helped solve
building a design system
Problem
Without a design system and well-defined layout, new features were built from scratch. The product felt inconsistent and was consequently hard to use.
Research
Navigation
Our primary users almost never left the Patients tab, and the navigation bar actions were rarely used.
Interaction
Key user flows required the user to navigate between multiple interfaces with distinct interactions. The user had to learn how to use each new feature.
Colors & Typography
A broad palette of colors were used inconsistently across the product, while typography was nearly all the same point size and weight.
I explored a variety of competitive and complimentary products to understand what the market looked like and what other software our users were interacting with.
Ideation
I rearranged actions into structured UI elements that offered a clear and consistent experience across the product and can be easily expanded to accommodate new features.
I reimagined the patient list and navigation bars to drive intended user behavior within the key workflows we were targeting.
Visual Design
.png)
I worked the CEO to build a deeper understanding of the brand we wanted to communicate. His words included "professionalism, warmth, and reliability."
Though blue delivered best on professionalism and was most common in the healthcare products I researched, the gorgeous sunset photographed above served as inspiration for the rest of the color palette.
Because first impressions matter...
The toolbar unified all actions on the page and offered an intuitive place to add new features as we built them.
The table was one of only two key interfaces. I removed extraneous details and colors so users can focus on the information most important to them.
I unified all patient-level actions, settings, and content into a single place so it was available during the conversation. With a menu structure, we were able to add new patient tools and information in the future.
I found many of our current and future user flows involved the user inputing information. I shifted nearly all user inputs into a standard form UI which we reused of a dozen times across the product for consistency and ease of use.
Interaction Design
In the original design, users predominantly interacted within a single tab. I repurposed the navigation bar to drive key user actions.
The expandability of the UI allowed us to drive user actions into filtered subsets of patients, eventually customizable by the user or their organization.
For example, an organization can add a list of patients overdue for outreach.
When I first adopted the product, there were barely any empty states so the user was often left having to figure out what to do next. I designed new interface components to drive user behavior as intended.
phone calling
Problem
Significant technical and regulatory constraints led to poor user experiences for both Navigators and Patients, sometimes discouraging phone call adoption altogether.
Research
User Insight
In interview after interview, users commonly complained about the phone calling experience. When introducing new users to the platform, phone call performance was often user's biggest concern both before and after experiencing our solution.
User Goals
-
Navigators and patients expect a normal phone call experience.
-
When deviations from a normal phone call experience are required, Navigators seek confidence in understanding the process.
-
Patients quickly lose trust with automated voices or call recording messages.
User Flows
A major challenge I faced was in the delay required for backend services to communicate with one another. For patients and navigators, this resulted in an awkward silence when the call was first connect.
To avoid interrupting the patient and navigator when the call was first connected with "this call may be recorded," I reorganized server requests and helped discover a new way to interact with the API.
Visual Design
As users toggled between desk and mobile phones, an inaccurate primary phone number would prevent a successful call. I added the ability to adjust which phone number Karuna calls to close the gap.
User Insight
Users struggled to understand Karuna's unique phone call experience, even after being trained. I found we were able to increase confidence in the product by being explicit about what the user should expect at the time of interaction.
Some users stopped using phone calls because they did not want their calls recorded. We added the ability to toggle this setting at the interaction level to increase use. After testing, we had to further refine how and when we play the "This call may be recorded." message to patients.
Initially a discreet banner at the top of the page, I redesigned active calls as a full screen experience. With a non-standard phone calling experience, it was more important Karuna users actively understand what is happening along the way to troubleshoot issues in real time.
To further encourage users to enable call recording, we learned we needed an option to remove recordings if sensitive information was shared.
Initially a text input field, we observed users inputing repetitive text or skipping the field to save time. I converted this to a dropdown to help simplify the process and capture structured call data for reporting.
Calls often failed for our users for reasons beyond our control, resulting in distrust and a perception of poor reliability. We added details about the call progress, along with tooltips to explain things that might seem wrong.
secondary contacts
Problem
Navigators were having conversations with family members, friends, and caregivers of their patients. But without support for
secondary contacts, users contacted them outside of Karuna or added the contact as a patient phone number, resulting in documentation inaccuracy.
User Goals
-
Navigators want to be able to communicate seamlessly with secondary contacts that support their patient's care.
-
Navigators need to accurately document encounters they have with secondary contacts to meet regulatory requirements.
-
Navigators must confirm the patient has consented for them to exchange PHI with secondary contacts via text message.
UX/UI Design
User Insight
For some patients like children or the elderly, Navigators communicated predominantly with the secondary contact. In other cases, the secondary contact was part of some temporary interaction.
Getting it right required a discreet UI and specific logic to direct users to the right conversation.
To reduce engineering load and meet minimum width constraints, I collaborated with a UX engineer to build a flexible component that can be used in both the tab bar and person menus throughout the product.
Secondary contacts had to be considered in every user flow, from phone calling to automated campaigns.
Designing secondary contacts was an even greater challenge on mobile, where a small screen size and an uncommon UX made interaction quite tricky.
It took some internal A/B testing to get the design for the secondary contact badge right. It was important it was easy to see and understand to the user, but Navigators reference their caseload by patient name, not the name of the contact.
repetitive messages
Problem
For certain kinds of messages like appointment reminders, some organizations required Navigators to include lengthy details with important appointment information.
We found users maintaining this copy in a Word doc, copying & pasting in Karuna when they needed. Sometimes, messages would go out with unfilled variables like <patientName>.
User Goals
-
Users want to easily send messages with repetitive content in Karuna without typing it manually or copying & pasting.
-
Users want to avoid accidentally sending incomplete templates to patients.
-
Each customer organization required a custom set of templated messages for their users.
-
Users want templated messages translated in the language of their patient.
UX/UI Design
As I mapped out the user flows, I realized there was a chance the user might not associate the currently selected tab with the template they choose. The recipient dropdown helped solve that.
The limited screen space of mobile forced me to split up the user flows into discreet steps and adjust some of the UI elements such as the form.
.png)
One of my earlier prototypes for templates allowed in-line editing. I replaced this with the above form for consistency with mobile and to leverage standard design system elements rather than building a new complex UI from scratch.
Eventually, we moved the template menu to a form as well, leveraging design system components to deliver a familiar, consistent experience with other key workflows.
I designed a user flow for sending templated messages out in bulk, similar to mail merge. To accommodate a variety of constraints, I had to map out all the edge cases that would templates from correctly being sent to a patient.
automated messaging
Problem
After normal business hours, patient texts and calls were still sent to the Navigators' phones, making it difficult for users to disconnect at the end of the workday and often leaving patients in the dark without a response.
User Goals
-
Users want to easily send messages with repetitive content in Karuna without typing it manually or copying & pasting.
-
Users want to avoid accidentally sending incomplete templates to patients.
-
Each customer organization required a custom set of templated messages for their users.
-
Users want templated messages translated in the language of their patient.
UX/UI Design
Combining automated messages with a manual chat interface required balancing of some complex constraints. I needed to avoid manual and automated messages from happening simultaneously. I started by mapping out the evolution of a campaign from being turned on to being dispatched.
Support for phone calls required some new research into phone trees and escalation workflows at user organizations.
Visual Design
.png)
If a user initiated a text message conversation shortly before the end of the workday, I wanted to require the user to explicitly acknowledge the patient might receive the After Hours message if they reply.
When a campaign is active, the navigator had an option to message the patient anyway or pause the after hours response until later. To accommodate navigators working late or outside of normal business hours, I also added an indicator to the navigation bar.
Once a campaign was triggered, I wanted to give the user an option to take over and manually reply, if they happened to be looking at the conversation. I had to carefully balance this with the engineering constraints that prevented 1-1 progress mapping.
-e.png)
After a campaign was executed, it would be important the user acknowledged the missed messages from the patient even though the most recent message was outgoing. I later adjusted the UI to leverage the orange highlight color on the specific parts of the conversation thread the user should focus.
This is a prototype I built to help test and validate parts of the campaign UX with potential customers.
This prototype demonstrated the user flow for enrolling multiple patients into a campaign at the same time.
task management
Problem
Karuna offered a collaborative inbox for healthcare providers, enabling multiple navigators to support the engagement and communication of each patient.
However, without a proper system for patient handoff between navigators, it was difficult for users to understand which patients messages they were responsible for.
User Goals
Ideation
.png)
UX/UI Design
.png)
Creating a comprehensive tasking experience to meet all the user goals required all-new supporting components that became quite complex for engineering.
Although I originally argued strongly for a dedicated task list, I was challenged by our CEO and product team to maintain the feature in the primary patient list.
By adjusting the primary table UI to integrate tasks, I was able to deliver on all the key workflows, rendering the dedicated task list e
By including an in-line history of tasks within the conversation thread, navigators would have the context to understand when & why other users joined the conversation.
I adjusted the UI to include text buttons to communicate more explicitly what the user should expect.
results & impact
1
User growth and activation rates increased from a dozen users to several hundred.
2
The number of patients engaged via Karuna increased from about 1k total to 2-3k/week.
3
Customer satisfaction manifested with an increase in sales growth and long term partnerships.
4
User satisfaction and ability to easily interact with the product improved substantially over time.
5
A strong design system enabled Karuna to more easily expand the product in the future.