All case studies

Case study

Product detail system redesign

Led a PDP redesign that evolved into a product-model and variation-system redesign during a live ProdX migration.

Hy-Vee Consumer Ecommerce Lead Product Designer (2020–2022) Product & System Design
Redesigned Hy-Vee product detail page on desktop with product options, fulfillment, and variation selection.
Redesigned PDP framework across desktop and mobile.
My role
Led a 100+ product audit, authored the variation rules, and aligned internal teams with ProdX on the underlying product model.
What changed
ProdX added two API attributes and Hy-Vee gained a scalable product-variation model that could handle category-specific edge cases.
Scope & context
The PDP had to improve during a live platform migration, with inconsistent product data, category-specific edge cases, and vendor dependencies.
Impact
Placement A/B test: Similar Items conversion increased from 0.82% to 1.49%. Broader first-month analytics showed about 84k additional related-product add-to-carts, 4k primary-product add-to-carts, and 31k variation interactions.
01

The challenge

The product detail page had two connected opportunities: make product variations easier to understand and support Hy-Vee’s move from a legacy in-house system to ProdX. The new platform added capability, and its default model needed to better reflect how grocery products varied across categories.

The work needed to address both the page and the variation rules so the experience could stay predictable as the catalog grew.

Existing Hy-Vee product detail page showing the original product variation experience
Existing product detail page before the redesign and ProdX migration.

Project detail

  • Symptoms: Variation states, hierarchy, and mobile behavior needed to make product differences easier to understand and compare.
  • Drivers: Existing data rules and platform constraints required careful handling of product combinations and content mapping.
  • Constraints: Live migration with active revenue and low tolerance for production errors.
  • Result: Improving those areas would support lower drop-off, stronger merchandising performance, and more scalable category behavior.

Variation complexity during a platform transition

The existing product detail experience already behaved differently across categories before this initiative began.

Product variation behavior varied by category, and some related items were being treated as variations. That made comparison less clear for customers and made small changes harder to predict. The redesign gave us a chance to make those relationships explicit and easier to maintain.

At the same time, the organization was migrating product data from a legacy in-house system to ProdX, a more advanced platform for managing variations, substitutions, and related products across the catalog. ProdX introduced greater capability, along with structural rules that directly shaped what was possible at the interface level.

Understanding those constraints early gave the interface a reliable foundation.

What the audit clarified

Early exploration showed how the platform constraints were shaping the customer experience itself. We needed to address that underlying behavior before polishing the interface.

Auditing more than 100 real product examples showed where we needed to adapt ProdX’s variation model to match how customers understood product differences. Variation categories needed a clearer primary anchor, and secondary attributes varied in scope, and state changes triggered page and URL behavior that broke continuity.

Clearer authoring and governance rules were essential so the migration improved the customer experience as the platform grew more complex.

What was at stake

The variation system had to be defined clearly enough for the organization to realize the benefits of the more capable platform.The opportunity was to make product behavior more consistent for customers, reduce operational workarounds, and give the catalog room to grow on a stronger system model.

This project required rethinking the system that powered the experience.

Baseline PDP used during the audit to document the existing page structure and how ProdX variation behavior surfaced to customers.

02

Discovery & insights

I audited more than 100 products across categories, deliberately looking for edge cases. The audit revealed unrelated products grouped as variations, legitimate variations split apart, ambiguous attribute hierarchies, and edge cases that standard flows and vendor prototypes did not show.

Interface changes depended on resolving variation logic upstream.

  • Product relationships needed explicit definitions and exclusions.
  • Variation precedence had to support the full range of categories and catalog edge cases.
  • The vendor model had to be tested against real commerce data.
Research audit of edge-case products and ProdX variation behavior
Edge-case product audit used to expose where variation logic broke across real categories.

Moving beyond assumptions

I studied variation behavior in real catalog data. The audit showed how product structure, governance, and interpretation across systems shaped the customer experience. I used those findings to define the rules before developing interface concepts.

