Skip to content
Healthcare · Patient Access2025

CR Patient

A patient-facing portal that makes requesting and tracking your own medical records feel effortless.

Role
Product Designer
Timeline
3 months
Platform
Web App · React
Year
2025

CR Patient is the consumer side of ChartRequest, where real patients request, pay for and track their medical records. Unlike the operations platform, these users aren't power users. They arrive once, often stressed, and need to finish a task without a manual.

The Problem

What wasn't working

The existing flow borrowed patterns from the internal tools, dense tables, KPI tiles and jargon that made sense to staff but overwhelmed patients trying to do one simple thing.

Goals

What success looked like

  • Design for one-time, non-expert users completing a single important task.
  • Replace dashboards and stats with direct, obvious entry points.
  • Meet WCAG AA so the portal works for everyone requesting their own health data.
Research

What I learned first

  • Studied where patients dropped off in the existing request flow.
  • Reframed the portal around the patient's job: 'get my records', not 'manage requests'.
  • Pressure-tested language so medical and legal terms became plain English.
Challenges

The hard parts

  • Simplifying without hiding legally required detail.
  • Designing empathetic empty and waiting states for an anxious moment.
  • Keeping the same design tokens as the platform while feeling softer and more human.
Design Process

How I worked through it

  1. 01

    Reframe

    Cut KPIs and stat tiles. Led with a single, direct 'Request records' entry point.

  2. 02

    Flow

    Broke the request into calm, one-decision-at-a-time steps with clear progress.

  3. 03

    Reassure

    Designed status tracking so patients always know exactly what happens next.

Wireframes

Structure before surface

Sketched the request as a linear wizard, testing how much to ask on each step before it felt heavy.

User Flow

The path a user takes

  1. 1Patient arrives and sees one clear action
  2. 2Answers a few plain-language questions
  3. 3Reviews and confirms the request
  4. 4Tracks status with human, jargon-free updates
Final UI

Where it landed

A warm, focused portal that treats a stressful task with care, direct entry, honest progress, and no dashboard to decode.

Impact

What changed

AA
WCAG accessibility target
Task-first
Replaced dashboards with direct actions
Fewer
Steps to complete a request
Clearer
Status communication for patients
Lessons Learned

What I took away

  • Designing for patients is the opposite of designing for staff, remove, don't add.
  • Tone is a UX decision. Words carry the anxiety or the calm.
Reflection

This project reminded me that accessibility and empathy aren't checkboxes at the end, they're the whole point when someone is asking for their own health records.