Healthcare / Enterprise UX
Rebuilding Self-Service Trust in a Healthcare Records Portal
A fragmented legacy portal pushed over a thousand callers a day onto the phone line. Splitting it into a no-login status tracker and a full request portal cut IVR call volume by 25% in the first month.
IVR call volume one month after launch
daily lookups on the new no-login tracker
online request creation, adopted by users
delinquency impact, awaiting a full billing cycle of data
One month after launch
| Client | An enterprise healthcare services provider (name withheld) |
|---|---|
| Role | Senior / Lead UX Designer, supported by one Junior Designer |
| Scope | Two connected products: a no-login status tracker and a full authenticated request portal |
| Timeline | 90-day end-to-end build |
| Tools | Claude Code (HTML prototyping), Figma, AI-assisted ideation |
| Core impact | 25% lower IVR call volume one month after launch; 300 to 500 daily tracker lookups |
CONTEXT & BUSINESS PROBLEM
A Visibility Gap Pushed Users Off Self-Service and Onto the Phone
The legacy portal had fallen critically short, not through one broken feature but through a systemic lack of visibility. Users who could not see where their request stood called instead.
IVR (phone line) calls per day
of users accessed the legacy portal
of post-pay invoices delinquent
THE LEGACY EXPERIENCE
Five Problems, One Outcome: Users Left the Portal
No status visibility
Users could not see request status, expected delivery, or issues, so they called the IVR instead. Rising call volume meant the business kept funding more IVR capacity, an operating cost created directly by the UX gap.
No aggregate view
Requests were looked up one at a time by request number. There was no way to see all of “my” or “my team’s” requests together.
No self-service intake
New requests could not be created online, which pushed volume into manual and offline channels.
No payment visibility
Payment was due after delivery with no way to see pending balances, so the business chased clients with repeated reminders.
High-friction tracking
Even logged-in users could only search by request ID, despite holding other identifying details that could have supported a lookup.
Cumulatively, this drove users away from the portal and back to phone support, the opposite of what a self-service platform should do and a direct cost driver for the business.
ROLE & SCOPE
Senior-Level Ownership, Directly Accountable to Stakeholders
The Senior / Lead UX Designer owned UX strategy and design direction across both products, with a Junior Designer supporting screen production. Design decisions were presented directly to business stakeholders and Product Owners, with no intermediary layer between them and the people funding the work. A core part of the scope was introducing AI-assisted workflows into the design process itself.
DISCOVERY & RESEARCH
The Support Team Was the Voice of the User
Research combined support ticket analysis, IVR call-log analysis, and interviews with the IVR support team, using the people fielding the pain daily as a proxy for the end-user voice.
Callers wanted one answer
Most callers wanted status and an estimated delivery date, not the full complexity of a redesigned portal.
Enterprise teams needed team-level views
The client base skews enterprise (payers, hospitals, legal teams). They needed every request and payment across their organization, not just their own.
Three access tiers
Needs split cleanly into View-only, Normal (view, cancel, pay), and Admin (full access plus user and payment management), mirroring how enterprise clients structure their own teams.
One root cause for delinquency
Payment delinquency traced back to no upfront visibility into pending post-pay balances.
Jargon was a barrier
The legacy UI leaned on internal, technical language that non-technical requesters could not use.
UX STRATEGY: THE REFRAME
Split One Portal Into Two Focused Products
Most callers just wanted a fast status check, so the fastest path should not require a login at all.
The original ask was one redesigned portal. Instead, the design lead proposed a lightweight, no-login tracker for quick lookups and a full authenticated portal for account holders managing requests, teams, and payments. Stakeholders were not initially convinced a separate site was worth building. It took three to four rounds of meetings, backed by IVR and ticket data plus a working prototype demoed live, to move from “not ready” to full buy-in.
THE NO-LOGIN STATUS TRACKER
Answering the Most Common Call Without a Call
A standalone tracker lets anyone look up a request by request ID, company ID, or patient details, with no account. A request moves through the same Submitted, In Progress, Complete timeline as the full portal, with estimated completion and balance due visible. After launch the tracker reached 300 to 500 lookups per day.
THE AUTHENTICATED REQUEST PORTAL
One Place to Create, Manage, and Pay for Requests
For account holders, the redesigned portal centralizes request management: an aggregate dashboard, search, status, online request creation, payment information, and transaction history.
Login
Leads with the trust signals the legacy portal never surfaced: HIPAA-compliant security, real-time tracking, and 24/7 access.
Dashboard
A request status summary gives one view across the whole request volume (pending fulfillment, deficient, pending payment, cancelled, finalizing, delivered), plus a balance-due widget on landing.
Find request
A full filter set replaces request-ID-only search. Results support bulk pay, download, and cancel.
Request details
A clear tracking timeline with estimated completion, shipment tracking, and inline payment on one screen instead of a phone call.
No-login tracker
A standalone lookup by request ID, company ID, or patient details, the direct product of the discovery-stage reframe.
Log a request
A guided online intake form with a live preview panel, replacing what used to require an offline process entirely.
Reports and history
Transaction history, itemized invoice details, status reports, and download records turn invisible backend states into self-service information.
User management
Admins manage portal users and authorized users directly, the concrete implementation of the View-only, Normal, and Admin tiers.
FIND REQUEST
From Request-ID-Only Search to Multi-Field Filtering
Discovery showed users held other identifying details but had no way to use them. The redesign supports lookup by any of the following, and results support bulk pay, download, and cancel for team-level work.
- Patient name
- Date of birth
- Reference ID
- Tracking code
- Request ID
- Status
- Date range
PAYMENT TRANSPARENCY
Show the Balance Before It Becomes a Collections Problem
Post-pay delinquency traced to a single root cause: no upfront visibility into pending balances. The design surfaces a balance-due widget on landing, pending-payment status across requests, inline payment on request details, itemized invoices, and a transaction history. Users gave direct positive feedback on pending-payment visibility and transaction history. Whether delinquency itself improved is still open: that result awaits a full billing cycle of data.
DESIGN PROCESS & KEY DECISIONS
Hiding Complexity Behind a Simple Interface
Each request carried layers of business logic that had to be reconciled into one simple interface:
- Pre-pay and post-pay models
- Mail, email, FTP, and fax delivery
- Variable SLAs
- Health-data security and authentication
- Multi-patient request forms
- Outreach calls
8 items to 4 pages
Navigation was consolidated from 8 legacy items to four major pages at launch: Home, Find Request, Download Records, and Action Required. Reports, Transaction History, and a dedicated Payment view were added after launch, based on real usage rather than upfront guesses. The IA was built to scale, not to lock in.
A deliberate departure
The team used a different color theme from the organization's existing product guidelines. It was a deliberate risk that paid off: end users called out the new palette after launch.
Prototype before Figma
Before committing to Figma, a working HTML prototype of the tracker was demoed live to stakeholders, turning an abstract pitch into something tangible and de-risking the decision to split the products.
AI-ASSISTED WORKFLOW
Feedback Cycles Cut From 8–12 Days to 2–3
The 90-day build ran as part of a broader AI-readiness initiative. Wireframes were built directly in HTML with Claude Code instead of static mockups, and AI tools generated multiple design variations quickly. Combined with tight feedback sessions with stakeholders, Product Owners, and customer support, stakeholder feedback turnaround dropped from 8–12 days to 2–3 days per cycle. The gain came from a deliberate process change, not from AI alone: senior judgment still decided what to keep, and what to scrap.
OUTCOMES & IMPACT
One Month After Launch, the Hypothesis Held
Results measured against the baseline metrics from the context section.
| Metric | Before | After |
|---|---|---|
| IVR call volume | 1,000+ / day | −25% |
| Daily tracker usage | Didn’t exist | 300 → 500 / day |
| Online request creation | Not available | Adopted by users |
| Post-pay delinquency | 30% | Pending a full billing cycle |
Documented user feedback
Direct positive feedback on pending-payment visibility and transaction history, confirming that the payment-transparency decisions solved a real, felt problem.
Users reported they could sort and find the right requests far more easily, a direct outcome of the multi-field Find Request redesign.
End users specifically called out and appreciated the new color palette after launch.
REFLECTION
Faster Decisions, Stronger Evidence
This project ran at a noticeably faster pace than prior work. It meant prototyping in Claude Code, connecting Figma to AI agents via MCP, running rapid feedback sessions that forced faster decisions, and getting comfortable scrapping ideas early instead of over-investing. It also reinforced a leadership habit: making the case for a scope change with data rather than opinion, and holding that position through multiple stakeholder rounds until the evidence carried the argument.
STILL OPEN
What Isn't Finished Yet
Pending
Delinquency data, awaiting a full billing cycle. This open loop will inform whether billing options need adjusting.
Open
Mobile support is currently down to 768px, with a goal of 400px.
Planned
Real-time notifications for followed requests.
Watch
Navigation growth (4 to 6 items) should be revisited before it creeps further.
Screens on this page are illustrative reconstructions with fictional sample data. This is the same discipline behind our UX & Product Design , Consultancy , and Legacy Application Modernization work.
Related service
READY WHEN YOU ARE
Working on something similar?
Tell us where the work is stuck and what better looks like.
Book a Consultation