Health Companion

Health Companion

One coherent home for your health

A health companion app for managing day-to-day wellbeing, from chronic conditions to everyday habits. I was the founding designer, working directly with the founder and two part-time developers to take the product from a sprawling feature list to a focused, usable tool.

Client

Confidential, early-stage startup

Confidential,

early-stage startup

Role

Founding Product Designer

Team

Founder,

2 part-time developers

Industries

Healthcare

Timeline

~6 months

App name withheld at the founder's request, as the product has not yet been publicly released.

Health Companion

One coherent home for your health

A health companion app for managing day-to-day wellbeing, from chronic conditions to everyday habits. I was the founding designer, working directly with the founder and two part-time developers to take the product from a sprawling feature list to a focused, usable tool.

Client

Confidential, early-stage startup

Role

Founding Product Designer

Team

Founder,

2 part-time developers

Industries

Healthcare

Timeline

~6 months

App name withheld at the founder’s request, as the product has not yet been publicly released.

Health Companion

One coherent home for your health

A health companion app for managing day-to-day wellbeing, from chronic conditions to everyday habits. I was the founding designer, working directly with the founder and two part-time developers to take the product from a sprawling feature list to a focused, usable tool.

Client

Confidential, early-stage startup

Role

Founding Product Designer

Team

Founder,

2 part-time developers

Industries

Healthcare

Timeline

~6 months

App name withheld at the founder’s request, as the product has not yet been publicly released.

How this started

A founder came to me with a real problem and a lot of ambition. People manage their health across a scatter of disconnected tools:
a fitness app here, a patient portal there, notes and reminders somewhere else, none of them aware of the others. His answer was a single app that brought all of it together: tracking, coaching, learning, doctor visit preparation, an AI assistant. One place for everything.

It was a genuinely good instinct, since the fragmentation is real and worth solving. My job was to find the version of it that could actually ship with a small part-time team and no budget, and over the months that followed, that turned out to be a narrower question than where we started.

The brief

The brief

The brief

What the research showed

There was no budget for formal user research, so before opening Figma I did the work I could: a competitive analysis of the tools people already use to manage their health, and a close read of where each one breaks down.

The pattern was consistent. These products were not failing because they lacked features. They were failing because of fragmentation. Every tool owned a slice of the problem, and none of them held the whole picture.

One gap stood out specifically: people had health data everywhere but nowhere to think out loud about what it meant. The existing tools handed you raw numbers or sent you to a doctor, with nothing sitting in between that could watch your data and open a conversation about it.

All of this pointed toward simplicity and trust as the things most worth designing for, which was in direct tension with the roadmap.

Designing inside the tension

I made the case for a tighter scope early and kept making it, but the roadmap had its own gravity. The founder was attached to the full vision for understandable reasons: every feature on it existed because it solved something real, and there was no clean moment where everyone agreed to do less. Rather than push the argument further in the abstract, I built out the full experience the brief asked for, because making the product tangible was the fastest route to a real conversation about what it needed to be.

Testing was where that conversation was going to happen, so once the core flows were built, I ran a round with five people to see how the full vision actually held up.

The turning point. Mid-project testing

The homepage was the clearest failure. Four of the five could not say what it was for after spending a minute with it. Two described it as "a dashboard," one called it "the notifications page," and one asked where the home screen was while already on it. Nobody mentioned the AI coach card unprompted, even though it sat at the top of the screen, because the metric tiles below it carried equal visual weight and won the attention race.

That was the evidence I had been missing.

Finding the right structure

The navigation went through four versions before it settled, all circling the same question: where does the coaching actually live?

Coach and MyHealth were doing the same job, so Coach absorbed MyHealth. Connect had no real feature behind it and came out. Challenges tested a gamified structure with streaks, but “challenge” read more like an obstacle than an invitation. It became Learning instead. What shipped is four tabs: Coach, Learning, My Data, My Doc. Each earned its place by surviving a version where it was tried and removed for a reason I could explain.

Designing for engagement

The Coach screen followed the same logic.

The first version was a feed trying to be every health touchpoint at once.
The second reduced the sections but the AI coach was still one item in a list rather than the reason to open the app.
The final version made the AI card the first thing a user sees, before any numbers, and the metrics moved to a supporting position below it. The screen went from a health dashboard with a chatbot attached to a coaching companion that happens to surface your data.

Coach buried as a widget

No hierarchy between the AI coach and
everything else. The screen has no primary
job, resulting in a cluttered, list-heavy
interface that lacks focus.

Coach as frame, tips as feed

Right placement, wrong density. The AI greeting is generic and the health metrics below carry equal visual weight, competing with the coach rather than supporting it.

One insight, one CTA

A specific, data-driven prompt replaces the generic greeting. One action sits below it. Metrics move to a supporting position.

