The Need
Conversion was constrained by inconsistent hierarchy, unclear value communication, and mobile friction.
What I Led
Defined and executed a new PDP framework balancing merchandising goals, technical constraints, and user clarity.
How it Worked
Re-architected decision-critical content, simplified variation logic, and introduced modular components for scale.
Impact
Established a scalable PDP architecture that reduced evaluation friction and enabled ongoing optimization.
Context
This redesign took place during a major platform transition from a legacy in-house product data system to ProdX, a vendor platform built to manage product variations, substitutions, and related products at scale.
While ProdX introduced greater flexibility, it also imposed new structural constraints that directly shaped the customer experience.
At the same time, the existing PDP was already under strain. Variation logic surfaced invalid combinations, unrelated products appeared selectable, and small updates introduced outsized risk. The experience did not scale cleanly across complex categories or support merchandising effectively.
This became a system-level redesign of how product data, variation logic, and presentation worked together under real business and technical constraints.
Business Stakes
The redesign needed to strengthen customer confidence and engagement while protecting active revenue during a live platform migration. Any structural misstep risked invalid product states, broken purchasing flows, or measurable revenue loss at scale.
Success required improving performance without destabilizing production systems.
Team
Product, Engineering, Platform Vendor (ProdX), Merchandising, and Operations.
Cross-functional coordination across platform architecture and merchandising strategy.
Constraints
Impact Snapshot
I served as Lead UX Designer with end-to-end responsibility across strategy, research, system design, and delivery.
Beyond interface design, I led edge-case analysis, competitive and best-practice research, experimentation planning, and post-launch analytics to ensure the solution scaled technically and commercially. I also represented design in direct negotiations with ProdX, advocating for implementation changes needed to support real-world product complexity.
Key contribution: Defined and negotiated the system rules governing product variation behavior across categories, aligning product, engineering, and the vendor around a shared foundation that reduced risk, supported scale, and informed future initiatives.
This work required leadership at the intersection of user needs, system architecture, and business risk.
Working closely within the product triad, I facilitated sessions, synthesized research into direction, and challenged solutions that introduced risk or failed to account for critical edge cases.
The goal was a platform that could handle real product variation without depending on brittle rules.
The product detail page had two connected problems: customers were seeing confusing product variations, and Hy-Vee was moving product data from a legacy in-house system to ProdX. The new platform added capability, but its default model did not reliably match how real grocery products varied across categories.
The design problem was bigger than cleaning up the page. The variation rules had to become predictable before the experience could.
Existing product detail page before the redesign and ProdX migration.
The existing product detail experience was already fragile before this initiative began.
Product variations were often incorrect, and items presented as variations were frequently unrelated products. Customers struggled to understand differences, compare options, or trust what they were seeing. Small changes introduced outsized risk, making iteration slow and confidence low.
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 at scale. While ProdX introduced greater capability, it also imposed structural constraints that would directly shape what experiences were possible at the interface level.
If those constraints were misunderstood or accepted too early, the resulting experience would fail regardless of visual polish.
Early exploration showed that the challenge was not simply adapting the interface to new constraints, but confronting how those constraints shaped the experience itself.
Auditing more than 100 real product examples made it clear that ProdX’s default variation model could not reliably represent how customers understood product differences. Variation categories lacked a clear primary anchor, secondary attributes were inconsistently scoped, and state changes triggered page and URL behavior that broke continuity.
Without clearer authoring and governance rules, the migration would carry the same customer confusion into a more complex platform.
If the variation system was implemented incorrectly, the organization would inherit a more complex platform without realizing its benefits. Customer trust would erode, teams would depend on fragile workarounds, and future product growth would be constrained by early system decisions.
This project required rethinking the system that powered the experience.
I audited more than 100 products across categories, deliberately focusing on edge cases instead of ideal examples. The audit exposed unrelated products grouped as variations, legitimate variations split apart, ambiguous attribute hierarchies, and failure states that standard flows and vendor prototypes did not reveal.
Interface changes could not compensate for bad variation logic upstream.
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:
The pattern was consistent enough that variation rules had to be defined, validated, and enforced at the system level before interface decisions could succeed.
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 inconsistent category logic, ambiguous variation hierarchies, and failure modes that were not apparent in standard flows or vendor prototypes. These findings became the foundation for defining variation rules, pressure-testing system assumptions, and aligning Product, Engineering, and ProdX on what the experience actually needed to support.
In parallel, I led structured discovery across internal teams, competitive platforms, and industry research to pressure-test assumptions and identify proven patterns.
This included:
This work surfaced a clear gap between platform defaults and customer expectations, reinforcing the need for a rules-driven system rather than ad hoc configuration.
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.
I turned the audit findings into explicit rules for variation definitions, precedence, exclusions, substitutions, related products, pricing, and availability. That gave Product, Engineering, Merchandising, Operations, and ProdX a shared model 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, instead of asking the UI to hide upstream inconsistency.
Variation rules used to make product relationships explicit before interface design.
The core challenge was not designing a better interface, but 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, not just a design configuration.
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.
ProdX’s default implementation did not support several of these requirements.
I led a working session with ProdX’s founder, alongside our product owner and engineering counterparts, to walk through real product failures from the audit, show where default assumptions broke down, and advocate for changes to attribute handling and rule flexibility.
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.
Once the system rules were defined, I could design against explicit behavior instead of guessing at edge cases.
I worked with engineering to ensure that:
Design decisions were now grounded in explicit rules rather than assumptions, reducing ambiguity across teams and lowering long-term maintenance risk.
With the strategy aligned and platform constraints understood, the work shifted to formalizing the variation system as a durable foundation. This was not just a design pattern. It was a governance model for maintaining clarity, preventing invalid states, and scaling as the catalog evolved.
Not every product attribute should be treated as a customer-facing variation.
A major failure of the existing experience was that true variations, descriptive attributes, and related products were handled the same way, creating confusing and unpredictable behavior.
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 without redesigning the PDP or relying on UI-level exceptions.
Many products qualified for multiple variation attributes at the same time. Without precedence rules, outcomes became unpredictable.
I established logic for:
These rules ensured each product resolved to a single, predictable variation structure.
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 without needing to know how ProdX worked underneath.
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.
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:
The goal was not to expose system complexity, but to absorb it so customers could move forward with confidence.
Early concepts explored how to express variation logic without overwhelming customers.
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 in a way that felt helpful rather than distracting.
Each interaction was designed to reflect the system’s intent:
Customers were never asked to interpret internal complexity. The experience behaved logically by design.
Execution was tightly coordinated with engineering to ensure fidelity between system logic and interface behavior. Rather than handing off static designs, I worked iteratively with engineers to validate that:
This reduced rework and prevented late-stage surprises.
The final experience felt simpler even as the underlying system became more robust. 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 framework that could scale with more confidence.
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 without outside explanation.
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 one month.
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 it was understandable without guidance.
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 were not just selecting variations correctly; they 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
Result
Moving relevant alternatives earlier in the decision flow improved both engagement and swimlane conversion.
Within the first month of launch, the redesign improved engagement, add-to-cart behavior, and the metrics we used to evaluate the product detail experience.
Engagement & Confidence
Conversion & Revenue Signals
System & Platform Outcomes
These results showed that the redesign improved more than page-level clarity. It changed how customers engaged with complex product configurations and created a stronger foundation for ongoing optimization.
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.
Post-launch analytics showed higher variation interaction, more add-to-cart activity, longer time on page, and lower bounce rate.
The redesign improved more than the purchase moment. It made high-variance products easier to understand and compare across the decision flow.
The product detail page shifted from a fragile, case-by-case solution to a stable system the organization could confidently build on.
Complex systems require shared rules, not just better interfaces.
This work reinforced that:
Leading this effort required balancing short-term performance pressure with long-term platform integrity, ensuring the experience could evolve without collapsing under its own complexity.
