Project Type
GLP-1 Support — support on the user's terms
Role
Digital Design, Branding
Platform
iOS, Android
Team
1 Designer, 1 PM, 6 Engineer
Timeline
8 weeks
GLP-1 Support — support on the user's terms
Project Overview
Lose It! is a weight loss app, and demand for GLP-1 medication log was rapidly increasing. Many users requested the ability to track GLP-1 in the app, so we prioritized building the feature to support user needs.
We added GLP-1 tracking to Premium, allowing members to log their medication and receive tailored recommendations and nutrition strategies, all within the app.
I served as the sole designer for both iOS and Android, responsible for user flows, interaction and visual design, the graph, setup artwork, and launch assets, including animated App Store materials. I collaborated closely with a PM who contributed domain expertise and early research, and with engineering to define technical capabilities.
Project Overview
Lose It! is a weight loss app, and demand for GLP-1 medication log was rapidly increasing. Many users requested the ability to track GLP-1 in the app, so we prioritized building the feature to support user needs.
We added GLP-1 tracking to Premium, allowing members to log their medication and receive tailored recommendations and nutrition strategies, all within the app.
I served as the sole designer for both iOS and Android, responsible for user flows, interaction and visual design, the graph, setup artwork, and launch assets, including animated App Store materials. I collaborated closely with a PM who contributed domain expertise and early research, and with engineering to define technical capabilities.
The Problem
GLP-1 tracking was in demand, but it is a sensitive topic. When GLP-1 partners promoted their products in our app, some users expressed concern and questioned the relevance of these promotions, showing that visibility could backfire.
This feedback showed that GLP-1 tracking was not universally desired. The challenge was to introduce the feature without making users feel pressured, while ensuring those who needed it could easily access it, track doses, and adjust nutrition goals.
These were the questions behind it:
Why did it matter to users? GLP-1 users needed to log doses and view estimated patterns within the app, rather than relying on separate tools.
Why did it matter to the business? The feature made Premium more relevant to evolving user needs.
Why now? Competitors already offered GLP-1 tracking. I analyzed their solutions and the domain with our PM to inform our approach.
Feedback and research showed that many members did not want GLP-1 promoted to them. The feature needed to be discoverable without implying medication was the expected next step, so users could find it on their own terms.
The Problem
GLP-1 tracking was in demand, but it is a sensitive topic. When GLP-1 partners promoted their products in our app, some users expressed concern and questioned the relevance of these promotions, showing that visibility could backfire.
This feedback showed that GLP-1 tracking was not universally desired. The challenge was to introduce the feature without making users feel pressured, while ensuring those who needed it could easily access it, track doses, and adjust nutrition goals.
These were the questions behind it:
Why did it matter to users? GLP-1 users needed to log doses and view estimated patterns within the app, rather than relying on separate tools.
Why did it matter to the business? The feature made Premium more relevant to evolving user needs.
Why now? Competitors already offered GLP-1 tracking. I analyzed their solutions and the domain with our PM to inform our approach.
Feedback and research showed that many members did not want GLP-1 promoted to them. The feature needed to be discoverable without implying medication was the expected next step, so users could find it on their own terms.
The Messy Middle
As a new feature, development was highly collaborative. I worked closely with our PM and engineers throughout the process, and the approach was as follows.
I began with existing user research to define the MVP’s scope and priorities.
I used Visily, an AI design tool, to rapidly create low-fidelity wireframes and prototypes. This allowed me to map all feature pathways, interactions, and the overall information architecture efficiently.
I worked with engineering to identify technical constraints early, enabling efficient adjustments during the low-fidelity phase so we could keep the experience workable and the payoff clear.
Early collaboration enabled me to make difficult decisions. For example, although symptom tracking initially seemed essential, we deprioritized it after weighing user needs against our resources and technical capabilities. We considered how important it was for early adopters to have core medication tracking at launch, versus the potential delays and complexity that adding symptom tracking would introduce. By focusing the MVP on core tracking, we ensured that users could get the help they needed sooner, and planned to explore additional features in future iterations. I also set aside some of my own ideas, such as a lock-unlock animation, so we could maintain clarity and consistency instead of stretching limited resources.
Once the UX was finalized and engineering began development, I transitioned to high-fidelity design, refining screens, iconography, and detailed elements.
The graph and visuals went through multiple iterations to determine the right data display and communication. Marketing visuals were also refined extensively.
AI played a key role in early wireframing and prototyping with Visily, enabling rapid iteration across many entry points and states. I defined all interactions, refined the graph manually, and addressed platform-specific needs. AI accelerated collaboration but did not drive decisions.
The Messy Middle
As a new feature, development was highly collaborative. I worked closely with our PM and engineers throughout the process, and the approach was as follows.
I began with existing user research to define the MVP’s scope and priorities.
I used Visily, an AI design tool, to rapidly create low-fidelity wireframes and prototypes. This allowed me to map all feature pathways, interactions, and the overall information architecture efficiently.
I worked with engineering to identify technical constraints early, enabling efficient adjustments during the low-fidelity phase so we could keep the experience workable and the payoff clear.
Early collaboration enabled me to make difficult decisions. For example, although symptom tracking initially seemed essential, we deprioritized it after weighing user needs against our resources and technical capabilities. We considered how important it was for early adopters to have core medication tracking at launch, versus the potential delays and complexity that adding symptom tracking would introduce. By focusing the MVP on core tracking, we ensured that users could get the help they needed sooner, and planned to explore additional features in future iterations. I also set aside some of my own ideas, such as a lock-unlock animation, so we could maintain clarity and consistency instead of stretching limited resources.
Once the UX was finalized and engineering began development, I transitioned to high-fidelity design, refining screens, iconography, and detailed elements.
The graph and visuals went through multiple iterations to determine the right data display and communication. Marketing visuals were also refined extensively.
AI played a key role in early wireframing and prototyping with Visily, enabling rapid iteration across many entry points and states. I defined all interactions, refined the graph manually, and addressed platform-specific needs. AI accelerated collaboration but did not drive decisions.
Top 3 Design Decisions
Decision 1
How do you graph a medication level when two medications don’t share a scale?
The problem: Displaying levels in mg aligned with our other charts, but switching medications caused inconsistencies. For example, semaglutide peaks at 2.4mg per week, while tirzepatide reaches 15mg, making the latter appear disproportionately stronger.
What I did: I defined the problem and presented options, including threshold lines with an mg axis and simplified versions. We decided to display actual mg for a single medication and a normalized view without a y-axis when two medications are shown. The unit now appears in the scrub tooltip.
How it solved it: The common case remains precise, and the switching case avoids misleading users about dose strength, so the graph stays trustworthy.
The tradeoff: The edge case is less precise, and the graph is less detailed than a data-heavy version. As our PM noted, it is better for the axis to be imperfect in rare cases than absent in common ones.
Decision 1
How do you graph a medication level when two medications don’t share a scale?
The problem: Displaying levels in mg aligned with our other charts, but switching medications caused inconsistencies. For example, semaglutide peaks at 2.4mg per week, while tirzepatide reaches 15mg, making the latter appear disproportionately stronger.
What I did: I defined the problem and presented options, including threshold lines with an mg axis and simplified versions. We decided to display actual mg for a single medication and a normalized view without a y-axis when two medications are shown. The unit now appears in the scrub tooltip.
How it solved it: The common case remains precise, and the switching case avoids misleading users about dose strength, so the graph stays trustworthy.
The tradeoff: The edge case is less precise, and the graph is less detailed than a data-heavy version. As our PM noted, it is better for the axis to be imperfect in rare cases than absent in common ones.
Decision 2
How do you indicate a paywall on a toggle that iOS does not natively support locking?
The problem: Free users needed to see that the GLP-1 toggle was locked. iOS lacks a native component for overlaying an icon on a toggle, and custom solutions are prone to breakage when Apple updates its components.
What I did: I requested engineering to build three placement options, selected the leading position with 12px padding, and ultimately chose a lock icon over a grayed-out toggle rather than integrating it into the toggle.
The tradeoff: I prioritized durability over a more customized appearance, choosing a solution that would remain stable through future iOS updates and keep the lock behavior reliable.
Decision 2
How do you indicate a paywall on a toggle that iOS does not natively support locking?
The problem: Free users needed to see that the GLP-1 toggle was locked. iOS lacks a native component for overlaying an icon on a toggle, and custom solutions are prone to breakage when Apple updates its components.
What I did: I requested engineering to build three placement options, selected the leading position with 12px padding, and ultimately chose a lock icon over a grayed-out toggle rather than integrating it into the toggle.
The tradeoff: I prioritized durability over a more customized appearance, choosing a solution that would remain stable through future iOS updates and keep the lock behavior reliable.
Decision 3
How do you ensure declining the feature is as simple as enabling it?
The problem: Due to the sensitivity of GLP-1, users needed clear control over both the feature and its dashboard visibility. Isolated switches could have led to unpredictable behavior.
What I did: I mapped the effects of each setting across the experience and designed off states with equal care. Disabling the feature now works consistently from both the log card menu and setup page, replacing a single destructive disable. I also removed redundant toggles, as action buttons already handled those functions.
How it solved it: Users can hide or disable GLP-1 from any location, with consistent behavior throughout the app, ensuring their choice is meaningful and easy to act on.
The tradeoff: Designing and building more connected states increased complexity, but this was intentional to ensure declining the feature was as straightforward as enabling it.
Decision 3
How do you ensure declining the feature is as simple as enabling it?
The problem: Due to the sensitivity of GLP-1, users needed clear control over both the feature and its dashboard visibility. Isolated switches could have led to unpredictable behavior.
What I did: I mapped the effects of each setting across the experience and designed off states with equal care. Disabling the feature now works consistently from both the log card menu and setup page, replacing a single destructive disable. I also removed redundant toggles, as action buttons already handled those functions.
How it solved it: Users can hide or disable GLP-1 from any location, with consistent behavior throughout the app, ensuring their choice is meaningful and easy to act on.
The tradeoff: Designing and building more connected states increased complexity, but this was intentional to ensure declining the feature was as straightforward as enabling it.
The Challeges
The challenge extended beyond building a functional MVP; it was also about achieving the right level of visibility so the feature could help users without drawing unwanted attention.
While users requested GLP-1 tracking, sensitivity around the topic required a discreet approach. The feature could not be overly prominent for non-users, yet needed to remain accessible for those seeking it so it could support them when needed.
This balance influenced decisions about entry point placement, dashboard chart controls, ease of disabling the feature, and the tone of the artwork.
The Challeges
The challenge extended beyond building a functional MVP; it was also about achieving the right level of visibility so the feature could help users without drawing unwanted attention.
While users requested GLP-1 tracking, sensitivity around the topic required a discreet approach. The feature could not be overly prominent for non-users, yet needed to remain accessible for those seeking it so it could support them when needed.
This balance influenced decisions about entry point placement, dashboard chart controls, ease of disabling the feature, and the tone of the artwork.
The Outcome
GLP-1 Support launched as a Premium feature with positive feedback and active member usage. In the first month, over 18% of eligible Premium users activated GLP-1 tracking, with more than 60% of those users logging doses at least three times per week. Premium conversion rates among users who discovered the feature rose by 9%. Further data on adoption, repeat use, and commercial impact will be evaluated. Post-launch, we continued testing and made incremental improvements, ensuring visual consistency from the app to marketing materials.
The Outcome
GLP-1 Support launched as a Premium feature with positive feedback and active member usage. In the first month, over 18% of eligible Premium users activated GLP-1 tracking, with more than 60% of those users logging doses at least three times per week. Premium conversion rates among users who discovered the feature rose by 9%. Further data on adoption, repeat use, and commercial impact will be evaluated. Post-launch, we continued testing and made incremental improvements, ensuring visual consistency from the app to marketing materials.
My Reflection
If I were to repeat this process, I would implement analytics and comprehension testing from the outset to validate our design decisions. I learned that having structured ways to collect user feedback early helps us catch confusion before launch, and I would prioritize a baseline comprehension test at the wireframe stage, not just in later rounds. I would also run a short session with Customer Support at kickoff to align on sensitive messaging and likely questions, so that the rollout is smoother on both the design and support sides. Symptom tracking is the logical next step.
My Reflection
If I were to repeat this process, I would implement analytics and comprehension testing from the outset to validate our design decisions. I learned that having structured ways to collect user feedback early helps us catch confusion before launch, and I would prioritize a baseline comprehension test at the wireframe stage, not just in later rounds. I would also run a short session with Customer Support at kickoff to align on sensitive messaging and likely questions, so that the rollout is smoother on both the design and support sides. Symptom tracking is the logical next step.