The screen has a single job.

Coach buried as a widget

No hierarchy between the AI coach and
everything else. The screen has no primary
job, resulting in a cluttered, list-heavy
interface that lacks focus.

Coach as frame, tips as feed

Right placement, wrong density. The AI greeting is generic and the health metrics below carry equal visual weight, competing with the coach rather than supporting it.

One insight, one CTA

A specific, data-driven prompt replaces the generic greeting. One action sits below it. Metrics move to a supporting position.

The screen has a single job.

Two decisions that defined the experience

Underneath the scope changes, two features did the real work of explaining what the product was for, with reducing the burden, not the ambition, as the guiding principle throughout.

👩🏻‍⚕️Doctor visit prep

This became the clearest articulation of what the product was actually for, and the feature that drew the strongest response when I tested the prototype.
The pre-visit checklist covers insurance card, medications, symptom timeline, and questions to ask, turning a stressful appointment into a structured preparation and giving the app a specific, high-stakes job to do at exactly the moment when being useful matters most.

Designing for engagement

The feature that surfaced from the research

The AI chat assistant was not in the original scope but came directly out of the competitive analysis: people had health data everywhere but nowhere to think out loud about what it meant. I scoped it to surface context-aware suggestions from existing health data, staying clearly within those bounds rather than attempting to replace medical advice.

Access mattered as much as the feature itself.
Mid-project testing showed users were scanning past the AI card to the metric tiles below it, so I designed a persistent ambient card at the top of the Coach screen that initiates conversation with a contextual prompt based on the user's data that day.

In the end-of-project round, four of five participants engaged with the AI card unprompted, and two said the opening message was what made the app feel different from a tracker. What testing couldn't tell me is whether that holds over time. A prompt that feels relevant on day one could feel repetitive by week three, and there was no runway left to find out.

From ambient prompt to full conversation.

From ambient prompt to full conversation.

What shipped


The end-of-project testing round confirmed the trimmed navigation was significantly easier to use: all five participants correctly identified what the Coach screen was for, against one of five in the mid-project round, and three of five completed the doctor visit prep flow without a wrong turn, against none in the first round. Doctor visit prep drew the strongest response in both rounds, with two participants in the second asking whether they could use a real version before their next appointment.
By the end, the work amounted to a full set of Figma screens and a working prototype, which is what carried the investor pitch.

I'm not going to overstate five people. What these sessions couldn't tell me is how the product performs across a wider range of health contexts, conditions, or health literacy. As a first read on whether the core direction works, the signal was clear enough to act on. The work was built toward an investor pitch; beyond that, the direction the company took was outside my involvement.

Reflection

This project sits close to what I find most interesting about product design: the work that happens before the pixels. Deciding what to build, and being rigorous about the order you build it in, shapes the user experience more than any interface decision does.

What stayed with me is how the scope conversation actually moved. It wasn't when I presented the research findings, or when I made the argument again with testing data behind it. It was when I sat a simplified navigation design next to the fuller one and let the two designs make the case. That single comparison did what months of conversation couldn't.











The turning point. Mid-project testing

The homepage was the clearest failure. Four of the five could not say what it was for after spending a minute with it. Two described it as "a dashboard," one called it "the notifications page," and one asked where the home screen was while already on it. Nobody mentioned the AI coach card unprompted, even though it sat at the top of the screen, because the metric tiles below it carried equal visual weight and won the attention race.

That was the evidence I had been missing.

Finding the right structure

The navigation went through four versions before it settled, all circling the same question: where does the coaching actually live?

Coach and MyHealth were doing the same job, so Coach absorbed MyHealth. Connect had no real feature behind it and came out. Challenges tested a gamified structure with streaks, but “challenge” read more like an obstacle than an invitation. It became Learning instead. What shipped is four tabs: Coach, Learning, My Data, My Doc. Each earned its place by surviving a version where it was tried and removed for a reason I could explain.

Two decisions that defined the experience

Underneath the scope changes, two features did the real work of explaining what the product was for, with reducing the burden, not the ambition, as the guiding principle throughout.

👩🏻‍⚕️Doctor visit prep

This became the clearest articulation of what the product was actually for, and the feature that drew the strongest response when I tested the prototype.
The pre-visit checklist covers insurance card, medications, symptom timeline, and questions to ask, turning a stressful appointment into a structured preparation and giving the app a specific, high-stakes job to do at exactly the moment when being useful matters most.

Finding the right structure

The Coach screen followed the same logic.

The first version was a feed trying to be every health touchpoint at once.
The second reduced the sections but the AI coach was still one item in a list rather than the reason to open the app.
The final version made the AI card the first thing a user sees, before any numbers, and the metrics moved to a supporting position below it. The screen went from a health dashboard with a chatbot attached to a coaching companion that happens to surface your data.

