Project Title

Membership Grid Reordering – February 2026

Introduction

In February 2026, I supported our Digital Producer with a seasonal optimisation initiative tied to our Mother’s Day gifting campaign. The commercial goal was to prioritise gift membership products by shifting them above core membership items on the RHS Join page. We chose Optimizely to run this change safely as an experiment so the team could measure its impact without modifying the underlying CMS templates. What initially looked like a straightforward hierarchy change revealed deeper frontend constraints, leading to a technical investigation into how the grid was rendered.

The Challenge

Despite applying multiple approaches—Optimizely Visual Editor rearrangements, JavaScript DOM manipulation, asynchronous timing, and direct Console testing—the visual order of the membership panels remained completely unchanged. Even when the DOM order updated correctly, the panels displayed in the original 1–2–3–4 structure. In early attempts, editing inline styles directly in the Visual Editor caused Optimizely to clone and replace nodes, which broke event listeners and CMS behaviours. This resulted in flashing panels and CTA URLs failing to navigate.

My Role

As Product Owner for Optimisation, I led the debugging and analysis of the issue, validated hypotheses through systematic testing, and ensured the chosen solution aligned with frontend architecture, CMS constraints, and CRO best practice. I consulted with engineering where necessary to confirm assumptions and to ensure the final approach was both safe and maintainable for experimentation.

Tools & Setup

Chrome DevTools — Used to inspect DOM, computed styles, and rendering behaviour.
Optimizely Web Experimentation — Used to apply controlled JS overrides at variation level.
JavaScript — Used to test DOM operations and implement the final fix.
CSS Grid — The underlying layout system determining panel placement.

What We Tested

Several hypotheses were explored:

1. DOM Reordering
2. Optimizely Visual Editor Moves (Before/After/Rearrange)
3. Asynchronous execution to wait for full CMS rendering
4. Waiting for elements before applying manipulation
5. Direct manual manipulation via DevTools Console

All methods successfully altered the DOM but failed to alter the displayed layout.

What I Found

1. CSS Grid template areas, not DOM order, controlled the visual layout

Using DevTools, I discovered that the membership grid used fixed named grid areas:

.membership-grid {

display: grid;

grid-template-areas:

'a1 a1 a2 a2'

'a3 a3 a4 a4';

}

This meant the browser ignored DOM order entirely and positioned each panel into predefined slots (a1, a2, a3, a4).

2. To support the Mother’s Day campaign, gift products needed priority

The experiment required moving gift products (items 3 and 4) into the top grid slots (a1, a2).
However, changing the DOM alone could not achieve this because CSS Grid overrode the sequence.

3. Editing inline styles in the Visual Editor broke CTA behaviour

When the Digital Producer applied inline grid-area changes using Optimizely’s HTML editor, Optimizely internally cloned and replaced the <li> elements. This caused:

• Loss of CMS-bound event listeners
• Broken CTA URLs
• Panel “flashing” on click
• Parent-level click interception

This reinforced that structural edits inside the Visual Editor are unsafe for CMS‑driven components.

4. The reliable solution was to override grid-area via JS, not change the DOM

By applying the grid-area override through JavaScript at runtime, we could safely:

• Reposition items visually
• Preserve original CMS behaviour
• Avoid Optimizely wrapper nodes
• Keep the change fully variant‑scoped
• Avoid touching global CSS or templates

This allowed us to elevate gift products for the campaign while ensuring stability.

The Solution

A lightweight, ES5-safe override was applied through Optimizely:

JavaScript

(function () {
  try {
    var i1 = document.getElementById('membership-item-1');
    var i2 = document.getElementById('membership-item-2');
    var i3 = document.getElementById('membership-item-3');
    var i4 = document.getElementById('membership-item-4');

    if (i3) i3.style.gridArea = 'a1';
    if (i4) i4.style.gridArea = 'a2';
    if (i1) i1.style.gridArea = 'a3';
    if (i2) i2.style.gridArea = 'a4';
  } catch(e) {}
})();

This updated the visual order instantly while keeping all CTA functionality intact. The performance impact is effectively negligible, as the script sets four inline style properties once per page load.

What I Learned

What worked well:
Using computed CSS properties in DevTools to compare visual grid placement vs DOM order quickly revealed the root cause.

What we decided:
For CSS Grid-based components, visual order changes must target grid-area or order rules. DOM moves will not affect layout.

What I’d do differently:
Inspect the rendering model (grid or flex) earlier in the process before attempting any structural manipulation.

Surprises:
How consistently CSS Grid can override expected behaviour—even when DOM updates appear correct.

Visuals

Final Implementation: CSS Grid Override and DOM Verification

This screenshot shows the final implementation: on the left, the membership panels appear in their new positions (Gift Membership now in A1/A2, core items in A3/A4). On the top right, DevTools displays the CSS grid-template-areas that define the layout, and on the bottom right, the Console output confirms our JavaScript successfully reassigned each panel’s grid-area value. This demonstrates how overriding CSS Grid — not the DOM — achieved the correct visual order.

Before and After: Updated Panel Order for Mother’s Day Campaign

These screenshots compare the original layout (core membership items first) with the updated experiment version where gift membership products were elevated to the top. This visual change supported the Mother’s Day gifting strategy while being delivered safely through Optimizely without modifying CMS templates.

Final Variant Implementation in Optimizely

This screenshot shows the final Optimizely implementation of the experiment. At the top, the variation’s custom JavaScript reassigned each membership panel’s grid-area value to create the Mother’s Day hierarchy (Gift items first). At the bottom, the live page preview reflects the updated visual order. This illustrates how applying CSS overrides via JavaScript — rather than editing HTML or restructuring the DOM — safely produced the correct layout without affecting CMS logic or core templates.

Feedback

If you’ve used alternative approaches to reordering grid-based components in experimentation, or have recommendations for reusable grid/flex diagnostics, I’d welcome the discussion.