Deep edge-case analysis

A core part of discovery involved auditing more than 100 edge-case products across categories.

The audit covered real combinations of sizes, flavors, bundles, substitutions, and near-duplicates. Those examples showed where clearer product relationships and variation rules would help customers make informed choices.

Patterns emerged quickly:

The pattern was consistent enough that variation rules needed to be defined, validated, and enforced at the system level so interface decisions had a stable base.

To understand how the new ProdX variation system would behave in real conditions, I conducted a deep audit of edge-case products across categories.

This analysis surfaced category differences, ambiguous variation hierarchies, and edge cases that were not apparent in standard flows or vendor prototypes. Those findings became the basis for defining variation rules, testing system assumptions, and aligning Product, Engineering, and ProdX on what the experience needed to support.

  • Products grouped as variations were often only loosely related
  • Legitimate variations were frequently split apart
  • Category-specific rules conflicted with global assumptions
  • Small data inconsistencies produced disproportionately bad experiences

Cross-functional and best-practice research

In parallel, I led structured discovery across internal teams, competitive platforms, and industry research to test assumptions and identify proven patterns.

This included:

That gap between platform defaults and customer expectations made a rules-driven variation system necessary.

Competitive patterns across major retail platforms revealed consistent best practices for variation clarity, anchoring, and error prevention.

While implementations varied, successful experiences clearly distinguished primary products from selectable options, avoided invalid states, and maintained a stable sense of place as customers explored variations.

  • Competitive analysis of platforms with complex variation, substitution, and grouping behavior
  • Baymard Institute research on product configuration, choice architecture, and error prevention
  • Collaborative ideation and story mapping with product and engineering
  • Validation of proposed approaches against known edge cases

Key insights

I used the audit, cross-functional input, and competitive research to turn a complex set of catalog behaviors into shared product requirements. The challenge statement and story map helped Product and Engineering align on what customers were trying to do, where the experience needed more support, and what had to be addressed before moving into interface design.

Challenge-definition worksheet from my discovery process, used to turn the audit findings into a shared definition of the variation challenge.

Story map from my discovery process, used to map the customer flow and organize the work around the variation model.

  • Variation complexity lived at the system level Across 100+ audited products, variation behavior depended on upstream modeling and governance. Interface improvements depended on clear attribute definitions and durable rules upstream.
  • ProdX’s standard model was designed around cleaner, more consistent data than the grocery catalog contained The platform worked well for simpler products, but broke down when applied to real-world catalogs involving substitutions, bundles, size hierarchies, and category-specific rules.
  • Edge cases were everyday catalog reality Many of the most complex products were also commercially important. Getting those scenarios right directly supported customer trust, merchandising performance, and revenue.
  • A stronger shared model would preserve future flexibility Adapting ProdX around explicit shared rules would preserve future flexibility and reduce hidden dependencies.
  • Clear variation rules were required before experience design could succeed Explicit variation definitions, precedence, and exclusions gave downstream Design and Engineering a more predictable model to maintain.
03

Framing the strategy

I turned the audit findings into a shared system model for product variation, substitutions, related products, pricing, and availability. That gave Product, Engineering, Merchandising, Operations, and ProdX a common set of rules for decisions that had previously been handled case by case.

I also led a working session with ProdX’s founder and our product and engineering partners around constraints that were affecting the customer experience. ProdX added attributes and adjusted behaviors to better support the product complexity we had uncovered.

The strategy connected the product model and interface through shared variation rules.

Defining the system requirements

The core challenge was establishing a system that could accurately model product variation, scale across categories, and remain adaptable over time.

Based on discovery and edge-case analysis, the system needed to:

Variation logic had become part of the product infrastructure, affecting both the product model and the interface configuration.

  • Represent variation types differently by product category
  • Enforce clear precedence rules when multiple attributes applied
  • Exclude non-variations from the variation experience
  • Support future expansion without requiring PDP redesigns
  • Keep the rules understandable to merchants, operators, and engineers
  • Goal: Make product evaluation fast, accurate, and confidence-building across devices while working within platform constraints.
  • Inputs: ProdX data model, variation rules, substitutions, related products, pricing, and availability.
  • Core interactions: Evaluate, compare, select variation, validate state, and add to cart.
  • Decision support: Prioritized hierarchy, progressive disclosure, and trust signals such as availability, delivery, and returns.
  • Governance: Reusable modules, category scalability, and safe handling of invalid states.

Influencing the vendor implementation

Supporting several of these requirements required changes to the standard ProdX implementation.

I led a working session with ProdX’s founder, alongside our product owner and engineering counterparts, to walk through real product examples from the audit, show where the default assumptions needed more flexibility, and advocate for changes to attribute handling and rule behavior.

ProdX responded by adding attributes and adjusting behaviors to better support the product complexity we had documented. The working relationship became more collaborative as the implementation evolved.

04

Defining the variation system

I formalized the variation model into durable rules for which attributes drive selection, which provide context, and which should never behave as variations.

Defined precedence and conflict-resolution logic so every product resolved to one predictable structure as the catalog evolved.

Hy-Vee variation rules defining product attribute behavior and conflict resolution
Variation rules defining which attributes qualified as true variations, how conflicts resolved, and how the system stayed predictable across product categories.

Project detail

With the strategy aligned and platform constraints understood, I formalized the variation system into durable rules and governance that could keep behavior consistent as the catalog evolved.

Authoring the variation rules

I authored a comprehensive set of variation rules defining:

These rules were derived from audited product examples and validated against real catalog data. They became the contract between product, engineering, and the vendor platform.

  • Which attributes qualified as true variations
  • Which attributes should never appear as variations
  • How attributes should be grouped, ordered, and labeled
  • How conflicts between attributes should be resolved
  • How different product families required different logic

From attributes to meaningful variations

Product attributes needed distinct roles in the customer experience.

True variations, descriptive attributes, and related products needed distinct behavior. Clear roles would make product choices easier for customers to interpret.

I defined a clear distinction between three attribute types:

Making these rules explicit made the system easier to reason about across design, engineering, and merchandising. New categories and attributes could be introduced through the model itself, reducing PDP redesigns and UI-level exceptions.

  • Primary variation attributes Attributes customers intentionally choose between, such as diaper size, count, or package quantity. Changing these should update the product without changing what the product fundamentally is.
  • Secondary attributes Attributes that provide useful context but should not drive selection, such as absorbency level, age range, or fit indicators.
  • Excluded attributes Attributes that should never appear as variations, even if they exist in the data. For example, pulling size or count values from similar products could unintentionally switch a customer from overnight diapers to standard diapers without them realizing it.

Rule precedence and conflict resolution

Many products qualified for multiple variation attributes at the same time. Precedence rules made those outcomes predictable.

I established logic for:

These rules ensured each product resolved to a single, predictable variation structure.

The rule set defined which attributes counted as true variations, how conflicts resolved, and how product relationships should behave consistently across categories.

  • Attribute prioritization
  • Conflict resolution
  • When variation groups should collapse or expand
  • How safe defaults were selected
05

Experience vision & execution

Once the variation rules were defined, I redesigned the PDP around clearer hierarchy and predictable behavior across web and app. Customers could compare options, understand unavailable combinations, and move through complex configurations while ProdX complexity stayed behind the interface.

The interface could stay straightforward because the system rules were doing the hard work behind it.

Redesigned Hy-Vee product detail page on desktop
Redesigned product detail experience on desktop, built around the new variation rules.

Project detail

Designing with explicit rules

With the variation system defined, explicit rules guided how products should behave across categories. That gave experience design a clear basis for handling both common flows and edge cases.

This allowed the interface to focus on clarity, predictability, and trust.

Experience goals

The redesigned product detail experience needed to:

The interface translated complex system rules into clear choices so customers could move forward with confidence.

  • Help customers understand what they were buying
  • Make variation choices easier to evaluate
  • Prevent invalid or misleading selections
  • Extend discovery beyond the primary product while keeping recommendations distinct and useful
  • Make the path from product evaluation to purchase more direct
  • Scale consistent behavior across categories

From concepts to execution

Early concepts explored how to make variation logic clear enough for customers to understand at a glance.

Beyond variations, I partnered closely with product and engineering to define how adjacent systems surfaced related products. For “Similar items” and “Often bought with this item,” I proposed a looping logic that rotated product groups instead of showing near-duplicate items. This created more variety, reduced redundancy, and made these swimlanes feel more intentional.

Several principles guided execution:

These principles helped the experience stay consistent even as variation logic differed by product type.

The resulting experience preserved clear product identity, prevented invalid states, and introduced adjacent product discovery while keeping the primary decision flow clear.

  • Only surface meaningful choices
  • Let structure do the work
  • Favor predictable layouts over highly conditional patterns

Translating system logic into experience

Once the system rules were defined, I worked with engineering to translate them into explicit interface behavior. Each interaction was designed to reflect the system’s intent:

Customers did not need to interpret internal complexity, and edge cases behaved predictably, giving teams clearer behavior to maintain over time. The experience behaved logically by design.

  • Variation groups appeared only when valid
  • Option ordering reinforced precedence rules
  • Default selections were safe and explainable
  • Invalid states were eliminated rather than handled visually

Collaboration with engineering

Execution stayed tightly coordinated with engineering so the rules and interface behavior remained aligned. I worked iteratively with engineers to validate:

This made implementation more predictable and surfaced important questions earlier.

  • The design accurately reflected rule resolution
  • Edge cases behaved consistently across scenarios
  • Changes to system logic propagated safely through the experience

Outcome of the design approach

The final experience felt simpler even as the underlying system handled more complexity. Because design decisions were anchored in shared rules rather than individual interpretation, the experience was easier to justify, extend, and maintain.

The result was a PDP system that could scale with more confidence.

Final desktop and mobile PDP designs applying the new variation rules and information hierarchy across responsive contexts.

06

Validation & experimentation

Before launch, unmoderated usability testing showed consistently strong task success across core product-detail flows. Participants could understand the hierarchy, interpret options and constraints, and complete product-selection tasks independently.

After launch, we ran a controlled A/B test that moved Similar Items above the product description while holding the rest of the page constant.

Swimlane conversion rose from 0.82% to 1.49%, reaching clear statistical confidence within the first month of the broader experiment window.

Unmoderated usability testing results for the redesigned product detail page
Usability testing showed strong task success across the core product-detail flows.

Unmoderated usability testing

Before exposing the redesigned experience to live traffic, I validated the product detail experience through unmoderated usability testing to ensure people could understand and use it independently.

Testing focused on whether customers could:

Participants consistently navigated complex product configurations with confidence. They identified valid options, understood why certain combinations were unavailable, and completed selection tasks with minimal hesitation.

Participants selected variations correctly and also understood the page structure and what to do next.

  • Understand the structure and hierarchy of the product detail page
  • Complete key tasks confidently and efficiently
  • Interpret available options, constraints, and system feedback correctly
  • Move through the core flow independently

Placement experiment

To validate a key system-level decision, we ran a focused A/B test on the redesigned product detail page.

  • Compared two versions of the same page
  • Moved the “Similar Items” swimlane from below the product description to above it
  • Held all other page elements constant

Placement test result

Moving relevant alternatives earlier in the decision flow improved both engagement and swimlane conversion.

  • Swimlane conversion increased from 0.82% to 1.49%
  • The higher placement outperformed the lower placement and reached clear statistical confidence within one month
  • The A/B test showed swimlane conversion improved from 0.82% to 1.49% when “Similar Items” appeared above the product description

Broader post-launch analytics

Alongside the placement test, broader post-launch analytics showed the following changes. These figures describe the overall redesigned PDP and are separate from the controlled placement-test result.

