E-commerce & web experience redesign
NeoLife
Four customer tiers. Four pricing structures. One storefront that had to look simple.
Role-based feature architecture and recurring-purchase optimization for a global health-and-wellness storefront serving four customer tiers.
Tools · Figma · Photoshop
01
What this was
NeoLife runs a global health-and-wellness storefront on a legacy commerce platform. I spent close to a year on the team as the UX/UI designer for the web experience, focused on the buying journey — product listing, product detail, recurring purchase, and the account features that sit behind them.
- Role
- UX/UI Designer
- Platform
- Web · desktop & mobile responsive
- Status
- Live in production
- Focus
- Role-based features · recurring purchase
A note on this work
This was done during my tenure at NeoLife, and I don’t own the output — so there are no Figma files to walk through. Everything shown here is a live production implementation you can open at beta.neolife.com. This case study documents the reasoning and the constraints, using the shipped result as the record.
02
The core challenge: hiding system complexity
The front end looks like a straightforward supplement store. Underneath, the platform serves four distinct customer types, and almost every commerce surface has to render differently depending on which one is looking at it.
A Guest sees retail pricing and can browse and check out. A Retail Customer adds an order history and favorites. A Member unlocks 10–20% pricing and recurring shipments through NeoShip, plus a points balance. A Promoter is running a business on top of the storefront — 25% pricing, case (bulk) pricing, commissions, and a downline. Same product card, four different truths about price, savings, and what the buttons do.
The design job wasn’t a redesign — it was fitting new capability into that grid without the interface getting louder for the people who didn’t need it.
Feature 1
A favorites system that scales across roles
High-frequency buyers and business partners re-order the same products constantly. The old flow gave them no way to hold a shortlist, so every re-order started from search.
Favorites had to be reachable from wherever the decision happens, without adding a screen. Two placements, one behavior: a heart on every product card in the listing, and a Favorite link on the detail page directly under the primary CTA — close enough to the buying decision to be useful, quiet enough to ignore. The list itself is account-scoped, so it follows a Member or Promoter across sessions and devices.
Feature 2
Buy by the case — bulk ordering as a role-aware component
Promoters and business-builders buy inventory, not units. Making that a first-class action on the listing page — rather than something you assemble by adding six of a thing to the cart — directly targets average order value.
The catch is that “buy the case” means something different per role, so it’s not one button. For a Guest or Retail Customer it’s a green savings pill — Case of 6, Save $99 — a straightforward upsell. For a Member or Promoter it’s a checkbox carrying that role’s case price inline, because they’re deciding on margin, not on a discount. Selecting it swaps the card into an active state: the title becomes Case of 6 and the price updates. Same component, three renderings.
Retail — a green savings pill
Member — a checkbox with the member case price
Promoter — the checkbox carries the promoter case price
Selected — the card commits to the case: title and price update
Feature callout
Both features, one card, one tap
Because both features live inside the product card, a buyer can add a bulk case to the cart or save an item for later without ever opening the detail page. For someone rebuilding a monthly order across nine products, that’s the difference between a two-minute task and a ten-minute one.
Reflection
What I took from it
- Designing the state matrix, not the screen. The case control shipped as a pill, a checkbox, an active state and a detail-page button — one feature rendered four ways by role. Most of the work was the matrix of what each role sees and what each interaction returns, not the layout.
- Legacy constraints are the brief. The platform was years of accumulated decisions. New features had to slot into the existing card and detail-page structure without a redesign, which is what set the bar for “good” — additive, quiet, consistent.
- Align with engineering before high fidelity. Role-based pricing and points logic lived server-side. The design only held up if it matched what the system could actually return per role, so speccing that with engineering early saved rebuilds later.
- You don’t always keep the files. I can point at the live site, not a source file. Writing decisions down as they ship — the reasoning, the constraints, the trade-offs — is the version of the work that stays with you.