Case Study · Wix.com
← All work

One landing page that adapts to who the seller is

Wix was losing dropshipping sellers to churn and had never reached one big group at all: site owners with no online store. My answer was a "Find Products to Sell" page that reshapes its entire purpose based on where a seller is in their journey — designed, built, and handed to engineering as a working AI-assisted prototype.

4adaptive states
One page, four distinct experiences — each reshaped around the seller's context and next-best action. Designed with Claude Design and Figma AI, then built as a working, API-connected prototype in Claude Code and Cursor (wired to Wix's MCP and product APIs) and submitted as a PR foundation for engineering.
Role
Product Manager + Designer
Scope
KPIs, scope, design, build
AI stack
Claude Design, Figma AI, Cursor, Claude Code
Timeline
2026
Context

A single page can't serve four very different sellers

Wix's "Find Products to Sell" page treated every visitor the same — but the people landing on it were anything but. Some had no online store at all. Some had just opened one. Some were running mature catalogs. A page optimized for one of them actively underserved the others.

Before — scroll the capture ↓
Full-length capture of the previous Find Products to Sell page: Printful print-on-demand grid with generic placeholder products, followed by Blanka, Modalyst dropshipping, Alibaba, AliExpress, Dripshipper, Spocket and Bookvault promos, stacked identically for every seller
The production page my redesign replaces, full-length — every provider and app promo stacked identically for every seller, with generic “Your Image Here” placeholders where personalization could be. ● Production page · 2026

The redesign brief was to lift engagement and return visits. My read was that the lever wasn't a prettier page — it was a page that knew who it was talking to and changed its entire purpose accordingly.

My role & honest credit: I'd recently moved into a Product Manager role on Dropshipping, so I owned this end to end — KPIs, research, scope, design, and the prototype build. The adaptive-scenarios architecture below was my concept; the AI-recommendations direction was my manager's idea. I designed the system that brought both together.
The core idea

Four states, four jobs

Rather than one layout with conditional bits, I designed four genuinely different experiences — each with its own hero, content, and goal, matched to the seller's maturity and intent.

01No online store
Order business merch · AI picks top 5
↳ "You could sell these on your own store"

Reached via contextual prompts where intent already exists — adding products to a booking service, or swag for an event. AI reads their site content and previews their logo on the top 5 recommended POD products.

Goal: lowest-friction entry into products; gently seed the idea of opening a store.
02New / small store
Get set up · payments · shipping · catalog
↳ Build the right starter catalog

A fixed setup-guidance area, echoing the Wix setup dashboard, focused on getting payments, shipping, and the right number and type of products in place. No catalog optimization yet — there isn't enough data to be useful.

Goal: reach a healthy baseline catalog and a sale-ready store.
03Experienced seller
Weekly catalog optimizations
↳ Restock · complement · expand category

Weekly, data-driven suggestions: restock low inventory with similar items, add complements to top performers, surface industry-trending products, and — at sufficient volume — recommend branching into dropshipping, POD, or wholesale.

Goal: grow revenue from an established base.
04Cross-cutting logic
Adapts to what they've already tried
↳ Has POD? → suggest dropshipping (& vice versa)

States 2 and 3 further adapt to what the seller has already added: have POD? suggest dropshipping, and vice versa. Tried nothing yet? Lead with POD — the easiest on-ramp into selling products.

Goal: always surface the most relevant next step, not a generic one.
The page's job isn't to show products — it's to figure out what this seller should do next, and make that the obvious path.

Wireframes above are simplified representations of the four states, created for this case study. The full-length “before” capture in Context is the live production page (2026).

The AI workflow

From idea to a working prototype — solo

The part I'm proudest of isn't a screen — it's how far I could carry this alone. I used AI not as a novelty but as the actual production pipeline, moving from concept to a running, API-connected prototype without a separate engineer for the foundation.

1 · Ideate
Claude Code · Figma Make
Described the four states and pressure-tested ideas; fed in my own designs for critique and optimization — AI as a sounding board, not an autopilot.
2 · Design
Figma AI
Once the direction was set, quickly built out the designs and an interactive prototype.
3 · Build
Claude Code + Wix MCP
Connected Claude Code to Wix's MCP so it built each page in Wix's real styling and patterns — not generic code. Stood up the initial architecture.
4 · Refine & ship
Cursor → PR
Finalized in Cursor and submitted a PR as a working foundation for the dev team to take to production.

A detail I care about: once the work moved into code, code became the source of truth. I stopped going back to Figma. When Wix landed a new POD partnership (Blanka) mid-build, I implemented it directly in Claude Code and Cursor, and I wired the prototype to Wix's product APIs so it pulled real products — not placeholder mockups.

Where my build ended: I'm honest about the boundary. I connected the product APIs and stood up a working, interactive prototype — but the harder integrations (the live AI recommendation engine and other dynamic elements) were beyond what I could wire solo and were left for engineering. The PR was a strong, running foundation, not production-ready code.
Exploration

One of the AI-generated passes

Below is a raw Figma Make exploration of the four-state concept — the kind of quick generated pass I use to pressure-test an architecture before committing to a direction, recreated for this case study. It is deliberately not the shipped design: the sketchbook, not the ship. Switch states to feel how the concept adapts. Best explored on desktop.

Generated exploration · Figma Make
Four-state concept — raw AI pass
Loads a live Figma embed
Exploration created for this case study — not the final design. The production direction was designed in Figma and handed to engineering as an API-connected code prototype (PR). Prefer a tab? Open the prototype in a new window ↗
Why it matters

What this project demonstrates

  • Systems thinking over screens — designing intent-aware states, not a single page, to serve four very different sellers.
  • Product ownership — KPIs, scope, research, and backlog owned end to end in a PM capacity.
  • Real AI-to-production fluency — moving from concept to an MCP- and API-connected prototype, and handing engineering a running PR instead of a static file.
  • Honest collaboration — building on my manager's AI-recommendations direction, and clear about where my build handed off to engineering.
The shift I'm most excited about: design's source of truth can move from the mockup to the running code — and one person can carry a lot more of that path than they used to.

The project was handed off as a PR foundation; my role ended before it reached production.