





The mobile problem was framed as user preference. Traffic data showed differently, so I redesigned the app and proved it wasn’t.
Trove Brands is an e-commerce group that owns and operates multiple e-commerce brands like Blender Bottle, Canoo, and Oath Nutrition as well as the award-winning brand Owala®.
Owala® is a leading water bottle e-commerce brand that is known for its innovation.
Integrate a 3rd party customizer into the Owala site that allows customers to personalize their water bottles.
As the Principal UX Designer I did all the research, design and project management for the development of the solution.
I partnered with the Digital Marketing Director, who coordinated with fulfillment companies and hired the third-party vendor.
82% of Owala's traffic is on mobile devices. The third-party platform projected the customizer would only capture a third of that on mobile. At launch, customizer mobile traffic matched the site's overall mobile traffic, closing the gap entirely.
Ten months after launch, the customizer had driven a 2x increase in sales. Customers loved to personalize their bottles, increasing the average cart total. Almost half of all sales included personalizations.
As we kicked off the project, the vendor gave us wireframes of their customizer to style. As I reviewed them, I had some concerns.

Cluttered and unorganized editing functions cause users to have to think more.
Small text and small buttons create small touch targets.
The small viewing area creates a challenge to be able to see the artwork effectively.
What works on a desktop does not work on a small mobile device.
When the vendor was pressed on why this was not designed ‘mobile first’, they explained that their data showed that users typically switch from the mobile version to desktop to use the application.
“...users prefer to use the customizer on desktop over the mobile version...”
Our traffic patterns for the Owala brand showed that customers predominantly used mobile devices to shop. If users had to switch from their mobile phones to a desktop it would negatively affect the adoption of this customizer.
total traffic is on a mobile device
How might we...
design the mobile app so customers don’t have to switch to the desktop version?
With a new objective set, we set off to figure out how we might improve the mobile experience. We started with a competitive audit to establish a benchmark and find our competitive edge, and identifying conventional patterns inspired new ideas.



Owala wasn’t the only brand offering bottle customization. As I audited competing customizers, it was clear this was not an easy problem to solve.
The customizers also struggled with:
A number of apps already handle complex editing on mobile and prove it can work well. Two examples stood out that I drew inspiration from, giving me confidence that we could build something that worked just as well.
Conventional mobile interaction patterns:

As ideas emerged from sketching and prototyping, I worked to test and validate directions that would inform decision making and project direction.

Immersive Tattoo Parlor

Accent Background Color
Stakeholders and marketing wanted to see the bottle in a tattoo parlor to match the campaign for the new customizer, so I prototyped the idea.
After testing it, here’s what I learned:
One idea that proved to be truly intuitive was allowing users to directly manipulate the artwork, but it was unsupported. I tested an alternative option that kept the project on time.
Direct manipulation patterns were proving to be the most intuitive solution for editing designs for the bottle. Because the platform didn’t support it, I brought the team a decision: push out the launch to develop it, or launch on time with less intuitive patterns.
These are the things we considered:

Shipping a good experience on time beat shipping a better one late.
Working through technical constraints and refining mobile patterns, I felt confident that this solution was going to be great. As we developed and tested the solution, the feedback was overwhelmingly positive.

What I’m proudest of here isn’t the metrics, it’s the diagnostic. The mobile gap wasn’t a user preference problem. It was a design problem that looked like a user preference problem. Reframing that, finding the right pattern language to solve it, and shipping it within three months is the kind of work that reminds me why I do this.
Performance metrics are a signal of a problem. They rarely explain user preference.
When we soft-launched the customizer, we knew we had achieved what we set out to do: users no longer switched from mobile to desktop to use it. Mobile traffic never tapered off. Success!
82% of Owala's traffic is on mobile devices. The third-party platform projected the customizer would only capture a third of that on mobile. At launch, customizer mobile traffic matched the site's overall mobile traffic, closing the gap entirely.
Ten months after launch, the customizer had driven a 2x increase in sales. Customers loved to personalize their bottles, increasing the average cart total. Almost half of all sales included personalizations.
Launch wasn’t the finish line. Staying forward deployed after release meant owning what came next: the customizer’s influence across the industry, and the edge cases that only surface in the real world.

