0->1 Product Definition for Unified Catalog + One Delivery
A beauty startup was exploring same-day delivery for local beauty supply. Local inventory is fragmented, no single store carries everything a customer needs, which creates a fulfillment and trust challenge. I led the 0->1 definition of the product as a product-first unified catalog with one driver doing multi-store pickups, delivered as one order. This included building the design system 0->1 to support fast iteration.
*Due to NDA, branding, product names, and store data have been anonymized. Screens are conceptual recreations that preserve the original UX decisions, component library, and fulfillment logic I defined.
Role
Lead Product Designer
Team
As the first design hire on this engagement, I worked directly with the Founder, partnered with Product, and designed for future engineering constraints without an engineering team in the room. This was a greenfield exploration, no previous designs existed. Engagement was structured as 10 weeks, with once-weekly founder syncs and async collaboration in between, requiring self-directed exploration and clear decision logs.
OUTCOMES
→ Defined a 0->1 fulfillment model that made a fragmented catalog shippable.
Defined the core logic from scratch: one order, one driver collects from multiple stores, one fee, one ETA. Solved for the reality that no single beauty supply carries everything a customer needs. Prototype standardized on $3.99 flat for one delivery with multi-store pickup.
→ Defined the discovery system for textured hair from scratch.
Built the match system (94% match plus why it matches), hair-type filtered reviews, and Shelves search (natural language like "leave-in for high porosity") as the primary discovery patterns. Product detail hierarchy focused on trust before speed.
→ Scoped a focused MVP from 11 exploratory concepts to 7 shippable screens.
Archived store comparison as a primary screen and pro verification for later. Replaced store selection with cart-level optimization chips: Best Overall, Cheapest, Fastest. Reduced customer decisions from 5 store choices to 1 tradeoff choice.
→ Created buildable v1 constraints for future engineering.
Documented assumptions for inventory (manual store confirmation vs POS integration), routing (static ETA vs real-time routing), and substitutions (Ask me / Best match / Refund) so the UI could be handed off without waiting for perfect APIs.
→ Built the design system 0->1 for the marketplace.
Created the foundational component library to make the 0->1 build scalable. Included product cards with match badges, optimization chips, availability modules, and tracking states. Established typography, color, and spacing tokens so future screens could be built without reinventing patterns.
THE PROBLEM
The Opportunity We Were Exploring
When I joined, the company had validated demand for same-day beauty supply but had no product yet. This was not a redesign. It was 0->1 exploration with no design system in place.
We had to figure out three unknowns from scratch:
First, fulfillment.
Local beauty retail is fragmented. No single store carries everything a customer needs, key items are typically spread across 2 to 3 shops. If we followed a traditional marketplace logic where 2 stores in cart meant 2 separate deliveries, my analysis showed delivery fees could exceed 20% of order value, likely creating abandonment.
Second, discovery.
Shoppers know their concern, breakage, high porosity, dry scalp, but don't know which product solves it. If we forced exact product names and store picking, users would have to work hard to trust a product. We needed to define how to build confidence from scratch.
Third, consistency.
There was no component library, no interaction language, no tokens. Without a system, every new screen would look and behave differently, which would erode trust and slow down iteration. We needed a system that could scale with the product.
The goal was to define a first version that felt like one unified catalog, not a directory of stores, and could deliver everything together in one delivery.
THE PROCESS
Phase 1: Aligning Founder on definition of success
Kickoff & Client Alignment: We agreed success meant a customer could get everything she needs in one delivery, and trust it would work for her hair. Two proxies we used to evaluate concepts: time to first add-to-cart and clarity of fulfillment cost. Because we had once-weekly syncs, I set up a decision log early so we could track exploration async.
Phase 2: Concept Mapping Workshop
When I started generating initial flows in Claude Design, the tool defaulted to a traditional marketplace pattern where a cart with items from 2 stores created 2 deliveries, 2 fees, and 2 ETAs. That pattern was included because it is common in grocery delivery.
I flagged it as misaligned for beauty. In beauty, fragmentation is the norm, not the exception, no single store carries everything. If we kept that model, a typical job like "I need 4 products no single store has" would break. We mapped two journeys to show the difference: the Claude-generated traditional flow vs a unified catalog flow. The traditional flow broke on Job #3.
We created two hypotheses to test in prototype. Hypothesis one: Customers think in products, not stores, so hiding store selection behind platform optimization will reduce drop-off. Hypothesis two: Leading product detail with match reasons and hair-type reviews will increase add-to-cart confidence more than leading with fastest delivery.
Phase 3: Navigating a Key Constraint on User Testing
One constraint I navigated was around user testing. I wanted to test prototypes with potential users to validate discovery and fulfillment concepts quickly. The founder wanted to keep the project confidential until it was built and strongly preferred that she be the one testing prototypes and providing feedback. I pushed back and advocated for external validation, but she was adamant about not sharing ideas outside our engagement.
Combined with once-weekly syncs and slow async communication, this meant I had to find signal in other ways without breaking confidentiality:
AI-assisted desk research. I used AI tools to synthesize patterns from public sources, including beauty community discussions, ingredient education content, and review trends around textured hair care. This helped me map common concerns to product attributes without exposing our concepts.
Domain expert sessions with the founder. I treated the founder as our subject matter expert and used our weekly syncs for structured discovery: how shoppers describe their hair, what language they use for porosity and breakage, how they currently shop across stores, and what causes distrust. I prepared async prompts so she could respond between meetings.
Secondary research and review mining. I analyzed public reviews on Sephora and Ulta, focusing on reviews that mentioned hair type, to understand what information builds confidence. I also reviewed shopper camera rolls (with permission), people screenshot ingredient lists and hair-type mentions, not store names.
Competitive teardown. I mapped existing behaviors across Instacart (multi-store fees = top complaint), Sephora/Ulta (great discovery, no local same-day), and DoorDash (hides complexity behind one fee). This synthesis became our principle: Customer sees one order. System handles complexity.
Because we could not do broad external testing, I was explicit in documentation about what was validated by proxy research vs what remained an assumption for future validation.
Phase 4: Shipped 0->1 Model + Design System in Hi-Fi Prototype
Within a focused two-week sprint inside the larger engagement, I rebuilt the core flow from scratch in Claude Design away from the default pattern: Home to Search with Shelves to Results to Product Detail to Cart with Optimization to Checkout to Tracking. In parallel, I built the design system 0->1 so components were reusable across flows. This allowed me to bring a testable prototype to our weekly review despite limited sync time.
Phase 5: Systematized The Exploration
I documented technical assumptions for future engineering: inventory confirmation via tablet/SMS not POS, static route estimate around 10:40 AM not real-time TSP, substitution preference as "Ask me / Best match / Refund." The decision log I created (Concept Explored / Why We Did Not Ship It / What We Shipped Instead / Technical Tradeoff / Validation Status) plus the component library became the template for future product reviews and builds. This was critical given async communication, anyone joining later could understand why decisions were made without needing a live walkthrough.
WHAT WE DEFINED 0->1
1. Fulfillment Model: One Delivery, Multi-Pickup
The initial Claude Design output included a traditional marketplace model where a cart with 2 stores would create 2 deliveries, 2 fees, and 2 ETAs. I identified that as misaligned for this domain and killed it. That model added cognitive load and cost.
What we defined instead: One order equals one delivery equals one driver does multi-store pickup. Cart shows "4 items from 2 stores" with info banner "One driver collects from both stores and brings everything together." Delivery simplified to "$3.99, One delivery, 2-store pickup." Checkout shows single ETA around 10:40 AM and single fee. Tracking shows human progress: "Picked up from Store 1 (1 of 2) to Picking up from Store 2 (2 of 2) to On the way."
2. Product Detail: Trust Before Speed
Early explorations had product pages dominated by store lists and granular stock statuses. We explored that and saw it forced logistics decisions before trust.
What we defined instead: Product page hierarchy built from scratch: 1) 94% match, Good match for your hair 2) Why: "High porosity, rebuilds bonds without buildup, Sulfate-free which you avoid" 3) Reviews filtered for hair type "128 reviews, Filtered for 4C, high porosity" 4) Availability: "Available near you, Can be delivered today, From $21.99, View all offers" as secondary bottom sheet. Pro stores removed for MVP.
3. Cart: Optimization Instead of Store Selection
Early explorations required manual store choice per item. We explored that and it created too many decisions.
What we defined instead: Top of cart has three chips: [Best Overall] with dynamic caption: "Everything in stock, 35 min, $3.99 delivery." User picks tradeoff, platform picks stores. Reduced 5 store decisions to 1 tradeoff decision.
4. Design System: Built 0->1 Alongside Product
There were no shared components or tokens. I initiated and built the system from scratch, including core tokens (color, type, spacing), product cards with match badges, Shelves search patterns, optimization chips with active/inactive states, availability modules, cart grouping, and tracking steppers. Defined consistent language for how the system confirms stock, handles decline, and shows ETAs, so users could build a mental model and trust the flow. Built in Claude Design and documented usage for future designers and engineers.
5. Handling Fragmentation: Explicit Choice Over Auto-Substitution
Early concepts showed out-of-stock as "Out at this store, 2 others" on home, creating anxiety before product evaluation. We explored that and killed it.
What we defined instead: We handle out-of-stock after both stores confirm. Modal: "Store A has confirmed its 2 items. Store B can't fill 1 item, Get it from another nearby store for $20.50 / Continue without it / Cancel. No driver assigned until you decide. Nothing charged." This gives explicit choice instead of auto-substituting and includes a 5-minute buffer for ops to SMS stores.
IMPACT
Product Impact
The one-delivery, multi-pickup model defined 0->1 is now the core narrative in the founder's pitch deck. The product detail hierarchy with match reasons became the standard for all new product pages. The component library I built became the single source of truth for future screens.
Organizational Impact
The decision log and component library I created became essential due to our working model. With once-weekly syncs and slow async, the team needed a way to track why concepts were killed without live context. This system became the template the team uses for product reviews and enables faster iteration for future features like subscription refills without rebuilding components.
What I Learned
For greenfield marketplaces with limited founder bandwidth, the most valuable work is often killing concepts early and documenting them clearly for async review. I learned to interrogate what Claude Design generated instead of accepting it, and to get signal without direct user testing through AI-assisted research, domain expert sessions, and competitive teardowns. Building the system alongside the product, not after, let me move faster within a 10-week, low-touch engagement.
Acknowledgements
Due to NDA, I can't name the client, but my sincere gratitude to the founder and product partner for trusting me to define the product and system 0->1 from scratch.
