Project Overview
Industry: GovTech / Health Services
Project Type: Salesforce Design
Role: Lead Designer
Program: Quality Innovation Network–Quality Improvement Organization (QIN-QIO)
Platform: Salesforce Service Cloud + Experience Cloud
Outcome: Onboarding time reduced from 9 hours to 3; emergency QA turnaround down 40%; 90% adoption
Project Summary
From nine hours to three. That’s the sentence I wanted every QIN-QIO leader at CMS to say when they described our new Salesforce case management platform. It wasn’t just a metric—it was the proof that design and architecture could turn a fragmented, high-stakes process into a coherent service built on guardrails, velocity, and trust.
Before our redesign, onboarding a single QA case could take over nine hours. Intake happened across emails, SharePoint folders, spreadsheets, google documents, and system lookups, with critical steps lost in rework and missing documentation. Our mission was clear: cut onboarding time without compromising compliance or accessibility.
The Challenge
Before redesign, the QIN-QIO case management process was a maze—a tangle of emails, spreadsheets, shared drives, and disconnected systems that required constant manual effort to keep cases moving. Each participant—nurses, QA leads, provider office managers, and CMS reviewers—worked from their own truth, not a shared one.
The result was delay, rework, and risk in a process where accuracy and timeliness literally impact patient care.
What We Found
No single source of truth: Case data lived across Outlook threads, SharePoint folders, and personal spreadsheets.
High cognitive load: Staff had to memorize dozens of exceptions and local workarounds.
Rework loops: Missing documentation or mismatched identifiers could stall a case for days.
Inconsistent developer outputs: UI layouts and interaction patterns varied by team, hurting usability and compliance.
Compliance fragility: Accessibility (508/WCAG), PHI protection, and audit trails were handled inconsistently across regions.
The problem wasn’t people—it was the system.
Each team had smart, dedicated professionals trying to do quality work inside an unstructured, fragmented environment that worked against them.
Baseline Reality
| Category | Starting Point |
|---|---|
| Onboarding a QA case | 9+ hours |
| Emergency QA turnaround | Frequent delays, unclear documentation |
| Developer throughput | Inconsistent, designer-dependent |
| Compliance | Mandatory: 508/WCAG 2.1 AA, PHI handling, auditability |
We weren’t starting from zero—we were starting from chaos. The challenge wasn’t just to make the process faster, but to make it trustworthy, repeatable, and resilient without sacrificing compliance.
Give the Work a Single Spine
Every successful transformation starts with clarity.
Before we could streamline or automate anything, we had to see the work for what it really was—not the way teams described it in theory, but how it actually unfolded across inboxes, folders, and hands.
The old process had no spine. Every team had its own shortcuts, naming conventions, and handoffs. Work flowed by habit, not by design.
To fix it, we didn’t start with wireframes or screens—we started with service design, building the skeleton that every future workflow would share.
Our goal was simple: make the process visible, governable, and fair.
Discovery and Mapping
We grounded the redesign in evidence, not assumptions.
Conducted cross-regional interviews and shadowing sessions across five QIO regions to capture true operational variance.
Audited existing workflows, templates, and intake artifacts to identify duplication and breakpoints.
Mapped a complete case lifecycle blueprint, from first contact to closure:
Intake
Validation
Assignment & Review
Documentation
CMS Submission
Close & Report
Each stage documented the people, systems, SLAs, and moments where automation could amplify human effort instead of replacing it.
Design Doctrine
Our guiding principle was simple but powerful: Automate presence, preserve judgment.
That meant we would use automation to remove friction, not remove people. The goal wasn’t to replace human expertise—it was to make sure human time was spent on thinking, not searching.
Salesforce made this possible because its architecture naturally bridges automation and human workflow. With Flow Builder, Omni-Channel routing, and data relationships built into the platform, we could let the system do the mechanical work—validating, flagging, routing—while keeping the moments of interpretation and decision squarely in human hands.
Automation handled what Salesforce does best:
Provider Verification: Real-time lookups through Flow and API integration ensured clean data before submission.
Duplicate Detection: Salesforce record-matching logic surfaced potential conflicts automatically.
Completeness Scoring: Declarative flows validated document requirements before a case could move forward.
These tasks ran invisibly in the background, keeping data accurate and compliance tight without adding cognitive load for users.
Humans focused on what only they can do:
Applying clinical reasoning and contextual judgment
Managing escalations, exceptions, and edge cases
Making final determinations that required nuance or expertise
This balance worked because Salesforce let us encode process intelligence directly into the workflow itself—every automation was transparent, traceable, and explainable. Users didn’t have to wonder why something was flagged or routed; the system told them.
That clarity built trust. Automation gave consistency and speed. Human oversight preserved meaning and accountability. Together, they became the north star that guided every design, development, and policy decision that followed.
Outcome Targets
To stay outcome-driven, we defined measurable success upfront:
Onboarding time: A measurable and significant reduction from the 9 hour mark.
Emergency QA turnaround: Meaningful reduction
Documentation errors: Goal of 30% reduction
Developer velocity: Consistent and repeatable
Accessibility: WCAG 2.1 AA compliance from day one
Build the Rails Before the Trains
Once we had the service blueprint, the next challenge was consistency. Teams were moving fast, but without shared design rules, every new feature risked creating another fork in the system. We needed to scale both speed and quality—without making design a bottleneck.
So before a single screen was built, we focused on the infrastructure of experience: patterns, governance, and enablement. The goal was to let developers ship confidently and designers focus where they added the most value.
What We Built
No-Designer Zones: Pre-approved SLDS templates for pages, lists, and forms that anyone could safely deploy.
Figma–LWC Wireframe Kit: A 1:1 mapped design system with responsive redlines, error states, and accessibility baked in.
Decision Matrix: A clear framework for when to use declarative Flow, custom LWC, or Apex for performance. – View Matrix
Governance Cadence: Pattern registry, change control, and accessibility QA embedded into sprint reviews.
What Changed
Developers no longer asked “Which layout should I use?”—they had trusted rails to build on.
Designers could finally spend time on high-density, high-risk interfaces, not routine screens.
Accessibility and consistency became defaults, not debates.
Measured Results
Developer cycle time: +35% faster
Redundant UI builds: −40%
Handoff errors: −60%
The Nine-Hour Dragon: Onboarding Wizard
Onboarding was the monster at the center of the maze—the process everyone feared, tolerated, and tiptoed around. It was the perfect place to prove that structured design on a structured platform could transform outcomes.
Our challenge: take a nine-hour ordeal and turn it into a guided, intelligent experience that never asked users to think about the system—only about their work.
Salesforce was the perfect foundation for this transformation because it gave us a single, configurable platform that combined process automation, data integrity, and human-centered design in one place. We could orchestrate complex, multi-step workflows declaratively while maintaining visibility, auditability, and compliance — all native to the platform.
Why Salesforce Was Perfect for This
Declarative power for complexity:
Flow Builder let us design dynamic, condition-driven onboarding steps without hardcoding logic. We could build adaptive paths that changed based on case type, provider, or severity, using clicks—not code—so changes could happen inside sprint cycles instead of release cycles.Real-time intelligence baked in:
Salesforce’s data layer and external service integrations (like provider lookups) gave us live validation without leaving the system. Record-triggered Flows ensured duplicate detection and completeness scoring occurred instantly and consistently across users.Guided UX through Experience Cloud:
With Salesforce screen flows and Omni-Channel routing, we delivered a single guided experience for nurses, QA leads, and CMS reviewers. The platform’s component-based design meant the same logic could serve both internal users and portal users, creating a seamless front-to-back experience.Embedded trust and compliance:
Field Audit Trail, Shield encryption, and platform-level PHI handling allowed us to build with confidence. Every field change, every action, and every decision was logged automatically—no custom logging layer required.Governed consistency at scale:
Because we paired Flows with our Salesforce Design Framework, developers and admins could work from approved templates, ensuring that every new automation adhered to accessibility, usability, and compliance standards.
Key Improvements
Dynamic Conditional Steps:
Flow Builder logic adjusted in real time by case type, severity, and provider status.Real-Time Validation:
Automated NPPES lookups, duplicate detection, and document completeness scoring executed within the same flow.Required Document Matrix:
Context-aware guidance used Salesforce screen components with rich text and inline examples tailored by case data.Smart Routing:
Omni-Channel triggered SLAs on “Validated” instead of “Created,” ensuring metrics reflected real progress.Auditability:
Field Audit Trail and event logs automatically captured “why this was routed this way,” creating defensible audit evidence for CMS oversight.
Trade-Offs
We intentionally favored declarative flows over complex code to maintain transparency, agility, and compliance alignment. Even though we could have optimized a few milliseconds with custom Apex or LWC logic, the declarative approach kept ownership within the team—no developer gatekeeping, no black boxes.
External API calls were staged asynchronously to preserve performance and user responsiveness, taking advantage of Salesforce’s event-driven architecture.
Pilot Results
Onboarding time: 9h → 3h (−67%)
Post-intake rework: −30%
User satisfaction: +0.8 CSAT gain
Why It Worked
Salesforce gave us a human-centered platform that speaks the language of service design—structured data, configurable logic, and visibility at every touchpoint. We didn’t have to bolt on technology to make this work; we just had to use the platform the way it was meant to be used:
Declarative when possible,
Transparent by default,
Governed at scale.
The result was more than just faster onboarding—it was a new way of working, built directly into the backbone of the system.
Urgency Without Confusion: Emergency QA
If onboarding was our marathon, Emergency QA was the sprint. These were the cases where every minute mattered—and where stress made clarity even more critical.
The challenge wasn’t just speed; it was orchestration under pressure. In emergencies, users don’t need more features—they need fewer clicks, fewer doubts, and a workflow that feels like it’s thinking ahead for them.
Salesforce was the perfect foundation for this because it let us combine automation, routing, and real-time visibility in one place—turning a chaotic process into a guided, predictable experience.
Why Salesforce Was Perfect for This
Dynamic case logic through Flow Builder:
Emergency QA leveraged record-triggered and screen flows that adapted instantly to the selected severity. Each severity level dynamically revealed the right fields, upload requirements, and SLAs—no branching code, just declarative configuration that product owners could evolve safely over time.Event-driven routing with Omni-Channel:
Salesforce’s Omni-Channel routing ensured that urgent cases were automatically escalated and assigned based on severity, skill, and workload. The routing logic wasn’t abstract—it was visible and auditable, aligning SLA timers with “Validated” status instead of “Created” for accuracy.Transparent collaboration through Experience Cloud:
The provider-facing portal (built in Experience Cloud) reflected the same data model and logic used internally, meaning every participant saw the same truth. Providers could upload required files and immediately track progress, removing the “Did you get my file?” loop entirely.Real-time validation via Salesforce components:
Uploads used file components within Flow combined with Apex-powered validation for type, size, and duplicate detection. This ensured nothing slipped through the cracks, while maintaining the simplicity of a single-page guided flow.Telemetry and insight via CRM Analytics:
All interaction data—submission timing, retries, escalations—fed into CRM Analytics dashboards. This gave CMS leads real-time visibility into bottlenecks and compliance status, making operational tuning continuous instead of reactive.
Design Goals
Keep users focused under pressure
Let severity drive both workflow and expectations
Ensure transparent communication between all participants
Deliver real-time validation and SLA accuracy through automation
Key Features
Severity-Driven Pathing:
Selecting a severity instantly shaped the workflow—requirements, uploads, and deadlines were generated dynamically through Flow Builder.Docs Needed Now Panel:
Conditional upload panels displayed only what was required for that severity level, with inline examples and built-in validation for size, type, and duplicates.Pre-Submit Checks:
A declarative Flow summary screen provided a plain-language review of missing items, why they mattered, and what would happen next.Provider Progress Tracker:
Experience Cloud dashboards mirrored Omni-Channel status and SLA timers, giving both providers and CMS staff one shared source of truth.SLA-Aware Orchestration:
Omni-Channel routing automatically adjusted timers, escalations, and notifications based on case severity, ensuring accountability without manual tracking.
Measured Results
Emergency QA turnaround: −40%
Documentation errors (first pass): −25%
Escalations for unclear instructions: Significantly reduced
Why It Worked
Salesforce gave us a platform where urgency didn’t mean chaos.Its declarative tools let us automate confidently, its data model kept context visible to everyone, and its orchestration features ensured the right person always saw the right case at the right time.
In short, Salesforce didn’t just power Emergency QA—it made it predictable, transparent, and humane under pressure.
The Invisible Architecture
Great experiences don’t last without solid architecture. Behind every interaction sat a federally compliant, performance-tuned Salesforce ecosystem—engineered to protect data, support growth, and make governance effortless.
We designed not just for now, but for ten years of sustainability across programs and partners.
Technology Stack
Service Cloud: Core casework and workflows
Experience Cloud: Provider collaboration portal
Flow Builder: Guided automation and logic
Lightning Web Components: Rich, modular front-end interactions
Omni-Channel: Skill-based routing and SLA timers
Shield & Field Audit Trail: PHI protection and complete traceability
CRM Analytics: Data visibility and performance telemetry
Data Model
CQP as the single source of truth
Linked to Provider, Facility, Care Episode, Document Package, and SLA Milestones
Every record traceable; no orphaned data
Security & Accessibility
Encrypted in transit and at rest
Principle of least privilege
Keyboard-first workflows
Accessibility defects treated as functional blockers, not “nice-to-haves”
Leading the Change
Technology only matters if people believe in it. Our final act was about adoption, enablement, and trust—building a culture around the new system so it wouldn’t just be used, but embraced.
I led a cross-functional team of eight—designers, admins, and developers—working directly with CMS product owners and QIN-QIO subject matter experts. Together, we built not just software, but confidence.
How We Led
Blended DesignOps and DevOps for continuous feedback and improvement.
Integrated pattern governance and accessibility QA into the sprint rhythm.
Ran weekly demos and KPI reviews tied to adoption, velocity, and satisfaction.
Driving Adoption
Created role-based training with in-product “See an Example” guidance.
Held open office hours for real-time support and feedback loops.
Used dashboards to identify drop-offs and tune flows in real time.
Results
Active usage: 90% adoption within Phase I
Developer efficiency: +35%
Redundant UI builds: −40%
Handoff errors: −60%
Accessibility: 0 critical AA defects at launch
Real-World Impact
This wasn’t just a technical win—it changed how people worked.
QIO Usersbegan their day with SLA dashboards instead of inboxes.
Providers finally knew what to upload, when, and why.
QA leads could rebalance workloads with real-time insight and confidence.
The platform gave everyone context, clarity, and control—the foundation of quality work and trust.
By the Numbers
| Metric | Outcome |
|---|---|
| Onboarding time | 9h → 3h (−67%) |
| Emergency QA turnaround | −40% |
| Documentation errors | −25% |
| Developer efficiency | +35% |
| Redundant UI builds | −40% |
| Handoff errors | −60% |
| Adoption | 90% active usage |
What I’d Do Again — and What I’d Do Next
Do Again
Lead with service design before UI
Invest in No-Designer Zones to scale speed without sacrificing quality
Wire reportinginto every workflow from day one
Do Next
Implement AI-assisted triage to predict severity and documentation needs
Use document intelligence (OCR + entity extraction) to prefill evidence checklists
Extend the blueprint across CMS programs for portfolio-level consistency
What I Wouldn’t Do Next Time
Even successful systems reveal their friction points once they meet reality. While our Emergency QA redesign delivered measurable impact, a few decisions created hidden complexity that I’d handle differently in the next iteration.
1. Relying too heavily on conditional logic in a single Flow
The Flow that powered Emergency QA became massive—dozens of branches, conditions, and screen rules.
It worked, but it made change management slower for admins unfamiliar with the model.
Next time, I’d modularize Flows into smaller, callable sub-flows to isolate logic and make updates safer and more transparent.
2. Overemphasizing transparency at the expense of brevity
We surfaced a lot of real-time feedback: validation messages, SLA timers, audit details.
For some users under stress, the volume of visible data was more distracting than helpful.
Next time, I’d streamline the interface further—show only the next required action, not every system message.
3. Assuming declarative = simple
Declarative tools like Flow Builder are powerful, but with nested logic they can become as complex as code.
Next time, I’d pair declarative design with stricter design governance—naming conventions, versioning, and a short architectural review for each Flow change.
4. Underestimating asynchronous delays
We staged external callouts (like identity and provider verification) to keep the UI responsive, but some users still felt lag when retrieving results.
Next time, I’d use Platform Events or Asynchronous Apex more aggressively to decouple long-running tasks and improve perceived performance.
5. Leaving documentation too implicit
Teams learned the system intuitively during build, but later onboarding new staff took longer than expected.
Next time, I’d create a living “Flow Catalog” in Confluence, documenting logic decisions, ownership, and version history for each automated process.