Content modelling in Optimizely: Why your initial delivery decisions matter more than you think

As a Strategic Global Partner agency working with Optimizely, we're often under pressure to deliver quickly and efficiently for our clients. Stakeholders want to see results, content editors want their CMS yesterday, and the backlog isn't getting any shorter. In this rush, it's tempting to take shortcuts when defining your content model. After all, "we can always refactor later" or "revisit this in Phase 2", right?

Having worked extensively in QA and Product engineering, primarily within the Optimizely ecosystem, I've seen first-hand how quick and easy architectural decisions made in the early sprints can either set a project up for long-term success or create technical debt that compounds with every feature release. Let's explore why investing time in proper content modelling upfront isn't just best practice, it's essential for project success.

The foundation: Why content modelling deserves your sprint zero

What is "content modelling" anyway?

Content modelling is the architectural blueprint of your digital experience platform. In Optimizely, your content model defines not just what data you store, but how that data relates, composes, and ultimately renders across channels. I've observed countless projects where content types are created ad-hoc, with developers treating them as simple data containers to vaguely match the Figma screens rather than the structural foundation they truly are.

A proper content model should define:

• Clear content type hierarchies and inheritance patterns
• Block composition strategies for reusable components
• Property definitions with appropriate data types and validation
• Relationships between content types (parent-child, references, composition)
• Metadata and categorisation schemes
• Localisation and versioning strategies

When you rush this phase, you're not just creating a few extra fields to remove later, you're establishing troublesome patterns that will ripple through your entire implementation. Your content model directly impacts your IA (Information Architecture), your rendering logic, your testing surface area, your content effort, and ultimately, your ability to scale and maintain the platform.

The cascade effect: How early modelling mistakes compound

Let's paint a scenario that might feel familiar. Your team needs to build a promotional banner that can appear on multiple page types. Under time pressure, you take what seems like the pragmatic approach: you create a PromoBannerBlock that contains all the promotional content: headline, body text, CTA, image, and background colour.

Seems reasonable, right? It works, it matches the designs, content editors can use it, and you ship it.

Fast forward six months. Marketing now wants:

• A/B test variations of promotional banners
• Different banner styles for different campaigns
• Conditional display rules based on user segments
• Analytics tracking with unique identifiers per banner instance
• Banner scheduling independent of page publishing
• Multi-variant testing with Optimizely's experimentation features

Suddenly, your "simple" block has become a liability. Because you modelled it as a monolithic content block rather than a compositional structure, you're facing technical debt; testing complexity; migration headaches; and, most importantly, editor confusion.

The root cause? The initial modelling decision didn't account for composition, extensibility, or separation of concerns. What looked like the "right choice at the time" was optimising for immediate delivery at the expense of long-term architecture.

How Optimizely enables structured, scalable content models

Here's where Optimizely shines, if you leverage the capabilities correctly. The platform provides robust primitives for building highly structured, composable content models that can adapt to changing requirements.

Block-Based architecture

Optimizely's block architecture encourages composition over inheritance. Instead of creating monolithic content types, you build discrete, reusable blocks that can be composed into larger structures. In the below example, instead of embedding all CTA properties directly in your Hero block, you create separate, reusable blocks:

HeroBlock contains:

• Heading (text)
• Subheading (rich text)
• Call to Action (reference to CTABlock)

CTABlock contains:

• Link Text (text)
• Link URL (url)
• Style (dropdown selection)

This compositional approach means your Hero component references a CTA, rather than embedding it. When CTA requirements change (and trust me, they always do), you modify the CTABlock definition, and all components using the CTA property inherit that change.

Content areas as composition engines

Content Areas in Optimizely are often underutilised. They're not just placeholders for blocks; they're powerful composition engines that enable editors to build sophisticated layouts without developer intervention:

Example: Constraining a Landing Page content area

• LandingPage content type with a Main Content Area
• AllowedTypes restricts to: HeroBlock, FeatureGridBlock, TestimonialBlock only
• Editors can compose sophisticated layouts using only approved, tested components
• Maintains design system integrity while providing creative flexibility
• Changes to allowed block types propagate automatically across all landing pages