After a year of our customizer setting the standard for customizers, competing brands like Yeti and Stanley started to adopt similar patterns.
We built a word moderator to screen out inappropriate text on custom bottles. What we hadn’t anticipated was that certain flagged words overlap with surnames from other cultures. It wasn’t a large volume of users, but for those affected it was a frustrating and at times distressing experience, and complaints surfaced quickly.
It was a humbling reminder that content moderation decisions have real human impact, and that building an inclusive list requires more cultural consideration than a basic blocklist.
During QA, I noticed that low-quality uploaded images weren’t rendering as expected in the final printed output. The issue turned out to be a file translation problem inside Spectrum’s pipeline: the image we were showing users as a digital proof wasn’t the same file being sent to the printer.
This was caught because I spent real time testing the experience as a user would, not just checking that buttons worked, but interrogating the actual output quality end to end. Catching it pre-launch avoided what would have been a significant return rate and a credibility hit for a brand that had positioned this as a premium product.
Reframed a metric as a hypothesis to test, not a fact to accept, then traced it to a root cause through competitive and pattern research.
Made tradeoff calls under real platform, timeline, and brand limits, validated with users, not assumed, and still hit the target.
First UX hire, no playbook, no dedicated PM. I drove alignment through process and caught a misdiagnosed problem that resulted in an industry standard for e-commerce customizers.
Making sense of complex health data is not easy. Using AI product frameworks, I transform complex data into sustained behavioral change.
Live Tula is a metabolic-health program that helps people reverse chronic conditions like Type 2 diabetes through sustainable behavior change. Members get a care team of coaches, nurses, and dietitians, a meal planner and tracker, and health metrics integrated from smart wearables. This project introduced Tulani AI, an in-app companion that turns those metrics into personal insights.
As Live Tula’s sole designer, I reported to the President. I owned the problem framing, research, and end-to-end design of Tulani AI. I partnered with the AI Architect on feasibility and constraints, and with the Head of Strategic Alignment on priorities and capacity. When the first redesign did not move engagement, I pushed the team to go back to members and coaches before building more, which changed the direction of the project.
Members started strong, tracking sleep, activity, glucose, and meals. After about 4 weeks, most of them stopped engaging.
Measured across 1,000 early adopters over 3 months.
Companies that offer Live Tula as a health benefit see this impact after the first year.
From opt-in to action, this is how a member uses Tulani AI to turn their own health data into a next step, with their care team still in the loop.

Members choose to turn on Tulani AI and see exactly which data it can access.
One tap creates an insight. No prompt writing needed.
Targeted questions narrow in on the insight that matters most.
Takeaways turn the insight into a clear next step.
References show the exact data behind every insight.
Members were dropping off, and the team assumed better charts and easier logging would fix it. After we shipped the new designs, engagement stayed flat. That told me the problem was not the interface.
The team agreed the fix was to make the data more visually engaging and make logging easier, so I designed that experience first. I focused on:

Result of the redesign
After 10 weeks, engagement stayed flat. The problem was not the interface.
When the redesign did not improve retention, I needed to understand why. I built two surveys: one for the health coaches who work with members every day, and one for members.
I surveyed 15 health coaches and 25 members to understand why engagement dropped.
I used Airtable to house and synthesize the responses, and its AI features to surface common themes and outliers in minutes instead of the days manual synthesis would have taken.
A significant number of members described the same gap: they could see their data, but did not know what to do with it.