Finding the right structure

The feature that surfaced from the research

The AI chat assistant was not in the original scope but came directly out of the competitive analysis: people had health data everywhere but nowhere to think out loud about what it meant. I scoped it to surface context-aware suggestions from existing health data, staying clearly within those bounds rather than attempting to replace medical advice.

Access mattered as much as the feature itself.
Mid-project testing showed users were scanning past the AI card to the metric tiles below it, so I designed a persistent ambient card at the top of the Coach screen that initiates conversation with a contextual prompt based on the user's data that day.

In the end-of-project round, four of five participants engaged with the AI card unprompted, and two said the opening message was what made the app feel different from a tracker. What testing couldn't tell me is whether that holds over time. A prompt that feels relevant on day one could feel repetitive by week three, and there was no runway left to find out.

Coach buried as a widget

No hierarchy between the AI coach and
everything else. The screen has no primary
job, resulting in a cluttered, list-heavy
interface that lacks focus.

Coach as frame, tips as feed

Right placement, wrong density. The AI greeting is generic and the health metrics below carry equal visual weight, competing with the coach rather than supporting it.

One insight, one CTA

A specific, data-driven prompt replaces the generic greeting. One action sits below it. Metrics move to a supporting position.

The screen has a single job.

Coach buried as a widget

No hierarchy between the AI coach and
everything else. The screen has no primary
job, resulting in a cluttered, list-heavy
interface that lacks focus.

Coach as frame, tips as feed

Right placement, wrong density. The AI greeting is generic and the health metrics below carry equal visual weight, competing with the coach rather than supporting it.

One insight, one CTA

A specific, data-driven prompt replaces the generic greeting. One action sits below it. Metrics move to a supporting position.

The screen has a single job.

AWS Learning
Landed

What shipped

The end-of-project testing round confirmed the trimmed navigation was significantly easier to use: all five participants correctly identified what the Coach screen was for, against one of five in the mid-project round, and three of five completed the doctor visit prep flow without a wrong turn, against none in the first round. Doctor visit prep drew the strongest response in both rounds, with two participants in the second asking whether they could use a real version before their next appointment.
By the end, the work amounted to a full set of Figma screens and a working prototype, which is what carried the investor pitch.

I'm not going to overstate five people. What these sessions couldn't tell me is how the product performs across a wider range of health contexts, conditions, or health literacy. As a first read on whether the core direction works, the signal was clear enough to act on. The work was built toward an investor pitch; beyond that, the direction the company took was outside my involvement.

Reflection

This project sits close to what I find most interesting about product design: the work that happens before the pixels. Deciding what to build, and being rigorous about the order you build it in, shapes the user experience more than any interface decision does.

What stayed with me is how the scope conversation actually moved. It wasn't when I presented the research findings, or when I made the argument again with testing data behind it. It was when I sat a simplified navigation design next to the fuller one and let the two designs make the case. That single comparison did what months of conversation couldn't.

AWS Learning
Landed
Landed
AWS
Landed
AWS
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand
Brand

How this started

A founder came to me with a real problem and a lot of ambition. People manage their health across a scatter of disconnected tools:
a fitness app here, a patient portal there, notes and reminders somewhere else, none of them aware of the others. His answer was a single app that brought all of it together: tracking, coaching, learning, doctor visit preparation, an AI assistant. One place for everything.

It was a genuinely good instinct, since the fragmentation is real and worth solving. My job was to find the version of it that could actually ship with a small part-time team and no budget, and over the months that followed, that turned out to be a narrower question than where we started.

What the research showed

There was no budget for formal user research, so before opening Figma I did the work I could: a competitive analysis of the tools people already use to manage their health, and a close read of where each one breaks down.

The pattern was consistent. These products were not failing because they lacked features. They were failing because of fragmentation. Every tool owned a slice of the problem, and none of them held the whole picture.

One gap stood out specifically: people had health data everywhere but nowhere to think out loud about what it meant. The existing tools handed you raw numbers or sent you to a doctor, with nothing sitting in between that could watch your data and open a conversation about it.

All of this pointed toward simplicity and trust as the things most worth designing for, which was in direct tension with the roadmap.

Designing inside the tension

I made the case for a tighter scope early and kept making it, but the roadmap had its own gravity. The founder was attached to the full vision for understandable reasons: every feature on it existed because it solved something real, and there was no clean moment where everyone agreed to do less. Rather than push the argument further in the abstract, I built out the full experience the brief asked for.
Making the product tangible was the fastest route to a real conversation about what it needed to be.

The turning point. Mid-project testing

