Rebuilding a Compression PDP Without Rebuilding Dawn's Variant Engine

Compression garments are harder to shop than ordinary apparel. A single product page has to carry two very different kinds of choice at once, and only one of them should change what goes in the cart. This is how the Absolute Support product page kept a custom, compression-aware interface on top of Shopify's own variant, price, URL, product-form, and cart behavior, without building a second commerce system to fight the first.

This is one of three deep dives from the Absolute Support case. It sits alongside the filtering deep dive and the merchant-editable sections deep dive.

The problem, in one paragraph

Absolute Support sells compression socks, sleeves, and hosiery. Buying one means resolving several decisions together: the compression level (measured in mmHg), the size, the garment type, the gender fit, and how many pairs come in a pack. Compression level is the decision that carries clinical weight, and it is the easiest to get wrong. If it sits in the same dropdown as color, a shopper can pick "20 to 30 mmHg" the way they pick navy over black, without registering what the number means. The page had to make that distinction clear, and it had to teach without pretending to give medical advice.

Constraints

A few boundaries shaped every decision that followed.

• Shopify owns purchase state. Variant selection, price, the product URL, the add-to-cart form, and the cart are platform behavior. Reimplementing them invites subtle, costly bugs at the exact spot a store makes money.
• The theme is Dawn. Dawn already ships a tested variant system. The brief was a pixel-specific custom interface, not a new commerce runtime.
• Compression is not a purchasable option here. In this catalog each product represents one clinical level. Level is a property of the product, not a switch the shopper flips.
• Medical-adjacent copy needs care. Guidance can describe and compare. It must not diagnose, promise an outcome, or tell someone which level treats their condition.

The decision: two kinds of product data

The core move was to separate data that describes the product from data that changes what you buy.

Compression level        Color · Size · Pack
(product attribute)      (Shopify variants)
      |                        |
      v                        v
  tier display             variant ID
  comparison view          price
  educational context      product URL
      |                        |
      v                        v
 describes the product    changes the cart

Legend:

1. Compression level is a product attribute. It drives a tier display, a comparison view, and educational context. It never changes the cart.
2. Color, size, and pack are Shopify variants. Each combination resolves to a variant with its own ID, price, and URL, and that is what the cart receives.

In one line: compression level says what the product is; color, size, and pack say which exact configuration you are buying. A quick note for readers new to Shopify: a "variant" is a specific purchasable combination of options, and it is the unit Shopify prices, links to, and adds to the cart.

Why Dawn stayed the source of truth

The custom controls are presentation. The moment a shopper changes one, the work hands off to Dawn.

Custom selectors          (authored presentation)
  color · size · pack
        |
        v
Dawn variant state        (native)
        |
        v
Selected variant          (native)
  price · product URL · product form
        |
        v
Cart                      (native commerce output)

On a phone this reads top to bottom, which is also how the browser stacks it. Nothing here is a parallel state store. The custom layer sets values; Dawn decides what those values mean. Keeping a single source of truth is the whole point: two systems tracking "the selected variant" is how a page ends up showing one price and charging another.

Implementation walkthrough

The detail that makes this work is that the custom controls are not wired to bespoke logic. They feed the same inputs Dawn already reads.

Custom controls map one to one to native options. Each color swatch, size button, and pack option corresponds to a product option Dawn understands. Selecting one writes the shopper's choice into the native option inputs rather than into a private variable.

Dawn resolves and re-renders. Dawn's variant-selects custom element reads those inputs, finds the matching variant, and re-renders the product information from the server. Because Dawn owns that step, the price and the "you save" text refresh on their own.

The custom price lives inside the re-rendered region. The custom price and savings markup is placed inside the part of the page Dawn re-renders on a variant change. So it updates with the variant automatically, with no separate price-watching script and no second copy of the number to keep in sync.

Pack savings come from real variant prices. For multi-pair packs, the template compares each pack against the single-pair variant's per-pair price and shows the actual difference. The discount is derived from live prices, not typed into the design.

URL and cart stay native. The product URL updates to the selected variant and the add-to-cart form submits that variant, both standard Dawn behavior. A shared link reopens on the same variant.

One set of controls. There is no duplicated mobile-versus-desktop selection block. The same controls are restyled responsively, so there is never a second, stale copy of the shopper's choice.

The compression comparison interface

Compression level is handled entirely on the descriptive side.

• The page reads the product's level from its product data and shows the matching tier.
• A shopper can open a comparison view that lays the tiers side by side: Mild (8 to 15 mmHg), Moderate (15 to 20), Firm (20 to 30), and Extra Firm (30 to 40), each with a plain-language note on typical use.
• The view includes a prompt to consult a medical professional.

This interface compares and explains. It does not diagnose, and it does not tell anyone which level to buy for a condition. That boundary is deliberate, and it is a content rule as much as a code one.

What stayed native

I restyled the buy box. I did not fork its behavior. These stayed Shopify and Dawn:

• Product form and add to cart
• Variant selection and state
• Price and compare-at price
• Product URL
• Cart and cart drawer
• Checkout

Verification

What I can verify is the implementation, not a business result.

• Compression level is modeled as product data, separate from variants.
• Custom controls update Dawn's native variant state.
• Price, product URL, product form, and cart stay aligned with the selected variant.
• Pack pricing is derived from real variant prices.
• The source of truth for purchase state remains Shopify's.

I make no claim about conversion, returns, or any health outcome, and none of those would follow from this work alone.

Trade-offs

• Dawn upgrades need reconciliation. The custom buy box tracks Dawn's variant contract, so a future Dawn change to that area needs a hands-on pass.
• Some comparison content is fixed in code. Parts of the tier copy live in the template rather than in editable settings, so changing that wording currently needs a developer.
• The model depends on stable conventions. It relies on a consistent compression tag and a predictable pack pattern. Off-pattern data falls back quietly rather than erroring, which is safe but easy to miss.
• Medical-adjacent copy needs governance. Descriptive language can drift toward advice, so edits to this content need review.

What I would improve next

• Move the remaining fixed comparison copy into editable settings so the team can adjust wording without a developer.
• Add automated variant-matrix testing across color, size, and pack so a data change that breaks a combination is caught early.
• Document the compression-tag and pack conventions the model relies on.
• Complete keyboard and focus verification for the comparison view.

Next: Custom Filtering UI on Shopify Search & Discovery, which applies the same idea to the collection page. Custom interface on top, native engine underneath.