bonza • Product • 2025
The world's first AI dog nutritionist
TIMELINE
3 months
ROLE
Product Designer (Me!)
TEAM
Designers
Developers
Manager
QA Team
Overview
What if a dog's meal plan didn't just get calculated once, but kept adjusting as the dog actually changed?
Every dog meal-plan subscription today works the same way: a short quiz (breed, age, weight, activity, health flags) feeds a formula, the formula spits out a fixed daily portion and recipe, and that's it, he plan stays static until the owner manually edits it months later. The quiz is smart. The relationship after checkout is not.
Bonza is a concept for a dog meal-plan subscription where the onboarding quiz is only the starting point for the AI, not the final answer. The AI keeps refining the plan using signals the owner already has easy access to, weight check-ins, leftover food, stool quality, energy level, so the portion and recipe adjust the way a good vet nutritionist would, without the owner having to ask.
↑ 395%
Feature discoverability
↑ 64%
App logins
↓ 29%
Customer calls
SOLUTION
A 5-step onboarding quiz that hands off to an AI that keeps working after checkout.
Bonza's current calculator is deterministic: quiz answers go into a formula, a portion and recipe come out once, at signup. Here's the same 5-step flow, with what an AI layer adds at each stage.
About your dog
Owner enters the dog's name, sex, and basic profile. Purely identity, no calculation happens yet, but this is what personalizes every screen and message that follows (e.g. "Bella's daily portion" instead of "your dog's daily portion").
Breed and age
Owner enters breed and date of birth. This sets the calorie baseline, age changes how many calories a dog burns, so it shifts the daily portion more than most owners expect.
Size, shape, and activity
Owner enters current weight, body condition ("a little thin" / "ideal" / "carrying a bit extra"), and daily exercise. This adjusts the calorie baseline up or down from Page 2's starting point.
Health
Owner ticks any relevant condition tags, joints and mobility, digestion, weight management, anxiety, etc. This doesn't change the calorie number, but it steers which ingredients the recipe prioritizes and can trigger a "worth speaking to your vet" note for higher-stakes conditions.
Current food
Owner logs what the dog eats now (kibble, wet food, home cooked, raw) and what share of the diet Bonza should cover (25/50/75/100%). This is used for transition planning and bag-size sizing, not the core calculation.
Result page
where the AI first shows up All five pages feed an AI model instead of a fixed lookup table. The model generates the starting daily portion, recipe mix, and bag size, and writes the reasoning for each in plain language, personalized per dog. The current "Worth speaking to your vet" and "What's in there for Bella" copy is already close to this pattern; the AI layer makes it dynamically generated rather than pulled from a static template.
What the AI deliberately does not do: It doesn't change a paid subscription's contents automatically; it proposes every adjustment, and the owner confirms it before the next delivery. It also doesn't make medical claims; health-tag-driven suggestions keep the same "worth speaking to your vet" framing Bonza already uses for higher-stakes conditions like cancer.
PROBLEM
Initial observations
The plan is smart at signup, then frozen
Owners' dogs change: age, weight, activity, health. But the plan doesn't, unless the owner manually goes back into settings.
Owners don't know if the plan is actually working.
Leftover food or a dog going off a recipe isn't captured anywhere; the subscription just keeps shipping the same thing.
Re-doing the whole quiz feels like admitting the first answer was wrong
This creates friction, owners would rather just cancel than restart a 5-step form.
DESIGN PROCESS
How might we collect ongoing signals without turning the app into a chore?
Early direction was a short in-app survey every week, mirroring the thoroughness of the original 5-step quiz.
This tested logically, more data, better AI adjustments, but risked the exact fatigue that makes owners abandon long onboarding quizzes in the first place. A meal-plan app that starts feeling like a chore works against the "set it and forget it" reason people subscribe in the first place.
What we did instead: single-question, push-notification-style check-ins spaced [2 weeks] apart, framed conversationally rather than as a form ("Did Bella finish her bowl today?" not "Please rate food consumption 1–5"). This trades data density for actually getting a response.
Final designs
Getting stakeholder buy-in
Reviews and rounds of iterations are hard, but they are key to turning stakeholders into advocates for the work. I knew it was crucial to listen and address concerns, without forgetting we had to be assertive about some of the design direction we chose, and to show the value in that direction.
One way I get buy-in is by showing the direct value and speaking to stakeholders directly. I walked the manager through a simple before/after of how many clicks it now took to reach a product, and the reaction was immediately positive.
Designing with the technical build in mind
WooCommerce and the Blocksy theme setup forced me to rethink the design again.
Bonza runs on WooCommerce (WordPress), not a custom-built app or headless storefront. That shaped several design decisions rather than sitting separately from them:
The quiz output has to resolve into real WooCommerce objects, a specific product variation (recipe + bag size) and a WooCommerce Subscriptions billing schedule (delivery frequency). The AI's "proposed adjustment" after checkout isn't a freeform recommendation; it has to map cleanly onto swapping a subscription's product variation or changing its renewal interval, both of which WooCommerce Subscriptions supports natively. Designing the adjustment screen meant staying inside what that plugin can actually change without a custom backend.
The result and account pages reuse WooCommerce's native cart/subscription management patterns (like the frequency selector and "pause/skip/cancel" options already familiar from the current flow) rather than introducing a parallel custom system, keeping the AI-driven parts of the experience feeling like an extension of the existing store, not a bolted-on app.
QA & TESTING
I tested multiple states in staging and evaluated design specifications across various screen sizes to be sure.
I used Claude Code to help run through QA systematically, checking each entry point (nav, search, direct link) against its expected states (empty, single-match, partial-match, fully populated, loading) and flagging layout breaks, truncated copy, and misaligned filters across common breakpoints before the limited rollout.
This project is still in build, outcome metrics aren't available yet.
Once the redesign ships and we have data to measure against (clicks to product, search abandonment, catalog engagement), this section will be updated with real, post-launch numbers.
REFLECTION
My key takeaways and learnings!
A good calculator isn't the same as a relationship.
Bonza's existing onboarding gets the initial calculation right, the hard problem is what happens in the following months, which almost nobody in this category has solved well.
The AI is only as good as the willingness to answer a two-second question.
The most sophisticated adjustment model is worthless if owners don't respond to check-ins, so the real design problem here was behavioral, not computational.
Naming conventions are part of the design, not an afterthought.
Mirroring Blocksy's setting names in Figma variables turned handover from a translation exercise into a direct mapping, developers didn't have to guess what a token meant.
CURIOUS TO KNOW MORE?
This is just a small part of the design process, to get the full story get in touch.