Celebrating Life Community Health Center
Turning a fragmented call-center workflow into one live, trusted system
Healthcare Enterprise
Data Management
Deployed 2026
Role
Lead Product Designer
Timeline
Nov 2025 - Jun 2026
Team
4 Designers, 13 Developers, 2 Tech Leads
Overview
The Client
Celebrating Life Community Health Center is a nonprofit clinic network in Orange County that serves patients regardless of their ability to pay. Four locations, one call center.
The Task
Every morning, the call center manager set appointment targets for each provider. The targets lived in a document, progress lived in people's heads, and updates happened in group chat. Nobody could answer a simple question: are we on track today? Our job was to build one live system for setting targets, tracking progress, and coordinating across all four clinics.
My Impact
Across thirteen sprints and four modules, I owned the User Directory and the permission system behind it: who can approve access, change roles, delete users, and transfer ownership, and what the product should refuse to let anyone do. The dashboard showed the work. The permissions decided whether people could trust it.
Research
First, I challenged whether we should build anything at all.
Before opening Figma, I wanted to know if this product needed to exist. CLC already paid for Veradigm, and Salesforce was on the table. Custom software only made sense if neither could solve the problem.
So I mapped CLC's requirements against both. Each could track activity. Neither could track performance against a daily goal.
CLC did not need another system for recording what happened. They needed a system that could tell them whether what happened was enough.
Insights
Both tools could record activity. Neither could tell you if it was enough.
Veradigm showed appointments and schedules, but had no concept of a daily quota and no view across clinics. Salesforce tracked cases and agent activity, not provider progress. That gap became our product thesis, and our reason to build.
Define
I made permissions visible through product structure.
I mapped four roles. Master owns the permission hierarchy. Call Center Managers run users and workflows. Call Center Staff handle daily quota work. Viewers are leadership who need visibility without editing.
Instead of designing one information architecture and layering permissions on top, I mapped the product separately for each role. The structures turned out meaningfully different. Masters and managers needed tools staff never touched. Viewers could look but not act.
Key Decisions
Key Decision 01 / Navigation
Role-shaped navigation is calmer but, It also hides the ceiling.
Users shouldn't constantly see controls they can't use. A staff member on their fortieth call doesn't need disabled manager buttons and explanations of why. So each role sees only the product relevant to their job. The tradeoff: when someone gets promoted, parts of the interface appear for the first time. But promotions are rare and daily use is constant. I designed for what happens hundreds of times, not once.
Key Decision 02 / Quota Tracking
The final version made the right information easier to act on
As the workflow became clearer, I simplified the dashboard around the manager's core job: see progress, identify who needs attention, and update quotas without second-guessing the interface.
Key Decision 03 / Provider Management
The Provider Directory became infrastructure for the rest of the product.
Providers weren't just names in a table. Their clinic, category, status' and permissions affected quota calculations and downstream workflows.
Key Decision 04
I used friction proportionally to the cost of being wrong.
The quota dashboard shows provider targets, real-time progress, and clinic context in one place. I designed editable targgets, clear progress indicators and role-aware controls.
animated gif
Key Decision 04 / Succession
Managers needed to understand the whole day without reassembling it themselves.
The quota dashboard shows provider targets, real-time progress, and clinic context in one place. I designed editable targgets, clear progress indicators and role-aware controls.
animated gif
Key Decision 05
Most of the User Directory was designed around what users shouldn't be allowed to do.
The quota dashboard shows provider targets, real-time progress, and clinic context in one place. I designed editable targgets, clear progress indicators and role-aware controls.
animated gif
Key Decision 06
Audit history needed to create accountability without becoming surveillance.
The quota dashboard shows provider targets, real-time progress, and clinic context in one place. I designed editable targgets, clear progress indicators and role-aware controls.
animated gif
Ideate
Much of the design work was deciding where friction belonged.
In usability testing, the biggest wins were small. People missed our Add New controls. Language tags looked decorative. Inline edits didn't show what was editable or whether it saved. A confusing bottom nav gave way to a simple top bar. But one lesson kept coming back: friction is a limited resource. I wanted confirmations only where mistakes were expensive.
Fig. 07 / Early build vs. final. Bottom nav out, top bar in, editable fields made obvious.
Fig. 08 / Quota management flow. Six confirmations collapsed into one review screen.
Key Decision 04 / Confirmation
One thoughtful confirmation is safer than six meaningless ones.
Our early quota editor asked users to confirm every change. Edit, confirm. Edit, confirm. Technically safer, but after enough dialogs, people stop reading. So I consolidated it into one review screen showing old versus new values, with a single confirm or discard. Someone could still skim it, but one meaningful review earns more attention than six interruptions. The goal wasn't more safeguards. It was effective ones.
Fig. 09 / Provider and category management. Deleting a category touches every provider.
Key Decision 05 / Destructive Actions
Destructive actions received a different standard.
I usually prefer undo over confirmation. But deleting a directory category removes that field from every provider record. A five-second undo toast isn't real recovery when you can't see everything you just affected. So cascading deletes get a deliberate confirmation, and everything else stays out of the way. The rule wasn't "always confirm." It was "understand the blast radius first."
Fig. 10 / User Directory flow. Most of the diagram is the system saying no.
Key Decision 06 / Refusal
I spent just as much time designing what the system should refuse.
The User Directory was less about what managers could do and more about what they couldn't. New users sign in with a CLC Google account and land in a pending queue. Once approved, they start as Viewer, the lowest access, so a requested role never becomes an approved one by default. Denials are quick: confirm, notify, and jump straight to the next request. The hardest rules were the simplest. Managers can't demote or delete peer managers. The Master can't delete itself, and instead of a warning, I removed the option entirely. The safest error state is one users can never enter.
Key Decision 07 / Feedback
Even a Save button became part of the trust model.
Save stays disabled until something actually changes. An active button tells users there's something worth saving. If it's always active, its state stops meaning anything. It's a tiny detail, but trust in software is built from hundreds of them.
Fig. 11 / Version log. Framed around the quota, not the person.
Key Decision 08 / Accountability
Accountability introduced an ethical product question.
Every quota change records who made it and when, so managers can trace a number that looks wrong. But that same log could easily become surveillance of hourly staff. So I framed it around the quota, not the person. It answers "what happened to this number?" instead of "what did this employee do today?" Information architecture decides which questions a product makes easy to ask, and those questions shape how it gets used.
Solution
The final platform included five major areas: Quota Tracking, Provider Directory, User Directory, Version Log, and Settings.
Quota Tracking
The whole day on one screen
Providers, locations, hours, targets, and live progress in one view. Targets are calculated from provider hours but stay editable, because if managers can't override a number they know is wrong, they start working around the system. Staff log progress freely. Exceeding a target takes manager permission.
User Directory
Mostly a study in the word no
The User Directory followed the same philosophy. The happy path was intentionally simple: open a user, change their role, save. Most of the complexity lived behind the scenes in the rules protecting that flow, the refusals covered in Key Decision 06.
Master Role Transfer
Friction, on purpose
To transfer ownership, the Master picks a successor, types TRANSFER, re-authenticates through Google SSO, and decides what happens to their own account. Removing it means typing DELETE. It's slow on purpose. Changing a setting should be easy. Handing over control of a clinic network shouldn't be. Friction should match the cost of being wrong.
Fig. 12 / 29 numbered dev annotations, expanding inline with endpoints, edge cases and permission matrices.
I treated developer handoff as part of the product.
With thirteen developers, a polished Figma file wasn't enough. Permissions are mostly invisible in a static screen. A disabled button doesn't say who disabled it, when it unlocks, or what happens if the API fails mid-transfer. So I wrote 29 numbered annotations directly in the prototype covering APIs, validation, permissions, edge cases, and rollback, six for Master Transfer alone. What users experience depends as much on the handoff as on the mockup.
Impact
The platform shipped to production and replaced a fragmented workflow.
CLC now has one live view across four clinics, with access built around four clear roles. Targets are set once, progress is visible all day, and every change is accountable. For the first time, they can see not just what happened, but whether they're on track.
4 clinics
on one live view, where before there was no view across locations at all
4 roles
with access enforced in the architecture rather than in disabled buttons
13 sprints
across 4 modules, delivered with 29 developer annotations for a team of 13
Reflection
The design decision I remember most is still the simplest one.
If I did it again, I'd test the access-denial flow with real managers. It was designed from reasoning about how a queue should behave, not from watching someone clear one. I'd also surface the JSONB tradeoff to the broader team earlier, especially what gets harder to filter and report on.
But the decision I keep coming back to is the Master that can't delete itself. No modal. No red warning. The option just doesn't exist. After months of flows, roles, APIs, and annotations, one of the most protective decisions I made is one no user will ever notice.
That changed how I define good design. It's not just polishing the happy path. It's knowing when to make something easy, when to slow someone down, and when to make the wrong action impossible.
I'm glad we crossed paths. I hope it left you inspired!
© Jerry Nguyen 2026