Reframed Problem Statement
Members were collecting data they could not interpret, so tracking stopped feeling worth it.
Members did not see enough value in tracking their health metrics. I needed to design a feature that helps members turn their own data into behavior change.
Was AI a good fit for this problem?
To answer that, I used a framework taught by NN/g for deciding when a co-intelligent solution is the right fit. You identify the core of the problem, then map it to one of the 4 ways AI can help.
Our problem mapped to Volume and Expertise: members had more data than they could read, and not enough expertise to interpret it. That pointed to Help Me Understand, which made AI a strong fit.
Step 1
Each problem statement maps to at least one of these 6 categories.
Step 2
AI can help with 4 different user goals.
When building a co-intelligent solution, it is important to understand how members will perceive it. Our members were most likely to treat Tulani AI as an Oracle: an authority that gives answers. In a health context, an authority that is wrong is risky, so every insight needed to show its sources and point members back to their care team.
Users see the AI as an authority, not a collaborator. They expect definitive answers and want to know where the information comes from.
This archetype shows up when your product is perceived as an expert: research tools, Q&A products, anything presenting knowledge rather than options.
'You ask. It pronounces.'
Users bring healthy skepticism. They know the model can be wrong and expect to review its output before trusting it.
This archetype shows up in meeting transcription, writing assistants, and tools that take monotonous, time-intensive work off users' hands.
'Eager. Fallible. Needs Supervision.'
Users see the AI as a partner in the work, not a source or a servant. It helps them produce better output by filling gaps and offering insight along the way.
Products matching this archetype use permission gates and planning modes, and ask clarifying questions before proceeding.
'Peer. Plans together. Asks before acting.'
Before designing, I used the Jobs To Be Done framework to understand the full scope of what this feature needed to do. Mapping the Four Forces was the most influential part, because each force pointed to a specific design response.
Data piling up with no payoff. Members track daily, then ask: now what?
Design response: insights with clear Takeaways, so every check-in ends with a next step.
Personalized answers on demand, with immediate gratification and a sense of ownership over their health.
Design response: one-tap generation that returns a personal answer in seconds.
Can I trust AI with my health data? What if it's wrong?
Design response: explicit opt-in, data access transparency, and auditable References.
Passive tracking is comfortable. Questioning your own data is a new behavior that takes too much effort or understanding.
Design response: no prompt writing, plus guided follow-up questions that do the questioning for members.
* The Four Forces surfaced our biggest challenge: trust.
How might we foster TRUST in this co-intelligent companion?
Health data is sensitive. Explicit opt-in, transparent data access, and clear controls are non-negotiable design requirements before any AI can see a member’s personal metrics.
Users’ default response to AI systems is healthy skepticism, and rightly so. To support feature adoption and maintain HIPAA compliance, users must explicitly enable and opt in to Tulani AI before the system can access any of their personal health data.
Trust is built before the first insight is ever generated.


The biggest challenge in implementing AI is helping members feel comfortable letting a system access sensitive personal data. Trust that the system handles that data responsibly is essential, and transparency is the primary tool for earning it. Members can see exactly which data Tulani AI uses and can turn it off at any time.
Because Tulani AI’s outputs are language-based insights, the system needs to meet members where they are. Responses that feel too clinical or detached can alienate the very people the product is trying to support. We added response settings that let members adjust the tone and language complexity of their insights, so the experience stays encouraging, readable, and light on cognitive load. Members can also recall past insights to see their progress over time.

Writing effective prompts is a skill most members don’t have. One-click generation removes the cognitive burden while guided follow-up questions help surface what’s actually useful.
Our research showed that members lacked the domain expertise to prompt an AI model effectively, so complex health data would go uninterpreted and the feature would go unused. To minimize the learning curve, we designed a one-click generation experience that removes the need to know what to ask. When the AI needs more context, it asks targeted questions about which insights would be most useful, guiding members toward better outputs without requiring them to understand how the model works. This mattered most for older members and members less comfortable with technology.


