2U Theme Experimentation

Documentation for CRO testing across the WordPress multi-site publishing platform for 2U’s University Partner Degree Websites.

Overview | Environments | Scope | Implementation | Process

Overview

This documentation portal outlines the latest workflow for building experiment variations within the current 2U Degree Site WordPress Theme. Key areas are outlined on this page, and sub-pages are forthcoming with additional detail. A portal sitemap will be added to this page as they become available.

As the current theme evolves under the CMS Modernization Project, experiment variations must meet these core requirements:

  • Designs must be produceable via the existing Gutenberg block components without custom code deployment.
  • Variation building must occur within approved UAT environments.
  • Variations are implemented via the Versions Block with Optimizely CSS for visibility toggling only.

Environment Boundaries

UAT Access Only: Experimentation work and variation building may only occur within the UAT environment. There must be no attempts to log into production environments. Production implementations and content transfers are handled entirely by the MarTech team in coordination with Web Operations. See full list of UAT environments below.

Design & Technical Scope

Designs & variation builds must be scoped and developed within these boundaries:

  • No Custom Code – Blocks Only: Experiments must be executed directly within the CMS using existing WordPress core blocks, components, and native layout configurations. Do not inject large custom HTML, custom JS, or CSS workarounds.
  • Responsive Block Behavior: Instead of isolating mobile-only structural variations, all tests must evaluate desktop and mobile views simultaneously. Building within the native block system solves cross-device layout stability upstream, as the core components contain built-in responsive parameters.
  • No Form Code Interference: There must be no alterations to Taxi lead form configurations, lead routing, hidden fields, tracking logic, or Airtrain form integrations.

Theme Modernization: Overview & Migration

Platform Direction

The CMS Modernization Project is moving the Degree multisite theme from a fragmented collection of site-level settings and custom implementations to a more centralized, governed WordPress framework. As part of the broader modernization effort, the new theme is intended to improve platform consistency, performance, maintainability, accessibility, and the scalability of content and experimentation workflows.

The modernized theme will provide:

  • Better performance and editing speed: The legacy Vibram theme pipeline will be retired in favor of a faster, more stable WordPress-native foundation.
  • Stronger brand and layout consistency: Shared design tokens and governed templates will replace many independent site-level settings and reduce visual drift.
  • A standardized component and pattern library: Editors and CRO teams will work with a defined set of reusable blocks and patterns rather than open-ended page structures.
  • Improved SEO and AI visibility: Cleaner server-rendered markup, structured metadata, and automated schema will make content easier for search engines and AI systems to interpret.
  • Built-in accessibility safeguards: Custom components and patterns are being developed to meet WCAG 2.2 Level AA requirements.
  • More scalable experimentation: The new architecture is designed to make successful variations easier to maintain and deploy without repeating the same implementation work across individual sites.

How the Migration Works

This is a content-and-configuration migration within the existing WordPress VIP platform.

The transition includes four main stages:

  1. Automated block translation
    Migration scripts map existing legacy blocks to their closest equivalents in the new library of WordPress Core, Ignite, and custom blocks.
  2. Content review and refinement
    The 2U team reviews migrated pages, removes outdated content, updates assets, and resolves layout or content issues that require manual attention.
  3. Quality assurance and validation
    Each site is reviewed for content accuracy, accessibility, SEO, analytics tracking, responsive behavior, and integration stability.
  4. Phased rollout
    The new theme will launch first on a pilot site, followed by a guided handoff and staggered migration of additional sites. Migration scripts may be run again for later-stage sites so that more recent content changes can be included before launch.

Experimentation During the Transition

The current theme uses a combination of WordPress Core blocks and legacy custom blocks. Those blocks are being mapped into a new, more standardized component system.

Although content and functionality will be carried forward where possible, the new theme will not reproduce every section with identical styling or layout behavior. The degree of visual change will vary by block and by section. Spacing, typography, responsive behavior, markup, and available configuration options may change as content moves into the new framework.

Because of this, experiments created during the transition should focus on changes that remain meaningful even if the surrounding presentation changes during migration.

All experiment variations must be built within WordPress using the current theme’s existing blocks, settings, and supported configurations.

