Healthcare UX · 2024Product Design ConceptIA · Interaction · Design System · Accessibility
MedBridge: a patient portal that finally makes sense.
Healthcare patient-portal Product Design concept unifying appointments, prescriptions, billing, and records into one calm flow.
Solo Product DesignerProduct discovery · Research synthesis · IA · Interaction design · Visual design · Design system · Accessibility · Prototyping
- One calm portal for appointments, prescriptions, billing, and records
- AA
- WCAG 2.1 self-audit
- 44
- interactive prototype screens
Patients juggled four disconnected portals and still couldn’t find basic information.
The old patient portal scattered appointments, prescriptions, medical records, and billing across separate sections, each with its own navigation. People called support for things that should’ve taken thirty seconds to do themselves. The portal just didn’t match how patients actually think about their own care.
The problem was structural, not visual. The portal had been built as four separate tools, and that’s exactly how it felt to use.
MedBridge is a healthcare patient-portal Product Design concept, not a production healthcare system. I used research synthesis, systems thinking, accessibility work, and a deep interactive prototype to explore what one calm portal model could look like without claiming a healthcare client, live clinical integration, or external validation.
Four disconnected tasks, one portal model.
Retrospective portfolio visualization based on the verified MedBridge narrative. The left side shows the fragmented structure the concept responds to; the right shows the unified navigation and component model.
Fragmented structure
- Appointments
- Prescriptions
- Medical records
- Billing
Separate tools, separate navigation, and context rebuilt at every handoff.
Unified portal model
One component set
Appointments, prescriptions, records, billing, and profile management share one calm system.
Retrospective portfolio visualization based on the verified MedBridge narrative.
Three patterns that shaped every decision that followed.
I used user interviews, contextual research across MyChart, Zocdoc, and Teladoc, journey mapping, task analysis, AI-assisted competitive analysis with Perplexity, and iterative prototyping. Beth and Mitchell are synthesized personas representing recurring user needs and accessibility themes, not confirmed named or anonymized participants.
Method note. Perplexity supported the competitive-analysis pass; it was used to organize comparison notes, not treated as primary research evidence. I am not publishing a participant count here because the exact number is not confirmed in the project record.
Beth · representative patient need. Just tell me what I need to do next and how much it costs.
Mitchell · representative caregiver/accessibility risk. If I can’t read it or I get lost, I just call the office, which defeats the whole purpose.
Patients treat the portal as one product
Every person I interviewed called it “the portal,” like it was one thing. In practice they were living with four disconnected tools. Drop-off spiked whenever someone tried to move between service areas.
Appointments are the front door
Scheduling and managing visits was how most people entered the portal in the first place. And yet that flow needed the most clicks of any section, with more dead ends than anywhere else.
Stress makes every flaw worse
People open health portals at anxious moments: right before a procedure, right after a diagnosis, when a prescription’s about to run out. Their mental bandwidth is already spent before they even open the app. So clarity here isn’t a nice extra, it’s the whole job.
Seven decisions the journey map forced.
Several research inputs shaped these decisions: broader interview themes, the competitive comparison, journey analysis, accessibility requirements, and iterative design critique. One primary end-to-end scheduling and access journey represents the highest-friction workflow; the decisions are not falsely attributed to that journey map alone.
FHIR R4 as an IA and data-model consideration
The concept’s patient, appointment, observation, medication, coverage, and invoice view models are mapped to HL7 FHIR R4 resources as an information-architecture and data-model consideration. The prototype does not connect to live FHIR APIs or a clinical system.
In-network by default, sorted by fit
The patient persona’s problem was too many results, unclear in-network status, and choice paralysis. So the redesign defaults every search to in-network providers and sorts by soonest availability and best match, instead of just dumping an alphabetical list on the user.
Real availability, not a guessing game
The second problem was that barely any slots fit a 9-to-5 schedule, and figuring out what was actually open took too much digging. The concept highlights evening and telehealth slots up front and shows open times before a patient commits to a provider.
Plain language, not clinical jargon
The representative patient need was to understand lab results without needing a translator. Test results now carry a “Reviewed” status in plain English instead of raw lab codes. Same information, no medical degree required to read it.
One accent color, spent only on action
Blue shows up only where a decision is actually live: a primary button, an active nav item, a selected date. Everything else stays neutral. That way the one thing that needs attention isn’t competing with a bunch of brand color for it.
44px targets, built for lower dexterity
The synthesized caregiver/accessibility persona represents the risk of clicking the wrong button and breaking something. Every interactive control now spans at least a 44×44px hit area with 8px of clear space around it. That’s comfortable for caregivers and anyone whose motor precision isn’t perfect.
A keyboard path, not a visual afterthought
Tab order matches the visual reading order exactly, a skip-link sits first in the DOM, and every icon-only control has a descriptive aria-label. I checked all of this with an actual Tab-and-VoiceOver pass; a contrast checker alone would have missed it.
Mitchell needed two accounts. He got one.
Mitchell is a synthesized caregiver persona representing an accessibility and account-model theme, not a confirmed participant. Not everything from the research made it into this version, and that’s worth being upfront about.
The caregiver dual-account gap
Proxy access is an account-model decision. A caregiver cannot safely use a shared login. A production MedBridge flow would use delegated proxy consent, explicit patient context, scoped permissions, and an audit trail so Mitchell could manage two patients without blending their records.
The representative caregiver need is to keep two patients’ appointments in one organized place without switching between confusing, dense accounts.
Real caregiver access means a second identity with permissioned visibility into a spouse’s records, rather than a shared login. Building that would have changed several information-architecture decisions in this project: how the dashboard greets the user, how appointments get attributed, how billing splits across two people. That’s a redesign of the account model, not a feature bolted onto one.
So I scoped this version around a single-patient account and wrote the gap down instead of forcing in a shortcut that would’ve undermined the “one calm, organized place” goal for everyone else. It’s the first thing I mention in the reflection below, and it’s the most consequential thing I’d build next.
From lo-fi to final, the dashboard.
The dashboard shows the clearest before-and-after. KPI cards above the fold, two content blocks below: that layout got locked in at the wireframe stage and never changed after that.
Lo-Fi
Final UI
Every numbered dot traces back to a friction point.
The dashboard and provider search carry the most research weight of any screens in the flow. Below, each element is annotated with the specific finding it came from.
- Pending balance sits beside unread messages, not buried in Billing. This is Insight 02: appointments and money are both front-door tasks. Beth shouldn’t have to leave the dashboard just to find out she owes $248.
- Confirmed, Telehealth, and Pending are visible without opening a row. This ties to Insight 03: stress makes friction worse. Someone scanning for “what do I need to do next” gets the answer right in the list, no click required.
- Vitals carry a “Confirmed” status, the same pattern as appointments. One visual language for “this is settled” means a stressed patient has fewer things to learn just to read the screen.
- Insurance filter defaults to a live decision, not a dead-end dropdown. This is Decision 02. The journey map’s biggest friction was unclear in-network status, so filtering by insurance is now a first-class control instead of something buried in Advanced Search.
- Rating and years of experience sit directly under the name. Choice paralysis came from too many undifferentiated results. A trust signal at a glance narrows the decision without making someone open every profile.
- Book is one tap from the search results, not three screens deep. This is Decision 03. Showing real availability up front means Beth commits to a slot without a separate “check availability” round trip.
One system. Five unified flows.
The four disconnected portal sections (appointments, records, prescriptions, and billing) become one system, with profile management as the added fifth flow. All five share one navigation model and one set of components. When people are already stressed, not having to relearn the interface every time they switch sections matters.
Audited, not assumed.
The WCAG 2.1 AA label in the hero is a self-conducted audit result, not external certification. Mitchell is a synthesized caregiver and accessibility persona used to test representative readability, navigation, and control-size risks, not a confirmed participant.
I evaluated keyboard-only navigation, visible focus states, color contrast, semantic hierarchy, form labeling and errors, VoiceOver on macOS, and responsive behavior. These checks support the self-audit claim; I did not test with disabled participants or claim external certification.
- 7 / 7
- Contrast pairs pass, up to AAA
- 44×44
- Min. touch target, 8px clear space
- 15.8:1
- Heading contrast (AAA)
- Tab + VO
- Self-checked keyboard + VoiceOver pass
Validation had a clear boundary.
Validation consisted of iterative design critique, heuristic evaluation, accessibility review, competitive comparison, and repeated workflow/prototype evaluation. I did not conduct moderated patient usability testing on this concept.
The next validation round would put the navigation, find-a-doctor path, booking flow, and cross-portal handoffs in front of patients and caregivers in moderated sessions. That is where I would test whether the unified model holds under real patient stress and assistive-technology use.
“This wasn’t really a visual redesign. It was a clarity redesign. I tested every decision against one question: would a patient under stress still know what to do next?”
The prototype: one portal, five flows.
The final redesign folds four disconnected portal sections into one system, with consistent navigation and predictable interactions. Appointment booking, prescription refills, billing, medical records, and profile management now share one mental model and one set of components. The accessibility work is a self-audited WCAG 2.1 AA target, not external certification, and the prototype does not connect to live healthcare data.
What I’d do differently.
I designed the mobile experience after desktop. Appointment check-ins and prescription refills mostly happen on phones, so next time I’d flip that order: mobile-first wireframing, then scale up.
I built accessibility into the components, but I didn’t test with screen reader users during wireframing. Next time I’d run at least one assistive-technology session early, in the lo-fi stage, instead of saving it for a final audit before handoff.
Full process archive (personas, journey map, sketch notes, and wireframes)
Two archetypes, opposite ends of tech literacy.
Beth is a synthesized mobile-first patient persona and Mitchell is a synthesized caregiver/accessibility persona. They represent themes from the research synthesis, not identified research participants, and together they span the widest gap in tech comfort this concept needs to serve.
Realize, find, choose, confirm, done.
One primary end-to-end patient journey represents the highest-friction scheduling and access workflow, from realizing care is needed to a confirmed visit. Two friction points drove the redesign priorities: finding an in-network doctor and finding a slot that fits the patient’s schedule.
One home, seven sections, two taps from the dashboard.
A flat IA with seven top-level surfaces, built shallow on purpose. Every screen is reachable in two taps from the dashboard.
Digital wireframes. Decisions locked in.
Moving to digital wireframes was the real test of whether the sketch decisions held up at screen fidelity, before any visual design work started.
One clear path in, SSO as the escape hatch
Two-column below the KPI cards
Tabbed status filtering over a dense table
Three-step booking with a persistent summary
Real labels, real hierarchy.
Same three screens, now with defined components, real copy, and basic hierarchy. One accent color, blue, introduced strictly for primary actions and active states.
A single source of truth.
WCAG-checked color roles, a 1.20 type scale, a 4px spacing rhythm, and the core components every MedBridge screen gets built from.
The primary path, fully clickable.
44 reviewable prototype screens: sign in → dashboard → book → pick date & time → confirm → success, plus the records, prescriptions, billing, messaging, and mobile surfaces. It is real screen-to-screen navigation, not a slideshow pretending to be a product.
