Case Study 1 - platform redesign

Rebuilding the Core: Modernizing the Therasoft Therapy Platform

A legacy EHR used by thousands of mental health practices had a problem that appeared visual but wasn't. As the sole product designer, I led a phased redesign that kept a live product running while rebuilding it underneath.

Role

Senior Product Designer, Sole Designer

Tools

Figma, Claude AI, Telerik/Kendo

Timeline

6 months

Team & Context

Sole designer, working directly with the company owner and an offshore engineering team. No design org, research function, or design system to inherit. I built those functions as the work required them.

What I owned

User Research,interaction Design, Design System, Prototyping, Dev Handoff, QA

5x

Beta practice adoption in six months.

1

Designer - research, UI, design system, and QA

2

Live product versions supported during transition

The Problem

Customers were calling it outdated. The real issue ran deeper.

Therasoft had become the most feature-complete platform in its category — but every feature had been built without a shared design system, by whoever was available at the time. Reviews consistently mentioned the same two things: the software looked old, and new users needed a support call just to get started.

The owner's framing going in was simple: it looks old, fix the look. Research with clinicians, admins, and the support team told a different story — this wasn't a visual problem. It was a usability and accessibility problem wearing a visual complaint as its symptom.

Live Product

A live product, in active daily use by thousands of practices, that couldn't go down for a rebuild. Every change had to ship without breaking someone's workday.

No Design System

No existing design system. Components had been hand-coded inconsistently across the product, with no documentation of what existed or why.

Two User Bases

Two incompatible user bases: power users with years of muscle memory who feared change, and new users who couldn't find their footing at all.

Offshore + Tech Pivot

An offshore development team with a language and tooling gap — and a mid-project pivot from Blazor to ASP.NET that invalidated the original handoff plan.

The Approach

Find the real problem first, then protect the people already using it

I separated the stated complaint from the underlying one — mining reviews, auditing competitors, and walking the product cold as a new user before any stakeholder framing set the direction. That reframed the brief from "make it look modern" to "make it usable for newcomers without breaking it for the people who'd relied on it for years."

From there the work ran on two tracks: cut page-level noise before touching any single component, and check every change against user mindsets built to represent both the legacy power users and the newcomers. The calendar below is the clearest example of how that played out — the same logic drove the intake redesign and the design system underneath, both covered in the process sections.

The Work- Clinical Calendar

Appointment length became the information hierarchy

Of the surfaces I redesigned, the calendar concentrated the most complaints and shows the method most clearly. Buttons were scattered, every appointment card tried to show everything at once, and the most-scanned piece of information — the client's name — was buried third in the visual hierarchy, after time and a cluster of action buttons.

The real design tension wasn't visual, it was between two user mindsets I'd mapped. Experienced users, many with ten-plus years in the legacy product, valued efficiency and familiarity above all, and when the beta shipped they had one non-negotiable demand: "I can't see the full day." They wanted everything visible at once. Newer users pulled the other way: several who wore glasses or contacts told me condensed cards forced them to zoom in to read anything. Showing the full day meant denser cards; denser cards hurt legibility. I couldn't fully satisfy both with a single card.

Appointment length became the way through. Instead of every card carrying the same load, what a card showed scaled with how long the appointment was — a 15-minute check-in and a 45-minute session aren't the same information problem. That preserved the full-day visibility legacy users demanded while keeping the most critical information legible against the accessibility standards the original calendar failed. The tradeoff was deliberate and named, not stumbled into: less detail on the shortest cards, in exchange for a full day that everyone could still scan.

Before
After
The legacy image of Therasoft's calendar

Original card: time and task buttons dominate; client name appears third in scan order, low contrast on red/green states.

The modern and updated version for the calendar

Redesigned card: name promoted to dominant element, three-tier hierarchy by appointment length (15 / 30 / 45+ min), interaction changed from hover to click to stop accidental triggers.

"It used to take me 5 minutes to create an appointment because I'd get distracted and easily click off the window."

- Therasoft customer, on the friction the redesign removed

The Rollout

A beta that worked exactly as intended, by surfacing what I'd missed

Rather than a hard cutover, the release went out as a beta to the platform's largest practices first. The beta caught something no amount of upfront research had: customers quietly reverting to the old version because the new calendar lost full-week visibility on one screen. Density wasn't clutter to a therapist managing a packed week — it was information.

I rebuilt the appointment cards into a compact layout that held up even in tight spaces, re-released to the general user base, and ran both versions in parallel until the legacy product could be sunset.

Process - Go Deeper

The decisions behind the outcome

The sections below hold the fuller story — the research methods, the roadblocks, and the reasoning behind each call. Open whichever ones are relevant to what you want to see.

01

Finding the real problem before designing anything

Reviews, competitive analysis, and walking the software cold

Before opening Figma, I read every review I could find and audited four competitors in the therapy practice-management space: SimplePractice, TherapyNotes, TheraNest, and Therasoft itself. SimplePractice had the most modern interface but sacrificed feature depth; TherapyNotes and TheraNest had real depth but carried significant navigational debt. The pattern across all four: nobody had combined clinical depth with a modern, approachable experience. That became the core design opportunity.

