Making core workflows simpler for practice staff dealing with patient requests
The Foundation
My Role
Senior Product Designer - Messaging Team
Co-led inbox and internal messaging workflow strategy with Product.
Planned and ran user interviews, surveys, and usability tests.
Improved team ways of working to increase pace, alignment, and delivery quality.
Refined product-level OKRs and problem framing to clarify priorities and guide the roadmap.
Setup
Working Constraints
Predominantly remote: Design/Engineering in Europe; Product/Sales/Support distributed across the U.S. → limited overlap and slower access to stakeholders.
Customer access wasn’t direct. Account managers controlled access, so we prioritised high-signal research and avoided anything that felt experimental.
Sales commitments sometimes outpaced the roadmap, so we had to ensure feasibility early on and manage internal communication to avoid overpromising.
Klara was trying to gain a foothold in a competitive market which translated to us having to accommodate customer requests and take on much of the onboarding and some system admin tasks. So any self-service features that required upfront investment had to be very intuitive in order to be utilised by a practice.
The Context
Klara’s core product is a shared inbox where staff receive patient messages in one place and triage them to the right people.
As Klara grew, larger practices were handling increasing volumes of patient messages without being able to scale their front-desk teams at the same pace. The inbox became the place where everything landed — triage, routing, voicemails, and follow-ups — even though it was originally designed as a simple list of conversations.
The problem wasn’t a single broken flow. It was the accumulation of small, manual steps repeated all day: opening messages just to understand them, moving conversations between inboxes, and dealing with voicemails that took longer to process than text. Over time, those small inefficiencies created real operational drag, especially for high-volume practices.
Digging Deeper
Looking at support tickets, usage data, and talking to Customer Success and practice staff, a pattern showed up quickly:
Front-desk teams were doing too much work just to work out what a message was, before they could even respond. Messages arrived unassigned, voicemails slowed things down compared to text, and useful actions lived one click further away than they needed to.
So the inbox could do a better job of helping staff make decisions.
Klara organised a 3 day session at the ModMed HQ in Florida which included workshops on prioritising the roadmap for the following year and solving some of the larger issues at hand.
There, amongst all of the roadmap and Ways of Working sessions we began looking into the inbox workflows topic and ideating on viable starting points.
Research included speaking with our customers about their existing workflows in Klara, where they were coming unstuck, and the workarounds they currently had in place.
On top of that we began looking into our Looker dashboards to build up a picture of how different types of moved from patient to practice, through the practice triage process, and back again.
Personas
Using customer interviews and data we were able to build small set of "Practice Personas" which showed us behaviours and traits at a higher level than a single user persona. That was useful because interaction with Klara workflows was often dictated by the organisation's ways of working and how practice admins trained their staff.
So we learned a lot about our large organisation customers and had a reference to share with stakeholders when discussing decisions being made.
Through rounds of discovery we were able to develop a picture of common workflow problems that, if we solve them, could have a big impact on our customer's working day…
Our Focus
Customer Needs
Problems
Developing Our Ideas
Gathering Regular Customer Feedback
We were able to take our early ideas to regular "Customer Council" meetings to sound out improvements and get input on the problems we were addressing. On top of that we ran regular customer surveys using Pendo.io which allowed us to gather feedback from targeted users actually using the workflows at that time for better input.
Outcome: We realised the bolder changes were greeted enthusiastically in our customer calls but when we presented actual prototypes large changes to the UI .
Deciding What To Optimise
Practices use Klara in a multitude of ways depending on their specific setup and workflows. Our job was to narrow down the key wins that would impact the greatest number of users. We took our viable ideas and put them into an Impact/Effort Matrix in a team workshop.
Outcome: A suite of five key changes to implement in stages with some changes unlocking others as we build. This let us deliver three smaller improvements as we continued planning the two larger changes on the map.
Mapping Scenarios & Logic
The model for any automations and shortcuts could be could take various forms depending on effort, technological limitations, user case, and so on. So we mapped the primary use cases we had and worked with users and engineers to figure out what was possible and then, within those bounds, what was most impactful and practical.
Outcome: Map for all of our key scenarios that we would iterate on and use as the the basis for setting the technical foundations before any UI design work was considered.
Explore Each Interaction
Within the flows where were dozens of individual potential touch points for staff from explicit interactions to status messages. Together they formed the staff's experience of their Klara workday.
Outcome: We treated the touch points as a whole to ensure the chain fit together seamlessly and consistently. UI elements and interactions that had existing, related uses in the app were unified in the design system.
With a clear picture of the workflows we're solving, team and stakeholder alignment, and a progressive release schedule we could build our solutions…
Principles & Approach
A handful of key points were agreed upon that would guide any solution we produced:
Make most common tasks maximum 2-3 clicks
If there’s an active order, you shouldn’t be able to lose it
People want reassurance more than perfect timing
There should only be one clear answer to “where’s my order?”
Assume the app gets interrupted — and make that fine
Fix the obvious pain first, then build on solid ground
Small changes, big knock-on effects
Results Snapshot
Key Workflow Efficiencies
Message Automations Builder
Staff can set a rule to either:
Route matching messages to an existing inbox (dropdown), or
Auto-reply with a templated response (textfield).
Extra value for our larger target customers: choosing which practices a rule applies to, not just one. This allowed any efficiency saving to scale while cutting the setup time needed if rules were setup on an office-by-office basis.
Outcome Snapshot
~5 mins to publish a first working rule (typical on first use)
Finding: the biggest stumble wasn’t the logic - it was confidence. Admins hesitated at “go live”, so we added clearer scope cues and an easy disable/duplicate path.
The old inbox was just a list: name, inbox tag, and sent time.
We rebuilt it to support quick actions, while giving enough context to act without guessing.
It was part of a wider push to reduce the hop between the inbox list and the conversation view.
A customisable multi-pane inbox + conversation was the north star - but the build cost (and the workflow change it would’ve forced) was too big at the time.
Better context + Actions upfront
= Fast, accurate message triage
We tested a few small changes to make decisions faster:
Staff avatar in the preview to show the last message was from staff, so you’d know a patient wasn’t still waiting.
Message counter to show multiple new messages, as a quick urgency cue.
File indicator to surface attachments that could affect triage.
Voicemail preview widget to make voicemail obvious and let staff play it from the inbox without opening the thread.
Future Exploration
The multi-pane concept took inspiration from the email inboxes staff already used, and industry-leading messaging tools like Slack.
We explored it at UI level and got good feedback, but the change was too large - technically and for customer adoption - to make it onto the roadmap.
LLM Enabled Workflows
I was able to work directly with a Google AI engineer who was leading a 12-month collaboration with Klara to implement LLMs and AI to improve patient and practice outcomes.
Voicemail Transcription + Meaning Layer
Klara already supported voicemails, but they landed as a simple audio player in the conversation view. We used an LLM to convert voicemail audio into text, unlocking a bunch of time-saving workflows.
Displaying voicemails as text let staff scan faster than listening in most cases, and made it easier to double-check anything unclear in the audio
To push it further, we added “Play from here” - splitting the transcript into individual words and wrapping them as links, so staff could jump playback to a specific point.
We also trained the model to extract meaning from the transcript and surface it in a way that supported quicker actions and decisions:
Quick links to relevant patient documentation or actions like message forwarding
Highlighted keywords staff rely on for care decisions (medication, patient details, usual doctor, etc.)
A short summary block under the voicemail to make the key info more digestible and actionable
Suggesting Templates In Converation
Beyond voicemails, we used the LLM to follow the thread of a conversation and suggest the best-fitting existing reply template.
Staff could reject suggestions and leave feedback, improving future recommendations.
Trust Is Key
Research showed 67% of surveyed staff were hesitant to trust fully automated suggestions (even though most still said they’d try it). So we focused on showing value without overselling accuracy while the model was still learning.
That meant careful wording, clear feedback, and easy alternative selection. We also tested confidence scores, but anything under ~95% caused suggestions to be ignored - even when they were correct.
All logic and interactions with the suggestion elements were to ensure we were could either serve useful options or if not offer another logical outcome while still training the model and maintaining user trust.
Outcomes
~14% of inbound messages
now route automatically
Repeatable message types only - the rest need human judgement
~9 hours saved per month
across the shared inbox team
Average week varies by ~±25% with workload
~40% faster handling
with transcription + “Play from here”
Scan first, jump to the exact moment that matters