By constraining allowed types, you maintain IA integrity while giving editors flexibility. This is content modelling meeting UX, you're encoding your site's design system directly into the CMS.

The Visual Builder revolution: Shifting the content modelling paradigm

The introduction of Visual Builder to the Optimizely portfolio represents a fundamental shift in how we think about content modelling and developer-to-editor workflows. For those of us who've been in the Optimizely ecosystem for years, Visual Builder feels both familiar and revolutionary.

What Visual Builder changes

Visual Builder brings true WYSIWYG editing to Optimizely, but the implications go deeper than just UI improvements. It fundamentally changes the contract between your content model and your presentation layer.

Traditional Optimizely workflow:

1. Developer defines content types
2. Developer builds rendering components (controllers, views, view models)
3. Editor creates content instances
4. Editor previews, hoping it looks right
5. Cycle repeats when it doesn't look right, leading to costly feedback cycles

Visual Builder workflow:

1. Developer defines content types with semantic, presentation-agnostic properties
2. Developer creates frontend presentational components following Visual Builder conventions
3. Editor creates AND designs in real-time with live preview
4. Editor adjusts styling, spacing, and layout without dev intervention
5. Changes deploy immediately

Content modelling for Visual Builder

This workflow shift has profound implications for how you structure your content models. With Visual Builder, your content types need to be even more focused on semantic meaning rather than presentation:

Avoid presentation-specific properties on your element:

• ❌ BackgroundColor - styling concern
• ❌ PaddingTop - layout concern
• ❌ ShowShadow - visual effect concern

Instead, model using content-focused properties in the Element AND semantic visual properties in the Styles:

• Element Content Properties:
• ✓ Title - what the card is about
• ✓ Description - the card's message
• ✓ Image - supporting visual content
• Element Styles:
• ✓ Variant - semantic style variant (e.g., "featured", "standard")
• ✓ Emphasis - content importance level (e.g., "high", "normal")

With Visual Builder, presentation concerns (spacing, colours, shadows) are handled in the design layer, not the content model. Your content types should describe WHAT the content is, while Visual Builder handles HOW it looks.

Practical recommendations for your next Optimizely project

Based on everything we've covered, here are concrete recommendations for content modelling success:

Before you write a single content type:

1. Map your domain: What are the actual entities in your business domain? Not pages and blocks—products, articles, events, people. Model those.
2. Define your composition strategy: Which content structures should be reusable blocks? Which should be page types? What's the hierarchy?
3. Establish naming conventions: Content types, properties, categories—everything should follow a clear naming scheme. This pays dividends for maintainability and testing.
4. Plan for localisation: Even if you're not multi-language now, model as if you will be. It's much harder to retrofit.
5. Consider Visual Builder from day one: Are your content types semantically focused? Does this design prototype work for a molecular page build? Will they make sense to editors in a visual editing context?

What does all this mean for my organisation?

Content modelling in Optimizely isn't just about creating blocks that match the Figma. It's about architecting your entire digital experience platform with foresight, understanding how today's decisions impact tomorrow's capabilities.

The introduction of Visual Builder and Optimizely Opal doesn't make content modelling less important, quite the opposite, it makes it more critical. These tools amplify both good and bad architectural decisions. A well-structured content model enables Visual Builder to shine and helps Opal generate meaningful, on-brand content. A poorly structured model creates friction at every turn.

For those of us working in quality or product engineering, content modelling is where we can have the most impact. By advocating for strong architectural foundations, comprehensive validation, and testable structures, we set our projects up for long-term success. The extra time spent in sprint zero pays for itself many times over in reduced technical debt, easier testing, and faster feature delivery down the line.

So, the next time you're pressured to "just get something working" or "just build the Figma", remember in the world of content modelling, fast is slow, and slow is fast. Invest the time upfront. Your future self (and your Content teams) will thank you.

Struggling to build a best-in-class website with a second-to-none editor experience? Discover how we can help transform your digital real estate to be future focused.↗