During this transition period, the following are out of scope:

  • Net-new components built specifically for the legacy theme
  • Custom theme development
  • Custom markup or behavior that falls outside the existing block system
  • Heavy styling overrides that depend on the current theme’s exact presentation
  • Changes to forms, integrations, or other platform functionality that require behavior beyond what is confirmed to work out of the box
  • Designs whose value depends on preserving the current theme’s exact visual treatment after migration

Because of migration risk, the need to avoid throwaway development on the legacy theme, and uncertainty about how custom work would carry into the new architecture, a custom code exception for legacy-theme experiments is not viable during this bridge period. Broader experimentation capabilities and any future exception process will be reconsidered for sites operating on the modernized theme as its supported workflows become clearer.

This boundary also keeps the transition aligned with the purpose of the modernization effort: moving experimentation toward reusable, governed platform capabilities rather than recreating one-off implementations that make testing difficult to maintain and scale. MarTech will continue working with CRO as the new theme’s capabilities come into focus, sharing updated guidance and helping the testing strategy move forward within the supported paths.

What to Prioritize Right Now

Experiment proposals should focus on changes that can be created cleanly with the current block library and that will still produce useful learning through the migration.

Examples include:

  • Copy and messaging changes
  • Headline and CTA updates
  • Image changes
  • Reordering existing sections or content
  • Adding or removing existing blocks
  • Adjusting supported block settings and configurations
  • Testing different content groupings within existing layout capabilities
  • Responsive variations that use the native behavior of the current blocks

Platform Assessment for Future Consideration

Concepts that fall outside the currently supported capabilities should not proceed into design or development during the transition period.

While CRO develops the broader approval workflow, MarTech will document a written platform assessment for these concepts. The assessment will:

  • Explain the current platform constraint
  • Identify the capabilities, dependencies, and technical assumptions involved
  • Note where Engineering input may be needed
  • Evaluate likely implementation effort, maintenance burden, and technical debt
  • Record whether the concept may be worth revisiting as the new theme’s capabilities become clearer

Engineering may be consulted as needed to validate technical assumptions, but the assessment does not create an exception pathway during the bridge period.

This provides a practical way to preserve useful ideas, explain why they cannot move forward now, and build a clearer basis for evaluating future options as the new theme matures.

Experiment Implementation via the Versions Block

To implement variations within the WordPress platform, utilize the native Versions Block built into the 2U Theme.

  • Version 1: Contains the control (visible by default; can be left empty if the variation introduces entirely net-new content).
  • Version 2+: Contains the variations (hidden by default). Optimizely targets the assigned CSS class to toggle visibility.

Current Approved CSS Swap Pattern

This CSS swap is the only custom code injection permitted, with the exception of solving for footnote accessibility compliance when variations introduce new footnotes to the core footnotes block.

/* Replace “.class-name” with the relevant class name added in WordPress */
.class-name [class*=’version-1′] {
    display: none;
}
.class-name [class*=’version-2′] {
    display: block;
}

Process Summary

Below is a tentative process outline as we ramp up block-native variation building. Process tracking and WebOps support are TBD, pending learnings from dry runs + first batch testing.

StepPhaseActionOwnerNotes
0
Analysis
Ideation
Design
All pre-build CRO processes + approvals

Platform-native design
CRO
Spiralyze
Documentation enhancements ongoing per MarTech to better inform design process
1
WordPress Variation Build 
Identify existing control content and wrap it within a Versions Block in UAT at the smallest reasonable level. 

Construct variants using 2U components.Assign unique CSS classes (ex: curriculum-copy-test) to bridge WordPress and Optimizely.
Spiralyze
MarTech available to Spiralyze devs for CMS support
2
Review
CRO + MarTech Review
CRO
MarTech
Review process subject to change as CRO approval matrix develops
3
UAT Handoff & Publish
MarTech copies finalized Versions Block from UAT to Production

MarTech publishes
MarTech
Variants hidden by default, safe during test setup

Notify WebOps
4
Optimizely Setup
Spiralyze configures + previews the Optimizely experiment 
Spiralyze
CSS for variation visibility switching only
5
Launch Experiment
Spiralyze publishes the Optimizely experiment to begin routing live traffic to the variations.
CRO
MarTech
CRO Preview link check

MarTech implementation support
6
Post-Test Cleanup
MarTech removes the Versions Block wrapper, retaining the winning layout and deleting losers.
MarTech
Winning variations are production ready for immediate rollout