Lead Product Designer · Product design · Interaction design · Discovery · Experimentation
ProdX added two API attributes and Hy-Vee gained a scalable product-variation model that could handle category-specific edge cases.
The PDP had to improve during a live platform migration, with varied product data, category-specific edge cases, and vendor dependencies.
Similar Items conversion moved from 0.82% to 1.49%. In the first month, related-product add-to-carts increased by about 84k, primary-product add-to-carts by about 4k, and variation interactions by about 31k.
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 product detail page before the redesign and ProdX migration.
- 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.
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 was essential; visual refinement alone was not enough to produce a reliable experience.
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.
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.
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 work across categories, not just common examples.
- The vendor model had to be tested against real commerce data.
Edge-case product audit used to expose where variation logic broke across real categories.
Discovery focused on how product variation logic actually behaved in the real world, not how it was intended to work on paper. Rather than starting with interface concepts, I focused on where the existing experience broke down and why. That meant looking beyond screens into how product data was structured, governed, and interpreted across systems.
A core part of discovery involved auditing more than 100 edge-case products across categories.
These were not theoretical scenarios. They reflected real products with complex combinations of sizes, flavors, bundles, substitutions, and near-duplicates that regularly surfaced incorrect or misleading variations in the current experience.
Patterns emerged quickly:
- 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
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.
In parallel, I led structured discovery across internal teams, competitive platforms, and industry research to test assumptions and identify proven patterns.
This included:
- 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
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.
- 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.
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.
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 was to solve the product model and the interface together so the UI did not have to compensate for upstream inconsistency.
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:
- 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
- Remain understandable to merchants and operators, not just engineers
Variation logic had become part of the product infrastructure, affecting both the product model and the interface configuration.
- 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.
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.
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.
Variation rules defining which attributes qualified as true variations, how conflicts resolved, and how the system stayed predictable across product categories.
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.
I authored a comprehensive set of variation rules defining:
- 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
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.
Not every product attribute should be treated as a customer-facing variation.
A key design insight was that true variations, descriptive attributes, and related products needed different behavior, making product behavior harder for customers to interpret.
I defined a clear distinction between three attribute types:
- 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.
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.
Many products qualified for multiple variation attributes at the same time. Precedence rules made those outcomes predictable.
I established logic for:
- Attribute prioritization
- Conflict resolution
- When variation groups should collapse or expand
- How safe defaults were selected
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.
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 product detail experience on desktop, built around the new variation rules.
Designing With Explicit Rules
With the variation system defined, experience design could move forward with more clarity. Decisions were no longer driven by edge-case guesswork or UI workarounds, but by explicit rules governing how products should behave across categories.
This allowed the interface to focus on clarity, predictability, and trust.
The redesigned product detail experience needed to:
- 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
The goal was not to expose system complexity, but to absorb it so customers could move forward with confidence.
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:
- Only surface meaningful choices
- Let structure do the work
- Favor predictable layouts over highly conditional patterns
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.
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:
- 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
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.
Execution stayed tightly coordinated with engineering so the rules and interface behavior remained aligned. I worked iteratively with engineers to validate:
- The design accurately reflected rule resolution
- Edge cases behaved consistently across scenarios
- Changes to system logic propagated safely through the experience
This made implementation more predictable and surfaced important questions earlier.
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.
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.
Usability testing showed strong task success across the core product-detail flows.
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:
- 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
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.
To validate a key system-level decision, we ran a focused A/B test on the redesigned product detail page.
Test
- 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
Result
- Swimlane conversion increased from 0.82% to 1.49%
- The higher placement outperformed the lower placement and reached clear statistical confidence within one month
Moving relevant alternatives earlier in the decision flow improved both engagement and swimlane conversion.
Post-launch analytics and experimentation confirmed stronger engagement and gave the team a clear evidence loop for continued optimization.
Behavioral Signals
- 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
Conversion & Revenue Signals
- 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
- The A/B test showed swimlane conversion improved from 0.82% to 1.49% when “Similar Items” appeared above the product description
System & Platform Outcomes
- Enabled a scalable ProdX implementation with a consistent customer experience
- More predictable handling of invalid combinations and edge cases across categories
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.
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.
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.
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.
- 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
The redesign made high-variance products easier to understand and compare across the full decision flow through purchase.
- 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
The product detail page became a stable system the organization could confidently build on.
Complex systems require shared rules, not just better interfaces.
This work reinforced that:
- Design decisions must account for data, merchandising, and engineering realities, not just visual clarity
- Making constraints explicit early keeps implementation predictable and decisions easier to revisit
- Strong outcomes come from aligning teams around system behavior, not debating individual UI states
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.
