A wellness app that started with a wrong guess

The client came to us with an idea. The physical program had been running for years and was working, but they could see a ceiling. A digital extension could reach more survivors, more often, more affordably. Maybe.

They had questions. Could the program translate to an app at all? Was AI the right tool, or just the trendy one? Could we build something real enough to test the idea?

What they needed was a proof-of-concept prototype. Something tangible enough to take to funders. Real enough to validate the concept. Lean enough to build inside their budget. The POC wasn’t trying to ship a product. It was trying to find out if shipping one was worth pursuing.

We came into the project with a hypothesis. After our research with cancer survivors, it wasn’t landing.

Our client, a small non-profit serving cancer survivors, founded by a survivor herself, had built a working program around monthly care packages. Each one highlighted five well-being practices: hydration, fuel, breathing, gratitude, and sleep. The program worked. People loved it. The client wanted to know if it could translate to an app.

The first question wasn’t “what does the app look like?” It was: what about the physical program actually works, and what would translate to a digital one?

Our approach:

The client walked us through the program: what members received, and what mattered most to the founder. Follow-up sessions pulled together a feature set: must-haves, nice-to-haves, and future ambitions.

One-on-one interviews with cancer survivors. We asked about the survivorship journey and what actually helped them through it. Then we reconciled what the client had told us with what the survivors did.

Going in, we hypothesized tracking would be the hook: mood, pain, medication, daily check-ins. Tracking is the standard play for wellness apps. Clients ask for it.

Survivors disagreed.

Tracking isn’t what they needed. They could already point to half a dozen apps that did it, and most sat unused after the first week. User drop-off in health tracking is a well-known pattern.

What did matter: information. The overwhelming volume of it. Good and bad cancer information. Appointment notes. Doctor instructions. Things they wanted to ask but forgot. The cognitive load of being a patient was the actual problem.

The opportunity wasn’t a tracker. It was an app that surfaced science-backed information and was smart enough to make sense of the notes users were already taking.

That’s where AI summarization came in. Users were already writing. The app could read it, summarize it, and surface what mattered.

The hook wasn’t teaching a new behaviour. It was making an existing one less heavy.

The hardest part of the project wasn’t the research. It was what to do with it.

The client understood the finding. They didn’t dispute that tracking wasn’t the hook. But their entire program was built around the five well-being practices. Hydration, fuel, breathing, gratitude, sleep. Not a feature set, the foundation. They wanted it to be the foundation of the app, too.

Two things were both true:

• Survivors said: the cognitive load of information is the real problem. Help us with that.
• The client said: the five practices are foundational. They have to be here.

The temptation is to pick a side. Push the client toward the research, or capitulate and bury it. Both moves are common. Neither is right.

The way through wasn’t choosing between content and tracking. It was rethinking what content meant in this app.

In the physical program, content was delivered. Packed into a box, sent monthly, opened on the user’s kitchen table. The package was the delivery mechanism. The user didn’t have to go looking.

An app doesn’t work that way. Generic content in an app is just a library. Libraries get ignored.

But content surfaced in context, that’s something else. Not a library. A response. The app could deliver the client’s curated content, the content they cared about, in a way that felt personal and relevant.

That reframe gave stakeholders what they actually needed. The five practices stayed at the foundation. Tracking came back into the design, but as a signal, not the hook. And users got what they’d asked for: less cognitive load, with the right information surfaced when it was useful.

The clearest example was hydration.

A user logs their daily intake. The app reads the signal. Based on the entry and the broader pattern, the AI surfaces relevant content from the client’s library. Maybe a short read on why hydration matters during treatment. Maybe a tip about flavored water during nausea. Maybe nothing — because the user is doing fine.

The hydration loop did three things at once:

1. Preserved the client’s content (the five practices stayed).
2. Treated tracking as a means, not an end (users log to get something, not to log).
3. Used AI to make generic content feel personal (surfacing is contextual to that user, on that day).

We carried the same pattern across the other four practices. None required the user to study the program. The program met them where they were.

When client priorities and user research disagree, the answer usually isn’t to pick a winner. It’s to ask whether the two signals are actually in conflict, or whether they’re describing the same problem from two angles. The client wasn’t wrong to defend the program. Users weren’t wrong to say tracking didn’t matter. Both were giving us real information. The design’s job was to figure out how both could be honored.

That’s the work. Not the wireframes, not the prototype, not the research synthesis. The reframe is the work.

The proof-of-concept prototype was delivered. The client has been using it in conversations with funders and sponsors. The funding outcome is still unfolding — but the POC’s job wasn’t to land the funding. It was to make those conversations possible. By that measure, the work is doing what it was meant to do.

The client. They were deeply invested in their program and community, and they could have easily said “please just do what we ask.” They didn’t. They made space for the research, sat with what it surfaced, and gave us the grace to figure out how to honor both their program and what users actually needed. That kind of openness isn’t guaranteed, and I don’t take it for granted.

Not picking sides. When client priorities and user research disagree, the easy moves are to capitulate or to push. The harder, better move is to ask whether they’re really in conflict and to design a version where both can be true.

Ask the client, up front and explicitly, what their hill to die on is. If the research lands somewhere they can’t go, I want to know that early. Not to argue with them, but to know what I’m working with.