Healthcare SaaS · Self-initiated · Post-surgery care web app · AI assistant · 2026
The UX research is mine: the theming, the triangulation and the findings. So is every UX decision. I set the art direction in Figma, and I built the design system, working in Claude Design.
With participants’ consent, Google Meet transcribed the interviews and Claude Cowork anonymized them. I checked the anonymization and corrected it where needed. I built this page with Claude Code and wrote parts of it by hand.
Day One Home
After surgery, the patient will control every care instruction and who sees it
- What
- Day One Home is the discharge program in Evantis, a self-initiated, 0-to-1 web app concept. The patient will invite family to help, share with professionals, and get routine answers from an AI that hands anything medical to their care team.
- Why
- Today, patients and families are the only link between doctors, juggling notes and phones and waiting hours for a callback.
I interviewed 7 people and reviewed 77 health tech companies: none brings every provider’s instructions together for them. - Role
- End to end: research, business case, UX design, prototyping and testing, to solve real patient pain in a way that can grow a business. I validate key decisions with 6 advisors from my network: 2 product managers, 2 engineers, 1 data analyst, 1 subject-matter expert.
- Discovery and UX research (Done)
- (Done)
- Wireframes, tested with users (In progress)
RITE, Rapid Iterative Testing and Evaluation: I walk a caregiver through the wireframes, weigh what trips them up, change what I judge worth changing, and test it in the next session.
- Prototype in code (Not started)
- User testing and validation (Not started)
My research proved me wrong twice before I designed a screen
In 7 interviews, users already juggled more than 1 portal and kept paper logs anyway. So I chose a standalone web app, not another portal.
Every provider needs a different part of the instructions, and only the patient can let them in. So the patient will control who sees what, in 1 app, not 1 per role.
The state already has the records from every provider, and it pays the bill when a patient it insures goes back to the hospital. That’s why I’d propose the state as the funder. I validated feasibility with engineering advisors from my network.
1 in 7
Adult hospital stays lead to another admission within 30 days.
Washington pays for each one of its Apple Health (Medicaid) members.
AHRQ HCUP, 2024 report ↗ (opens in a new tab)
Industry data, not from this study.
Context
I started by assuming the care instructions already existed, just spread across systems that don’t talk to each other
It came from close to home: family, friends, and once my own household, coming home from the hospital. I reviewed 4 patient portals and . None held a patient’s full history across every provider a patient sees, from the hospital to the dentist to the MRI center.
Can patients and families tell what comes next after leaving the hospital, and who’s responsible for it?
If families see all the care instructions in one place, they can tell what comes next and act on it.
I chose not to build another portal. I’d design one place where families see all the instructions.
Discovery
After the hospital, families kept track of everything themselves
- A paper medication log, kept by the recliner.
- A notes app shared with siblings.
- A Google Doc of research, and a list of questions for the surgeon.
Each family used its own mix of paper, apps, portals and messages. None of it lived in one place. Access to medical records split the group, and that turned the next step toward access.
Who I talked to: 4 family caregivers and 3 care professionals, all from my own network. The caregivers looked after a parent, a spouse or a child, and their experiences ran from 2021 to 2026.
Parents had their children’s records by default. For adults, it depended on the patient: one handed access over when leaving the hospital, another managed their own care.
“I had the feeling I’m the only connection between [all of their doctors].
“You need to wait. You need to call many times. You’re waiting for that phone call back. Meanwhile, [they’re] in pain.
Problem definition
Many people touch the care instructions, and each needs a different part of them
I mapped who handles the care instructions after the hospital. Family and outside care professionals needed an adult patient’s permission to see them.
Families and care professionals walked me through each handoff: the surgeon, the nurse, the pharmacy, the family at home. Relatives got in with the adult patient’s consent, or by using their login and password. A home care agency told me it had no access to hospital records at all. So sharing became its own step, and the patient controls it.
Service blueprint
Evantis gives the patient one set of instructions. Behind it, the state, the providers and a nurse each play a part. The service blueprint and the task flows shaped the wireframes.
Task flows
6 flows for the weeks after the hospital: steps and decisions, not screens.
Nothing sensitive is typed. The member ID is on the card.
Answers come only from the patient’s records, the plan and a library vetted by healthcare organizations.
The notification never carries health details.
Only the patient grants access, or a legal proxy for an incapacitated patient.
No action from the user.
- DecidedThe AI answers, says no, or hands off
It answers from the patient’s records and instructions, says no to what it shouldn’t answer, and hands clinical questions to a nurse.
Who answers when the AI hands off is still open. At first it was the hospital’s nurse, but I moved away from the hospital. My likeliest option: Washington’s Medicaid insurers already run 24/7 nurse advice lines, so Evantis could route each question to the patient’s own insurer. I’m reviewing this with my advisors in Sprint 4.
- Ruled outBuilding inside the hospital’s record system
Its records stop at its own patients and its own visits.
- LaterCare professionals editing the instructions
They only view them in the first version. Editing from their own software is a second step.
Decisions
The promise needs records from every provider a patient sees, so I’d start with the state, not with one hospital
A hospital keeps only its own records. The state pays for its members’ care wherever they go, so it holds them across providers.
Apple Health is Washington’s Medicaid program, the state’s payer. Starting with one hospital would be quicker, but every hospital would need its own connection, and it would still miss the dentist, the therapist and the pharmacy. A lead engineer checked with me that building on the state’s member ID and records is feasible.
Some families have no one well enough to help and no way to pay. An app won’t change that.
Lo-fi wireframes · in testing with caregivers
Exploration
The direction has support. Now it earns the build decision session by session
A CEO and a CPO from my network supported the direction after I presented the research, the hospital route I ruled out and the case for the state. Before anything gets built, I’m testing the 2 assumptions the product depends on, in rough form. The assumptions: that a patient can run their day from one screen, and that they will trust an AI that answers from their own instructions and hands the rest to a nurse.
I asked the CEO and the CPO 2 things: does the state direction hold, and who should own the nurse line. The direction held. The nurse line stayed open. Each session confirms a decision or changes it; the board keeps the record, and Sprints 6 and 7 set the bar for the build decision. The screens are whiteboard and sticky notes on purpose: cheap to change the same day, expensive to fall in love with.
Design decisions
I’ll decide what the first version does, and what it leaves out
With the direction supported, I settle 3 things before any high-fidelity design, so the expensive work starts from a fixed brief.
- 1
Product scope
Recovery after a hospital stay only: the care instructions, the AI and sharing. Family profiles, visits, documents and the rest of Evantis come later.
- 2
Success metrics
The for task success, AI safety and AI quality are set. I’ll test against them in Sprints 6 and 7.
- 3
Design system
I’ll extend the Evantis design system in code, so prototypes come together fast.
Iteration and outcomes
I’ll prototype and test until the evidence says build, iterate or stop
Once the first version is defined, each round puts a coded prototype in front of users and measures the prototype against the targets set in Sprint 5.
- 1
Prototype fast
I’ll prototype in code on the Evantis design system, from rough to final.
- 2
Check feasibility
I’ll check with my engineering advisors that each prototype can be made as it stands.
- 3
Test often
Each round: 4 caregivers, 2 patients, 3 care professionals and 2 nurses. The first rounds test the AI’s answers and sharing, the riskiest parts.
- 4
Build decision
I’ll recommend build, iterate or stop to the CEO and CPO, against the in Success Metrics. Miss task success or an AI safety gate, and the recommendation is stop.
What I learned
I was sure the answer was a better portal, then sure the product should start with a hospital. Both times the evidence overturned my plan before a screen existed, which is the cheapest moment to be wrong. It also showed me that the family member running care isn’t always in the room; some coordinate from another state. So I test the premise before the product, and I design for the caregiver at a distance.