Designing a faster, smarter way for coaches to document patient touchpoints — eliminating multi-system friction, ensuring billing accuracy, and unlocking $100K in annual savings.
Two distinct but connected problems made this project worth building — and understanding both shaped every design decision that followed.
Coaches held "Provider" access in Elation, InStride's external EHR, at ~$300 per user per month. Across nearly 75 coaches, that's over $100K annually. Leadership had identified this as unnecessary — coaches weren't heavy Elation users — but couldn't simply downgrade their access because the billing pipeline depended on it. Coach time was billed by reading appointment records directly from Elation, which required Provider-level access to create. No access, no record. No record, no bill.
This wasn't a design problem on the surface. But solving it required designing a new workflow that could auto-generate visit notes — decoupling billing from Elation access entirely.
To log a single interaction, a coach had to navigate across multiple systems: open the patient chat, switch to the calendar, create a new appointment event, estimate the time spent, and save — for every interaction, across up to 20 patients. Coaches estimated this consumed roughly 2 hours per week on average. Some logged in real-time. Others waited until end of week, reconstructing interactions from memory. The result: documentation that was inconsistent, often inaccurate, and increasingly forgotten altogether.
Missed logs meant missed bills. Inaccurate estimates meant inaccurate billing records. A process meant to capture clinical work was actively undermining the revenue it was supposed to generate.
The design opportunity: Find a single workflow that served both problems — one that could auto-generate the billing record while making the act of logging so fast and low-friction that coaches would actually do it, accurately, every time.
The daily reality before: Open patient chat → switch to calendar → create appointment event for proactive/reactive coaching → estimate time → save. Repeat for every interaction. Across 20 patients. Often reconstructed from memory at end of week. Input the same information into multiple systems. Every. Single. Week.
Coaches context-switched across the patient chat, calendar, and Elation to complete a single logging task — creating cognitive overhead and entry errors.
No system reinforced the right behavior. Coaches logged when it was convenient, not when it was accurate — leading to missed interactions and bulk memory-based reconstruction at week's end.
The entire billing pipeline read coach appointments from Elation — requiring expensive Provider access. It was structurally fragile, costly, and impossible to scale.
A supporting visual kept intentionally simple: the work moved from multi-system reconstruction to one contextual action in the existing chat workflow.
I led design end-to-end. Rather than waiting for complete requirements, I used early high-fidelity mockups as a forcing function — giving stakeholders something real to react to and helping the team surface assumptions, constraints, and gaps before they became expensive to resolve.
I have a habit of working in high-fidelity early — not to over-commit to a direction, but because our stakeholders are in the platform every day. Abstract wireframes create distance. When I put a mockup in front of a coach or a PM that looks like the actual product, they stop translating and start reacting. That's where the useful feedback lives.
I built early mockups directly on top of existing high-fidelity screens. New features were called out with bright accent colors or clearly labeled callout boxes. Each screen was annotated, and I'd create a single summary screen at the top that captured the full flow at a glance — so stakeholders could orient themselves before diving into detail. This became the artifact that structured every early conversation.
Logging moved into patient chat where coaches were already working, reducing context-switching and making the default action feel obvious.
History gave coaches visibility into what had already been sent, while limiting edits to what was safe for billing integrity.
My early assumption was that coaches needed to log all forms of patient communication — emails, phone calls, texts, and chat messages. That wasn't wrong, but it was incomplete. Through early syncs, I learned these interactions fell into two distinct categories with different behaviors and entry points:
This distinction shaped the entire design. It told me where the logging action should live — inside the chat, where the majority of interactions already happen — and what the modal's default coaching type should be based on context of entry.
It also surfaced the behavioral range question: some coaches log in real-time, others at end of day, others at end of week reconstructing from memory. That range had real design implications. I couldn't design purely for the real-time case. The interface needed to support bulk, retrospective logging without making it feel like a chore.
Once I understood that most coaching interactions happened in the chat, a new question emerged that wasn't in the original brief: our internal chat platform lets coaches schedule delayed messages. If a coach schedules a message while it's top of mind — then it's sent later while they're offline — how does logging work for that interaction?
The PM flagged this as worth exploring. I took the initiative to go further. I did market research to understand how other tools handle time-logging tied to async or scheduled communication, looking for patterns I could learn from rather than designing from scratch. That research, combined with the workflow I'd already mapped, led me to a flow that let coaches opt into logging time at the moment they schedule a message — with the note only generating once we received confirmation the message was actually sent. If the message failed or was cancelled, no note would be created.
This feature collapsed two separate tasks — scheduling and logging — into one moment, exactly when the context was freshest. It was one of the most celebrated parts of the launch.
The log-time toggle appears at the scheduling moment — letting coaches document time while context is fresh, with notes generated only after confirmed delivery.
The idea for a historical log view came from a previous project — automating notes and sending them to Elation. In that workflow, if a user needed to make updates after submission, a manager had to go in and manually correct records in Elation. There was no way for the user to see what had been sent or self-serve a small fix. I didn't want to repeat that experience here.
My instinct was that coaches would want visibility into what they'd logged — both to catch mistakes and to build a clearer picture of patient interactions over time. I mocked up a log history showing the past seven days of entries, with the ability to edit time duration only. When I shared this with the team, the response was immediate — yes, this is needed. It became part of the MVP scope.
The constraints around what could be edited came later, once engineering walked through the implications of modifying records that had already been sent to Elation as billing notes. That conversation is what led to the most complex design problem in the project.
I shared designs with the internal product and design team first — a session that surfaced key scope questions around editing complexity and the weekly plan's role as a shared clinical record. I brought those open questions directly into the coaching leadership review rather than resolving them internally, which made that session far more productive.
As the logging workflow took shape, I realized the value of coach touchpoints could not stay buried in chat or billing artifacts. Therapists and psychiatrists also needed that context in the Weekly Plan — the shared clinical source of truth used across the care team.
That question expanded the solution from a time-tracking form into a system-level workflow: log once, generate the billing artifact, and surface the right clinical context where the whole team already looks.
The design shift: This was not just about making logging faster. It was about making coach work visible, useful, and accurate across the clinical system without creating more manual entry.
Coach notes now auto-populate into the Weekly Plan, creating visibility for the broader clinical team while reducing duplicate entry and version drift.
Early in the design, I explored giving coaches the ability to edit their logged entries freely — updating dates, coaching types, and notes after submission. It seemed like an obvious quality-of-life feature. Mistakes happen. Coaches log retroactively. Of course they'd need to fix things.
Then I started understanding what actually happened when a coach hit "submit."
The moment a log was saved, our system generated a visit note in Elation — signed by a system user, timestamped, and immediately readable by the billing and data teams working in those records daily. That note wasn't just a coach-facing log. It was a billing artifact. It was what insurance would eventually see. Editing it wasn't a UI problem — it was a data integrity problem with downstream consequences we couldn't fully predict.
The core tension: A single tap on a submit button touched the billing pipeline, the clinical record, the data team's Sigma reports, and eventually an insurance claim. Designing with that full system in view — not just the coach's screen — was the real challenge.
The interface protected the billing record by blocking duplicate proactive logs for the same date and directing coaches to the appropriate correction path.
On-call coaching notes written by coaches in the logging modal were being passed through to the weekly plan — the clinical team's shared source of truth. Therapists, psychologists, and coaches all reference it. My initial design allowed coaches to edit these notes in the weekly plan after submission.
Clinical leadership pushed back hard. If a coach edits a note in the weekly plan and that edit doesn't sync back to Elation, you have two different records saying two different things. A therapist reads one version. The billing team sees another. From a clinical documentation standpoint — that's not just inconvenient. It's a liability.
But locking the weekly plan entirely created its own problem. Coaches revise their notes. They get feedback from managers. If we made it read-only, we'd be replacing one frustration with another.
The answer came from engineering: the "dummy note" approach. Send a minimal, structured note to Elation for billing purposes only. Keep the weekly plan as the coach-facing record — editable and contextually rich — but stop trying to keep the two systems in sync.
The two systems would serve different audiences with different needs. Billing needs a timestamped record that a note occurred. Clinical documentation needs a living record of what happened. Once I reframed the separation as principled rather than a compromise, the design became clear. Coaches could edit time duration only from the log history view. Everything else required a manager-assisted path in Elation — rare enough in practice that coaching leadership agreed it was an acceptable tradeoff.
Several moments required navigating between what was technically feasible, what was clinically safe, and what would be genuinely useful to coaches. These were the most meaningful calls.
Multiple entry points existed. Placing it in the patient chat — the primary workspace for coach-patient communication — reduces context-switching to near zero. The majority of proactive and reactive coaching originates from or is visible in chat, making this the most contextually natural entry point.
Forcing coaches to always enter the correct date would have been a barrier to adoption. Defaulting to today removes friction for the most common case, while allowing past-date entry accommodates coaches who log in batches. Future logging was intentionally blocked to prevent premature billing records — except when tied to a confirmed scheduled message.
Initially explored more flexible editing. Once we understood that notes are immediately sent to Elation as billing artifacts — readable by data teams and eventually by insurance — editing dates, types, or notes posed serious data integrity risk. Reduced to time-duration only, with a manager-intervention path for everything else.
Originally designed on-call notes to be freely editable in the weekly plan. Clinical leadership raised that edits not syncing back to Elation create two conflicting records — a clinical and billing liability. Resolution: minimal structured note to Elation for billing; weekly plan remains the coach-facing record with intentionally separated purposes.
Identified an unaddressed moment in the coach workflow: scheduling a delayed message is the exact moment context is freshest. Took initiative to research patterns from other tools, then designed a flow where coaches can opt into logging at scheduling time. The note only generates on confirmed send — cancelled or failed messages produce no record.
A compelling use case surfaced late: coaches who do daily check-ins want to log a full week at once. Explored a multi-day entry UI where selecting multiple days generates a note per day. Kept MVP simple and scalable — this was documented with clear design direction for a future sprint, not abandoned.
The $100K is the headline. But the more meaningful shift was what happened when you removed 2 hours of frustrating administrative work from a coach's week. Coaches weren't just saving time — they were recovering capacity. Time consumed by navigating calendars, reconstructing interactions from memory, and entering the same information into multiple systems went back to patients. Coaches could take on more patients. The work they were hired to do became more of their day, not less.
The 100% log rate matters beyond the number itself. Before, coaches who bulk-logged at week's end were doing their best — but memory is imperfect across 20 patients and dozens of interactions. Logs were missed. Time estimates were rough. Insurance submissions reflected an incomplete picture of the care actually delivered. After, logging happened in context, when the interaction was fresh. The record became accurate. InStride stopped leaving money on the table for care it had already provided.
Although net-new, this feature was designed to be scalable from day one — kept MVP and simple so it could grow with the team. By automating visit note generation and passing coaching type data into the weekly plan, we also removed a second manual step coaches previously completed separately. Coach touchpoints now appear in the shared clinical record automatically, making coach work visible to the broader clinical team — therapists, psychologists — without any additional effort. We also drew on and repurposed the automated note generation pattern from a prior project, reducing engineering lift and keeping the project on its four-week timeline.
The clearest signal that the design had done its job didn't come from a metrics dashboard. It came within days of launch — unprompted, from coaches who sought out the team specifically to share their response.
The scheduled message logging flow — a workflow I identified, researched independently, and drove from concept to launch — was called out by name in post-launch feedback. Combined with a 100% logging rate within the first week, it signaled that we had solved the right problem in a way that fit naturally into coaches' existing workflows.
Treating edge cases and open questions as deliverables reduced engineering surprises. The scheduled message feature — called out by users as the standout — came from questioning outside the original brief and doing independent research to back it up.
The Weekly Plan feature came from asking "where does this need to live for the whole clinical team?" In billing-adjacent systems, the right question is always: who else is affected, and what are the downstream consequences? The UI is the easy part.
Behavioral questions — logging cadence, batch preferences — were answered through design reviews rather than direct coach research. Earlier interviews would have surfaced the bulk log use case for MVP. One upfront rule — any action generating a billing artifact is locked post-submit — would have resolved the editing debate in one conversation.
The dummy note resolution came from engineering. I contributed by understanding the problem clearly enough to recognize a good answer when it came from somewhere else — and letting go of a direction I'd been attached to. The coaching leadership review was the single most valuable session. I'd schedule it earlier every time.
OTHER SELECTED WORKS
Case studies across patient experience, provider tooling, and operational systems — where design decisions carry real weight.