I ran a testing round with five people on the core flows.
The home screen was the clearest failure.
Four of the five could not say what it was for after spending a minute with it. Two described it as “a dashboard,” one called it “the notifications page,” and one asked where the home screen was while already on it. Nobody mentioned the AI coach card unprompted, even though it sat at the top of the screen, because the metric tiles below it carried equal visual weight and won the attention race.

That was the evidence I had been missing.

Finding the right structure

The navigation went through four versions before it settled, all circling the same question: where does the coaching actually live?
Coach and MyHealth were doing the same job, so Coach absorbed MyHealth. Connect had no real feature behind it and came out. Challenges tested a gamified structure with streaks, but “challenge” read more like an obstacle than an invitation. It became Learning instead. What shipped is four tabs: Coach, Learning, My Data, My Doc. Each earned its place by surviving a version where it was tried and removed for a reason I could explain.

Two decisions that defined the experience

Underneath the scope changes, two features did the real work of explaining what the product was for, with reducing the burden, not the ambition, as the guiding principle throughout.

👩🏻‍⚕️Doctor visit prep

This became the clearest articulation of what the product was actually for, and the feature that drew the strongest response when I tested the prototype. The pre-visit checklist covers insurance card, medications, symptom timeline, and questions to ask, turning a stressful appointment into a structured preparation and giving the app a specific, high-stakes job to do at exactly the moment when being useful matters most..

The Coach screen followed the same logic.

The first version was a feed trying to be every health touchpoint at once.
The second reduced the sections but the AI coach was still one item in a list rather than the reason to open the app.
The final version made the AI card the first thing a user sees, before any numbers, and the metrics moved to a supporting position below it. The screen went from a health dashboard with a chatbot attached to a coaching companion that happens to surface your data..

Coach buried as a widget

No hierarchy between the AI coach and
everything else. The screen has no primary
job, resulting in a cluttered, list-heavy
interface that lacks focus.

Coach as frame, tips as feed

Right placement, wrong density. The AI greeting is generic and the health metrics below carry equal visual weight, competing with the coach rather than supporting it.

One insight, one CTA

A specific, data-driven prompt replaces the generic greeting. One action sits below it. Metrics move to a supporting position.

The screen has a single job.

The feature that surfaced from the research

The AI chat assistant was not in the original scope but came directly out of the competitive analysis: people had health data everywhere but nowhere to think out loud about what it meant. I scoped it to surface context-aware suggestions from existing health data, staying clearly within those bounds rather than attempting to replace medical advice.

Access mattered as much as the feature itself.
Mid-project testing showed users were scanning past the AI card to the metric tiles below it, so I designed a persistent ambient card at the top of the Coach screen that initiates conversation with a contextual prompt based on the user's data that day.

In the end-of-project round, four of five participants engaged with the AI card unprompted, and two said the opening message was what made the app feel different from a tracker. What testing couldn't tell me is whether that holds over time. A prompt that feels relevant on day one could feel repetitive by week three, and there was no runway left to find out.

The feature that surfaced from the research

The AI chat assistant was not in the original scope but came directly out of the competitive analysis: people had health data everywhere but nowhere to think out loud about what it meant. I scoped it to surface context-aware suggestions from existing health data, staying clearly within those bounds rather than attempting to replace medical advice.

Access mattered as much as the feature itself.
Mid-project testing showed users were scanning past the AI card to the metric tiles below it, so I designed a persistent ambient card at the top of the Coach screen that initiates conversation with a contextual prompt based on the user's data that day.

In the end-of-project round, four of five participants engaged with the AI card unprompted, and two said the opening message was what made the app feel different from a tracker. What testing couldn't tell me is whether that holds over time. A prompt that feels relevant on day one could feel repetitive by week three, and there was no runway left to find out.

What shipped

The end-of-project testing round confirmed the trimmed navigation was significantly easier to use: all five participants correctly identified what the Coach screen was for, against one of five in the mid-project round, and three of five completed the doctor visit prep flow without a wrong turn, against none in the first round. Doctor visit prep drew the strongest response in both rounds, with two participants in the second asking whether they could use a real version before their next appointment.
By the end, the work amounted to a full set of Figma screens and a working prototype, which is what carried the investor pitch.

I'm not going to overstate five people. What these sessions couldn't tell me is how the product performs across a wider range of health contexts, conditions, or health literacy. As a first read on whether the core direction works, the signal was clear enough to act on. The work was built toward an investor pitch; beyond that, the direction the company took was outside my involvement..

Reflection

This project sits close to what I find most interesting about product design: the work that happens before the pixels. Deciding what to build, and being rigorous about the order you build it in, shapes the user experience more than any interface decision does.

What stayed with me is how the scope conversation actually moved. It wasn't when I presented the research findings, or when I made the argument again with testing data behind it. It was when I sat a simplified navigation design next to the fuller one and let the two designs make the case. That single comparison did what months of conversation couldn't.