Work / Carefully
From a booking app to trust infrastructure.
Phase 1 proved patients wanted Carefully. It also proved I had built the wrong product. Carefully was a booking app, but the value lived in the trust layer that comes before booking. Phase 2 rebuilds it as trust infrastructure and tests one question: do structured trust signals change which provider a patient picks, or only how they feel?
The problem
Millions of patients with chronic pain delay or avoid care because they cannot find providers who will take them seriously. A 4.6-star average says nothing about whether you will be interrupted, rushed, or dismissed.
Carefully surfaces the pattern instead of the score, so the people most likely to be dismissed can see it coming.
Built for patients with chronic pain, and bias-aware providersWho it's for
In despair over finding a provider who fits their needs. In constant pain, and powerless to change it.
They can see how a provider actually treats patients before they book, walk in with their concerns already organized, and finally feel heard and in control.
Demoralized by defensive, distrustful encounters, with their relational skill going unseen and their idealism wearing thin.
Patients arrive pre-matched and prepared, so visits start from trust instead of suspicion, and the relational work that drew them to medicine is what gets them chosen.
The pivot
Phase 1 testing (n=6, SUS 81.5) showed the trust idea landed, and exposed three failures: dead navigation, low-fidelity visuals that cost credibility, and too few real options. The fix had to go further than a polish pass: it called for a re-design. Carefully stopped being a booking app and became a layer patients use before they book elsewhere.
The build
Behavioral patterns like "listens well" and "rushed visits noted" replace stars, so patients know what to expect before they book.
Patients log their concerns and get a clinically legible summary plus questions to ask, so they walk in prepared, not surprised.
A private care record that, with per-entry opt-in, feeds the trust layer, turning one patient's experience into the next patient's signal.
The demo
The test
Phase 1 asked whether people liked the idea. Phase 2 asks whether it changes how they choose. A randomized, unmoderated A/B study (n=30, standard listing versus trust-signal listing) measures whether patients switch providers when the signals appear, not just how they feel about them.
The hard parts
The hardest part of building Carefully at this phase was making change decisions, and arming myself with enough information to stand behind each one.
In the first round, even with people I knew, it was hard to hear negative feedback, to watch the app glitch, to see where users simply didn't get the point. The second round was harder still, because it demanded trade-offs.
My moveI made myself sit with the uncomfortable questions instead of around them. Is this actually the right solution to this problem? Can I realistically build the infrastructure it would need? Letting the data drive the answer, not my attachment to the idea, moved the product forward.
After Phase 1, I hit a wall. I'm deeply independent, so I found the work itself to be less difficult than recognizing that being resourceful sometimes means asking for help.
My moveI found Eric Shumake's Maven Healthcare in UX course, applied for the scholarship, and got it. I took it alongside an Interaction Design Foundation mobile design course and applied both directly to Carefully's problems.
A product that tries to serve everyone serves no one. The hard call here was cutting down who Carefully was for, when every cut felt like closing a door on someone.
My moveI redefined the user as people managing chronic pain, in the Philadelphia metro area, on the web. The choice to focus on chronic pain stemmed from a social listening exercise I did as part of my UX in Healthcare course. Reading entry after entry in patient forums gave me a sense of the vast unmet needs of this population. These patients were the most visible and communicative, and seemed to derive the most satisfaction from good provider communication. They also collaborate with each other a lot.
For example, here's a type of post you'll frequently see on r/chronicpain: "I have a pain specialist appointment next week. Tips to get the doctor to take me seriously and actually try to help me? There are definitely a couple things I want to try but won't name them, otherwise I'll look like I'm drug seeking."This told me that this population would be easier to find and solicit feedback from. The problem instantly got more solvable.
I started out learning Kotlin, set on building a native app. That path felt like the best way to do it, and walking it back felt like a step down.
My moveI made the trade-off with clear eyes and started with a web-based build. A native app would allow the user access to notifications and GPS, key for finding nearby providers, but in the end, the build speed of a web app won me over. Although users spend 90% of their browsing time in apps, Carefully's users are already primed and high-intent by the time they arrive. Plus, a smooth, responsive design can give the website a convincing web-app feel. So I chose the platform I could realistically build up into a scaleable system.
Each of these was a pivot, and each pivot came from the same place: sitting in the discomfort of a decision, then gathering as much information as I could until I felt good about making it.
The behavioral results come next. If you have ever felt dismissed at a doctor's visit and want to help shape this, I am recruiting Philadelphia-area participants.