When exploring how members would start generating insights, we considered a conversational UI and a simpler, structured interaction model.
Conversational UI did not fit because:
One tap. No prompt-writing skills needed. Actionable, reliable insights in minutes.
The model can generate unhelpful or inaccurate responses. In a health context, eroding trust is particularly costly. Takeaways and auditable references were designed to let members verify the basis of any insight.
To align responses with the Live Tula program, we used retrieval-augmented generation (RAG) to ground the model in the Tula 10: a proprietary, 100+ page document outlining the 10 principles that guide all care. These principles provided guardrails for the model’s responses. The model also referenced health goals set by health coaches to ensure each response supported those goals.
As an extra layer, and to keep a human in the loop, health coaches, nurses, and dietitians reviewed responses. This ensured that every response lived up to the standards of the Live Tula program.

Every response includes a Takeaways section with actionable next steps and a References section where members can audit the exact data points behind the insight, making the AI’s reasoning visible and verifiable.
To balance data thresholds and token costs, I designed graceful states that never lead members to a dead end, with clear and specific microcopy.
AI tokens are expensive, so limiting how many each member can use is essential for managing costs at scale. Exact pricing depends on the model and data volume. We set a limit of 1 insight per member per month. I also designed the state where a member runs out of tokens, so they always understand what happened.


When a member hasn’t logged enough health data to generate an insight, graceful error states explain the limit and suggest how to keep going.
When I left the project, Tulani AI was with early adopters. These are the open questions I would tackle next.
Early adopters used an interim model. Choosing the long-term model was still open. Next, I would compare models on cost, response quality, and reliability using a shared set of real member scenarios.
We had confirmed we were designing the right thing. Next, we needed to confirm we designed it right. Engagement was increasing, but we had not yet circled back with qualitative research. My next step would be follow-up interviews with early adopters and coaches.
HIPAA does not include AI-specific guidelines. During BAA negotiations we would need to define contracts, safeguards, and clear boundaries around what data the AI can access and whether any retention is permitted.
Every member has a different threshold for how much data they are willing to enter manually, and food logging is the most demanding example. Next, I would test the minimum data Tulani AI needs to generate meaningful insights.
Validated the data-overload problem through coach and member surveys before touching AI. Applied the JTBD Four Forces to understand adoption dynamics, not just user desire.
Balanced member and coach needs against model constraints, compliance requirements, and cost-aware token design, not just what is technically possible.
One-click generation, guided inputs, plain language, and auditable references. AI that works for members managing a chronic condition, not just for people comfortable with technology.
Prioritized key features to align with business goals, leading to a 20% growth in new accounts and improved customer satisfaction scores.
A luxury skincare brand was growing but wasting design time on wrong priorities. We reprioritized the roadmap, leading to improvements in bounce rates, cart abandonment, and user signups, proving that knowing what to design is crucial.
Glymed+ is a luxury professional skincare brand that sells through licensed skincare pros. Every customer is connected to a Pro, the distributor who recommends and supplies their products. The brand was already growing every year, so this project was about making sure limited design time went to the work that moved the business.
I was the agency designer on Glymed+, with 10 hours a week on the product. I partnered with our agency PM and worked directly with Glymed’s President, Vice President. I facilitated the objectives workshop, built the scoring model with the team, and designed the signup, cart, and profile improvements.
Priorities were dictated by subjective opinions, and there was no established method of measuring the performance of Glymedplus.com
A clearer signup and Find a Pro flow, tracked with A/B tests.
An anonymous cart and a streamlined checkout made ordering easier.
The Product Owner and stakeholders used a simplified MoSCoW method to prioritize the roadmap. I started down that list, fixing the Profile, Settings, and notifications. The UI got better, but one question kept coming up: was this making any difference?
The settings page and rewards obviously needed a rework just by looking at it. I focused on adding clear editing paradigms, better hierarchy and organization. Improving the mobile version was essential as well, since most traffic was on mobile.
While this did not have a direct impact on the bottom line, I believe it was essential.