The redesign improved page-level clarity, changed how customers engaged with complex product configurations, and gave the team a better base for ongoing optimization.

Pre-launch analytics showed high bounce rates, lower variation engagement, and limited cross-sell interaction, pointing to an opportunity to improve clarity across complex product configurations.

Post-launch metrics showed increased variation interaction, longer time on page, higher add-to-cart activity, and reduced bounce rate, confirming improved clarity and engagement across the catalog.

  • Time on page increased by approximately 31 seconds
  • Bounce rate decreased by approximately 5%
  • Variation interactions increased by approximately 31k events, indicating higher product exploration
  • Add-to-carts from similar items and often-bought-with swimlanes increased by approximately 84k
  • Add-to-carts for the primary product increased by approximately 4k

Platform outcomes

Post-launch analytics and experimentation confirmed stronger engagement and gave the team a clear evidence loop for continued optimization.

  • Enabled a scalable ProdX implementation with a consistent customer experience
  • More predictable handling of invalid combinations and edge cases across categories
07

Impact & lessons

The redesign improved the customer experience while giving Hy-Vee a more reliable way to implement ProdX across complex product categories.

Within the first month, related-product swimlanes generated about 84,000 additional add-to-carts, primary-product add-to-carts increased by about 4,000, and variation interactions increased by about 31,000 events.

  • The data model is part of the UX.
  • Edge cases reveal assumptions that normal flows hide.
  • Clear system rules make interface decisions faster and safer.
  • Platform constraints become design inputs when they shape customer behavior.

DESIGN SYSTEM APPROACH

Using Storybook as a shared design and engineering workspace

Hy-Vee already had Storybook with an engineer leading its implementation. We worked directly together: he brought component ideas and implementation questions to me, and I brought UX debt, interaction inconsistencies, and patterns I wanted the system to address.

That collaboration made the component library a practical working space between Product Design and Engineering. We could work through reusable behavior together while I was redesigning high-traffic ecommerce experiences across desktop, mobile, and app.

I carried forward a simple lesson: design systems are strongest when Design and Engineering shape them together. Engineering brings implementation constraints and reuse opportunities; Design brings interaction coherence, accessibility, and the product needs that feature work continues to reveal.

AI RETROSPECTIVE

How I'd approach this work with AI today

This redesign only worked if the variation rules held up across the complexity of a real-world grocery catalog. I worked through more than 100 product scenarios by hand to find the edge cases and write those rules.

Today I'd give AI the rules and a representative set of catalog data and test the model against a much wider range of product combinations. I'd use those results to confirm that the rules stay coherent across edge cases, sparse data, and category-specific variations. I'd also use the rules as shared AI context with Engineering and our product-data vendor so we were all reasoning from the same model.

My role would be to own the model itself: define the rules, set precedence, and decide which exceptions deserve explicit design treatment.

Customer & business impact

The redesign made high-variance products easier to understand and compare across the full decision flow through purchase.

  • Increased customer confidence when navigating complex product configurations by making variation logic predictable and trustworthy
  • Enabled deeper product exploration without increasing cognitive load, supporting informed purchase decisions
  • Improved the effectiveness of cross-sell and related-item interactions by clarifying how products related to one another

Platform & organizational impact

The product detail page became a stable system the organization could confidently build on.

  • Established a governed variation model that worked across categories without requiring separate redesigns
  • More reliable handling of invalid states and merchandising-driven variations by making variation rules explicit and shared
  • Enabled faster onboarding of new attributes and product types without fragmenting the customer experience

What I took from the work

Shared rules gave the interface a reliable foundation.

This work reinforced that:

Leading this effort required balancing short-term performance pressure with long-term platform integrity, ensuring the experience could evolve as the system grew more complex.

  • Design decisions connect visual clarity with data, merchandising, and engineering realities
  • Making constraints explicit early keeps implementation predictable and decisions easier to revisit
  • Shared system rules give teams a consistent basis for resolving individual UI states