Then I walked the software myself, cold, the way a new user would. The first thing I hit was a "dashboard" window that opened automatically on login with no clear next step — and closing it didn't reduce the noise, because the calendar underneath was just as dense. There was no onboarding of any kind. I logged that as a pattern to watch for, not a one-off complaint.

Method: review mining → competitive teardown → cold walkthrough as a new user, before any stakeholder framing entered the process.

02

Building user mindsets so I didn't redesign people of of their own software

Legacy vs. modern users, power vs. casual, across three practice types

The support team had tried moving a single button once before. A power user's response: "you moved a button and I don't know where to look now." That was a real signal about the cost of change for an established user base, not a one-off complaint to dismiss.

I interviewed solo practices, group practices, and admins, then built mindsets across two axes: legacy users vs. modern users, and power users vs. casual users, within each practice type. Every design decision afterward got checked against these — not as a formality, but as the actual mechanism for not breaking things for the people who'd been relying on this software for years.

03

No design system existed, and the dev pivot that forced one into being

Telerik/Kendo, a Blazor-to-.NET pivot, and building a system from inside a constraint

Opening the existing Figma file, I found no design system — multiple different UI approaches used inconsistently, with no documentation. The owner had been using Telerik/Kendo components, but the offshore development team struggled to implement them directly and had been hand-coding everything, checking it visually against the design rather than reusing components.

A month into handoff, almost nothing had shipped. The root cause: the team wasn't reusing components because nothing was built for reuse. My boss made the call to pivot the build from Blazor to ASP.NET — which meant the component library I'd been using couldn't export as .NET code at all. I built a design system inside Figma from scratch and converted it into functional .NET code myself, leaning on the HTML/CSS fundamentals from my design program to close a gap I hadn't expected to own.

Outcome: a working, documented Figma design system with .NET-ready code underneath each component — built reactively, mid-project, inside a hard technical constraint.

04

"This doesn't make the process any quicker" — taking feedback literally

The client-intake redesign that needed a second version

My first pass at the new-client intake flow cleaned up visual hierarchy and modernized the look — and customers told me directly it didn't make the process any faster. I'd designed for the wrong variable: speed was the constraint, not visual cleanliness.

I rebuilt it as a three-step progressive disclosure flow within the week and retested. The response was clearly better — except for one legacy power user who preferred everything on a single screen. One voice out of five isn't a majority, but it represents a type of user, not just an individual, so I didn't dismiss it. I explained the accessibility reasoning (the old single long form failed WCAG text-size guidance) and logged the tension as something to watch, rather than overriding it silently.
"He explained the research behind the current changes, then offered a way to solve my particular issue — a button to copy a previous code that we could edit. It was the perfect solution for everyone."

- Cassandra — Therasoft Customer

05

Working across a language and time-zone gap with the dev team

India-based offshore developers, and finding a working rhythm through trial and error

The development team was based in India, fairly fluent in English but with enough of a communication gap that it took several meetings to understand how they talked about the product and what they needed from a handoff. There were real misfires — feedback that I thought was clear led to rework because a core piece hadn't actually landed.

The fix wasn't a single tool, it was iteration: annotated Figma files, more direct calls on complex interactions, and eventually finding the cadence that worked for both sides. Telerik's ThemeBuilder helped once it was in place — it let the dev team see component behavior directly instead of waiting on me to prototype everything, which sped up high-fidelity handoff meaningfully for a solo designer.

06

What I'd do differently

Two calls I'd revisit

Two things. First, I'd have pushed harder for more dramatic change to the data tables — even redesigned, they retained clutter, and I still believe they should have been cards that adapted dynamically to whoever was using the product. Given the codebase constraints, that fight would have cost more time and resources than we had, so I let it go. I still think the instinct was right.

Second, the table filters. Research said the All/Inactive/Active radio buttons should become a dropdown — enough users were mis-clicking them. But another set of users flipped between those filters constantly, and I spent too long weighing those two groups against each other before realizing I'd been designing for two or three user types and had forgotten Admins as a group entirely. I wanted to go back and fix that properly. Then 6.0 started.

Outcome

Two different user bases, two different kinds of success

Newer and younger users were immediately happier — the breathing room and grouped information made the product make sense in a way the old wall of buttons never did. Legacy users needed something different: not less density, but a way to reconstruct their own version of "everything visible," which we built as collapsible tabs that could stay open.

The pattern that held throughout: every time a user complained, the team checked with them to find the real issue — and the real issue was usually training, not design. A library of training videos and a properly designed onboarding flow grew directly out of that finding. Five months after the beta launched, practice adoption had grown 5× — from 15 practices to around 70 — and the redesign moved toward general release as I transitioned off the project.

The lasting lesson was sharper than the redesign: keep the list of who you're designing for explicit and complete. The one time I let it blur, I lost track of an entire user group — admins — until late in the process. I design with that map in front of me now.

Back to PortfolioNext Case Study: AI Agent Framework →
Case Studies
The Legacy ProblemDesigning Trust FirstPatient Portal Clarity
Contact Me
Email MeLinkedIn