Was this making a difference?
It was hard to know what was working and what wasn’t without measuring the performance of the site. I worked with the PM and engineering to establish tracking hooks and an analytics tool.
Quantitative data provides a measurable baseline for evaluating performance, which was essential for the A/B testing that followed.
KPIs established for measurement:
Industry benchmarks, not site results
I ran a small off-site workshop with the President, Vice President, and Product Owner, using an affinity map to surface the biggest pain points, which we converted into objectives.

Working with the team, we listed out all pain points. These came from customer reviews, complaints from distributors, business needs, and KPIs that were underperforming.
In identifying groupings, we worked to discover common themes and not just related or duplicates.
We voted on significant themes that seemed most impactful. The vote was essential for getting consensus on the objectives.
The highest ranking themes became the objectives.
As a team, we identified three major themes that became our objectives. They were based on the biggest pain points we identified for the platform. Objectives commonly align with these 3 KPIs: acquisition, adoption, and retention.
Product discovery was low; customers relied on distributors to add items. Shoppers needed help understanding products and their benefits. High bounce rates on product pages indicated shoppers needed clarity before buying.
High bounce rates & low conversion & discovery
The checkout flow was complicated and required users to sign in. There was no cart caching, and checkout was not anonymous.
Cart abandonment & reorder rate
A complex distribution model was not conventional and the mental model was hard to grasp from the UI. Every customer has to be associated with a Pro. The Add a Pro step in signup had a high bounce rate.
Find a Pro bounce rate & signup abandonment
With the objectives set, the next step was a scoring method to rank each feature by the impact it would make.
Each roadmap item got a t-shirt size score for each of the three objectives, based on how much it would move that objective.
We added the scores together, and the totals became the new priority order.
Proposed scores · 2 = Low · 4 = Moderate · 8 = High alignment
Focus on business initiatives, and replace opinions with a score to prioritize the roadmap.
A good product team balances three needs: user needs, business needs, and development needs. Once the roadmap followed our objectives, we shipped UI changes against them and used A/B tests through a CRO tool to find the best solutions.

The long form of the original signup page had a high bounce rate. It was also clear from customer feedback that they didn’t know if they were signing up under the right distributor. So I focused on:
Glymed+ highly recommends that all customers be associated to a distributor, so customers who came to Glymed+ without a recommendation were failing to understand why they needed one. So I focused on:


When auditing the checkout and signup flows, I discovered an opportunity to add anonymous checkout and cached carts for browsing customers. The product details page also had opportunities to increase clarity about the product and convert better.
Product Owner, Glymed+
“Being focused on those objectives, we’ve seen positive growth. More than we hoped for.”
Since we have aligned on these objectives, we implemented a few UI changes to improve these experiences. We have also implemented an A/B testing method through a CRO tool to identify the best solutions. We have already seen incremental improvements in bounce rates, cart abandonment, and user signup.
I frequently shared this Venn diagram. It shows how a good product team has three needs. User Needs, Business Needs, and Development Needs. The sweet spot is when all these needs converge. Product teams are successful when they work on things that solve problems for their users, help market the product, and are feasible.
While you hope every project creates positive change, improving one area often exposes a vulnerability in another. At Glymed+ we wanted to make it easier for customers to purchase on the site, and as we did, other challenges surfaced.
As we reduced friction in the signup flow, we saw an increase in fraudulent orders. These orders were being placed by bots and scammers. Engineering turned their focus toward this security issue once it was discovered, and orders were canceled.
Distributors get a portion of all sales that come through the Glymed+ site. So when they learned that anonymous orders could be placed, they were worried it would affect their sales numbers, since a new path for purchasing was introduced that did not require a distributor.
Moved a single designer’s 10 weekly hours from fixing what was broken to building what moved the business.
Replaced subjective labels with a scoring model tied to measurable objectives the leadership team agreed on.
Shipped signup, cart, and Find a Pro improvements that lowered bounce and cart abandonment and grew new accounts.