Shopify Theme Engineering · Medical Commerce
Extending Dawn for a Complex Compression Catalog
I designed and built a custom visual, educational, and product-selection layer for a medical compression storefront, while Shopify's native product form, variant state, cart, search, and filtering stayed the source of truth underneath.
View live store- Shopify
- Dawn
- Search & Discovery
- Metafields
- OS 2.0
Native and custom, mapped
The customer sees a bespoke interface. Purchase-critical state stays native.
Native Shopify and Dawn
Inherited- Product form
- Variant state
- Price updates
- Product URL
- Cart behavior
- Search & Discovery facets
- Predictive search
- Customer accounts
- Checkout
Authored presentation
Authored- Compression-aware buy box
- Color, size, and pack selectors
- Compression comparison view
- Mobile filter presentation
- Dual-handle price slider (over native facets)
- Grid and list toggle (presentation)
- Reusable OS 2.0 sections
- Metafield-driven overrides
Integrated and configured
Configured- Search & Discovery configuration
- Product and collection taxonomy
- Theme editor controls
- Metafield data conventions
- Client
- Absolute Support, an established US compression brand
- Theme
- Dawn 15.4.1, extended
- Role
- Sole Shopify theme engineer
- Scope
- Storefront visual and educational layer, custom product page, custom discovery interface, merchant-editable sections
- Core work
- A compression-aware product page, custom filtering on Search & Discovery, and a reusable OS 2.0 content section library
- Industry
- Medical and everyday compression garments
- Platform
- Shopify
Custom experience, native commerce engine
Dawn already ships reliable, well-tested commerce behavior. Rewriting it adds risk and maintenance for no customer benefit. So I kept it and built a custom interface on top. The visual, educational, and product-selection layer is authored. The systems that hold variant state, price, the product URL, the product form, and the cart stay native.
The value here is in the restraint. A smaller custom surface means lower integration risk and less to maintain as Shopify and the installed apps evolve.
The interface is custom. Price, URL, variant state, and cart still belong to Shopify.
A product decision more complex than ordinary apparel
Absolute Support is an established US compression brand, selling compression socks, sleeves, and hosiery. Its catalog is harder to shop than ordinary apparel, because a single purchase involves several decisions at once: compression level, size, garment type, gender, and multipack quantity.
Compression level, measured in mmHg, is the decision that matters most and the easiest to get wrong. The storefront needed to make compression, sizing, and pack selection clear, and to educate the shopper without acting as medical advice. The storefront runs on Shopify, with Dawn as its foundation, which set the central constraint for everything that followed.
One purchase, five decisions
- Compression levelPrimary decision
- Size
- Garment type
- Gender
- Pack quantity
Product data
Separating a clinical attribute from purchasable variants
Color, size, and pack quantity are purchasable options. Compression level describes the product itself and carries a different decision weight. When they share one dropdown, a shopper can select a compression strength the way they pick a color, without understanding it. So I separated the two.
Compression level, as a product attribute
Compression level is treated as a property of the product, not a variant. Each product carries its level in its product data, and the page reads that value to show the matching tier. The range spans lighter everyday support through higher compression strengths, including levels commonly selected with professional guidance. A shopper can open a comparison view that lays the tiers out side by side, with plain guidance on typical use and a note to consult a medical professional. The guidance is framed as education, not diagnosis.
Color, size, and pack, as variants
Color, size, and multipack quantity, one, three, or six pairs, stay as ordinary Shopify variants. Pack savings are calculated from the variant prices, so a larger pack can show its real per-pair discount and a value badge.
Custom controls, native state
The custom color, size, and pack controls were designed and implemented as the storefront presentation layer, and they feed Shopify's native variant state. When a shopper changes an option, Dawn handles the variant switch, refreshes the price, updates the product URL, and drives the cart. The custom price and savings display sits inside Dawn's variant container, so Dawn's own re-render keeps it accurate. There is one source of truth for price, URL, and cart state, and it is Shopify's.
Everyday support
Describes the product, or changes the purchase
Product attribute
Describes the product
Shopify variants
Changes the purchasable configuration
How a custom control drives native state
Production implementation
View live storeCustom discovery on Shopify's native facet engine
The catalog is organized so shoppers can enter from whichever axis they think in: garment type, compression level, condition, or gender. That taxonomy combines Shopify admin configuration with custom theme presentation. Collection filtering runs on Shopify Search & Discovery, the native facet engine. On top of it, I built a custom interface: a mobile filter bar, a dual-handle price range slider, and a grid or list toggle that remembers the shopper's choice. Those controls pass their actions into the native facet form, so filtering and sorting stay Shopify-native while the presentation is custom.
The storefront also includes a tag-based product finder. A shopper selects gender, compression level, and style, and the finder routes them to the matching collection. It is a fast shortcut into the catalog, a tag-based navigation shortcut, not a quiz, a recommendation engine, or a diagnostic tool.
Read the filtering deep diveFiltering path
Custom storefront, routine updates without a developer
A storefront the internal team cannot edit becomes a standing bill for developer time. So the content layer was built as reusable Shopify OS 2.0 sections, controlled from the theme editor.
- Update section images, copy, CTAs, and FAQ entries
- Select products and collections through native pickers
- Configure the finder's options and destinations
- Override feature content per product through metafields
- Rely on a banner fallback chain, so new collection pages look complete before anyone edits them
Two choices keep this safe to reuse: every section ships presets and blocks for the theme editor, and there are no hardcoded product IDs in the section code.
Navigation logic, the underlying data conventions, and structural layout changes still require development.
Read the section-layer deep diveMetafield override
What is verified, and what is expected
Verified in the implementation
- Dawn-native product and cart behavior preserved
- Compression modeled separately from purchasable variants
- Custom selectors feed native variant state
- Custom filtering presentation runs on Search & Discovery
- A reusable, merchant-editable content layer
- Price, URL, variant, and cart share one Shopify source of truth
Expected, not measured
- Clearer product selection for a medically complex catalog
- Less developer involvement in routine content updates
- Lower integration risk than replacing native commerce systems
No conversion, revenue, SEO, or performance measurement was part of this engagement.
Honest trade-offs
Overlapping section patterns
Why it exists: A few banner and education sections share similar layouts.
What I would do next: Consolidate them into fewer parameterized sections.
Some educational copy is fixed in code
Why it exists: Certain comparison cards live in the template rather than in editable settings.
What I would do next: Move that wording into section settings.
Tag-based discovery depends on clean data
Why it exists: Levels and styles are driven by product tags, so consistent tagging matters.
What I would do next: Normalize the tag conventions. This is data hygiene, not a defect.
A future Dawn upgrade needs reconciliation
Why it exists: The custom layer will need hands-on work when Dawn updates.
What I would do next: Keep the changes concentrated in a small number of files, which keeps the cost manageable.
These define the maintenance work I would prioritize next.
Related deep dives
Three implementation stories from this project.
Rebuilding a Compression PDP Without Rebuilding Dawn's Variant Engine
How compression level became a product attribute with a comparison view, while color, size, and pack stayed native variants feeding Shopify's variant state.
Custom Filtering UI on Shopify Search & Discovery
A mobile filter bar, dual-handle price slider, and view toggle that pass their actions into Shopify's native facet engine instead of replacing it.
A Merchant-Editable Section Layer on Dawn
Reusable OS 2.0 sections with presets, per-product metafield overrides, and a banner fallback chain, with no hardcoded product references.
Selected stack
Theme foundation
- Dawn 15.4.1
- Shopify Liquid
- OS 2.0 sections and blocks
Product modeling
- Shopify variants
- Product metafields
- Native product form
Discovery
- Shopify Search & Discovery
- Collection facets
- Product tags
Frontend
- Liquid
- CSS
- JavaScript
- Theme editor schema
Ownership
Precise by design: I inherited Dawn and Shopify's commerce engine, extended the theme, configured Search & Discovery and the taxonomy, integrated metafields and the theme editor, and authored the presentation layer. Nothing here was built from scratch.
Next case
Boxwood Coffee
A disciplined Prestige adaptation for a specialty roaster, preserving proven commerce behavior and adding custom code only where coffee-specific data and navigation required it.
Need a custom Shopify experience without replacing the platform underneath?
I design and build storefront layers around real catalog, merchandising, and platform constraints, while keeping purchase-critical systems reliable and maintainable.
Start a conversation