NNg Certified - ID 1064178
Patient Portal
A patient portal for Medical Specialists, PA, a local specialty practice, designed for mobile and laptop.
Each scenario is a working path through the prototype, based on my conversations with patients and the practice owner. The portal changes what it shows first and how it phrases it, but it never changes or hides a value.
In the prototype · Home → Results
In the prototype · Home, refill entry
In the prototype · Rail control → Results
In the prototype · Visits
In the prototype · Every screen
In the prototype · Medications
The practice owner described the problem in operational terms: patients rarely use the portal, so they call the front desk, which takes staff away from other work. He also mentioned several layout problems that contributed to patient dissatisfaction and a negative view of the practice.
Design the practice’s portal for mobile and laptop, with the same features on both, using the Carbon design system and the practice’s own brand. Develop it far enough that the practice owner can walk through real patient scenarios.
Each section shows the existing portal as it is today, with identifying details removed, followed by my exploration and the refined concept in the clickable prototype. Tap any screen to enlarge it. The design uses IBM Carbon type and tokens with a warm, plain tone. Every row, tab, help icon, refill button, and message thread in the prototype responds to taps.
What was wrong. The page greets the patient and then shows counts. In the account I reviewed, “5 unread” opened mostly promotions, and “View All” does not say what to do next.
What I changed. I started from one question: what does this patient need today? The page now leads with one item and its action, such as a results summary or a refill button, and says why it comes first. The main result states that the clinician has already seen it. AI-written text is labeled, with a “Read from” line.
What was wrong. Each medicine is a dispensing label in capital letters. It does not say what the medicine is for, how many days are left, or where to refill it.
What I changed. Each medicine is now a card that starts with what it does and when to take it (“Thyroid, first thing”), with days left, refills authorized, a Refill button, and the clinical name below. A daily timeline shows how the medicines fit together, including a timing conflict between vitamin D and thyroid medicine.
What was wrong. Results are listed by date and test name. The list shows a date where the value should be, so every result requires a tap.
What I changed. Each value is shown on its reference range, with the previous result and one sentence of context. Patients choose Guided, Standard, or Detailed. A low value is shown in amber rather than red. Only the order and wording change, never the number.
What was wrong. Messages appear in an email-style inbox, where promotions, statements, and notes from clinicians look the same.
What I changed. Care team messages come first, with the sender’s name and role, followed by practice news and billing. One “Ask your care team” button replaces Compose, and each message includes what the patient was viewing, such as the June panel.
I placed AI at four points, all following one rule: AI reads and drafts, the patient decides, and every generated item shows what it was based on. Nothing in the concept answers a clinical question; those go to the care team.
Labeled “Not reviewed by your care team,” with a “Read from” line naming the panels and the clinician review it was based on.
A question field that answers only from the patient’s own chart.
AI drafts the request, and the patient reviews and sends it.
Suggests questions for the next visit, each linked to the value that prompted it, written as questions rather than advice.
A clickable prototype for mobile and laptop, with documented design rationale and six patient scenarios that work as paths through the prototype.
Reviewed by the practice owner across several meetings.
After the review, the owner asked me to redesign the clinician tool as well. I recommended starting with the patient side, and I told him that architecture, integration, security, and compliance are outside my expertise and require qualified specialists.
Integration with the records system, security, privacy rules, and clinician workflow determine whether a patient portal works. A refill request or a reviewed result must go to a clinician queue, so the patient side cannot be designed in isolation.
AI drafts, the person decides, and every output shows what it was based on. The limits on what the AI can do are as important to the design as its features.
The next steps are about validation rather than building.
A two-week anonymous log of why patients call the front desk, and short task sessions with five to eight patients and front-desk staff. Some fixes may be configuration changes rather than a new product.
Connect the question field to a live model restricted to a fictional record, and test it with difficult questions such as “should I stop my medication?”
A clinician review of every medical example, the clinician handoff workflow, and the decision to configure, buy, or build belong with the owner, a clinician, qualified engineers, and a compliance advisor.