Modularity has emerged as a major theme in digital design. 

• Modular content supports the reuse of content in different contexts. 
• Modular design supports the reuse of design components across applications and platforms.

Both help digital teams build new experiences by providing a kit of parts. A content model and design system provide building blocks to create new experiences. 

But if teams are missing critical building parts or find they don’t fit together right, they’ll miss out on the benefits of modularity in UX.   

While similar in their motivations, modular content and modular design have developed separately. Both approaches emphasize defining structures that can be used repeatedly, improving the efficiency of content and design activities. Yet the full potential of these approaches goes beyond optimizing existing content and design work. When developed in tandem, they offer a platform to extend what teams can address, allowing them to deal with novel requirements. 

Previously, we looked at why digital teams should decouple their content and design and stop designing content for specific screens. And we stressed the importance of coordinating their content models and design systems to support user experiences. In this post, we’ll look at how teams can upgrade their use of modularity in their next project.

Strengthen your governance and capabilities. When organizations transition to decoupling content from design, they may find weaknesses in their content and design maturity.

• They’ve been doing lots of projects in an ad hoc manner, with little governance over how the content or design is structured. 
• Their current content model and design system have grown piecemeal and are not sufficiently robust to handle future needs.

They need a stronger foundation. Implementing a headless CMS, which decouples the content from the design by default, can serve as a catalyst to improving these dimensions.

A new project can highlight gaps in current capabilities. Before throwing themselves into the details of a major new project, digital teams should do four things:

1. Define what’s novel in the project
2. Assess what frameworks are already available
3. Determine the readiness of your existing systems
4. Strengthen your weaknesses

Step 1: Define what’s novel

The first step is knowing how much your team will need to change how they have done their work previously.

Look at what you are aiming to deliver and ask how much it will be different from projects you’ve done in the past. Some questions to consider:

• Will existing UI components be sufficient? 
• Can the current content structure handle the messages and interactions envisioned?
• How much will the new project depart from your existing patterns? 
• What new elements might you need?

Here are some examples of new content and design elements that might be required:

Examples of new content elements	Examples of new design elements
New content types covering new topics or tasks New text fields for existing content types to add or break out details Additional metadata for accessibility, search, or social media platforms Enhancements to rich media elements such as transcriptions or annotations Representing information in new ways, such as with graphics or audio	Modules to support a new task Components or widgets to support new functionality Representing newly introduced states or statuses relating to the content or user

Novelty isn’t always radically new, though it sometimes is.  Novelty can appear when a new project extends either:

• The scope of what’s been done, such as addressing new subject domains or channels
• The detail or granularity of what’s being presented, such as when previously unstructured templated content is given more detailed structure 

Your project’s goals will reveal what’s novel.  Determine how different the new project will be from past projects.  Will the project be:

• A completely new greenfield project?
• A redesign or refactoring of an existing application?
• An extension in the breadth or depth of the content or functional coverage?
• A new direction, such as serving a different channel with alternative modes of interaction?

Any time your project introduces novelty compared to what you’ve done previously, it suggests you’ll need to add more structure to your content model and/or design system. 

An example: the project introduces multilingual versions of an app that was previously available only in one language. The content model would need to accommodate different versions of the content, while certain design components may need tweaking to present other languages properly, such as the sizing of elements such as buttons and inputs, text within images, the formatting of dates, numbers, and currency, or the layout—especially if adding right-to-left languages.

Another example: if the project introduces augmented reality (AR), the team will need to develop frameworks to provide and present information for that channel.

Step 2: Assess the frameworks you have already

Assess the completeness of the foundation that’s in place. Review your existing content model and your design system. Can they address the kinds of content you need to present and the channels you are serving?

Test the maturity of your content model and design system by seeing how well it can handle new requirements.  Think about the different scenarios and whether your systems can support them. 

How detailed is your content model? Your existing content model might not have been built for more structured content. Immature content models suffer from two common problems:

1. They are vague and loosely structured, failing to organize information around topics or tasks and instead provide a limited range of generic content containers.
2. They are overly specified because they reflect the text presented on existing screens rather than structuring information according to its meaning and purpose (it’s a de facto content model arising as the byproduct of screen design).

Another limitation is that existing content models are often web-specific. Mobile apps, chatbots, email, and other non-web channels often don’t use this content model at all. If you want to unify your content model to support multichannel content delivery, you will need to include topics and tasks that may not be part of your web channel. Doing so will improve the governance you have over your content.

Decide how much granularity your content model needs. You’ll want enough granularity to support publishing flexibility but not so much that it creates complexity without delivering value. Decide on content types according to how content teams need to manage the information and the high-level user tasks associated with the content. Break out (de-clump) content elements within types by paying attention to how users access specific information in different scenarios. Content elements give designers control over what informational details to present. Think about:

• Details users will need to see more than once at different stages
• Details that you’ll want to show or hide depending on the context
• Headings, labels, or descriptions that could vary across platforms or channels

How detailed is your design system? Your design system may cover the basics but not more complex patterns. Immature design systems are limited by several issues:

• They are focused on aesthetic guidance but don’t cover interaction patterns in much detail. 
• They have been copied from other organizations and only cosmetically modified instead of being tailored to support the concrete needs of the organization’s customers. 
• They are too generic and not focused on supporting specific user tasks.
• They don’t govern recurring UI patterns, such as onboarding new users or resolving user problems.

Upgrade your design system. A mature design system indicates much more than how to style boxes and buttons. If you are looking to address new channels, you may need to extend your design system to cover them. The goal should be to develop design modules that support critical tasks, presenting a range of content users will interact with when using various channels. 

The maturity will influence how much foundational work is needed. The less mature your content model or design system, the more effort you’ll need to put in.

Cross-check the robustness of your content and design frameworks. Verify that the content model and design system can handle the needs of the new project. Even if the project doesn’t seem to introduce much new functionality, work through user scenarios to make sure that the right content and design features will be available. This is especially important when user interaction is envisioned: Will they have the relevant information and be able to work with it? Think about the key customer metrics driving the project and what content and interaction support is needed. What problems might customers encounter that need to be accommodated?

The table below will provide your team with a rough guide to your current maturity and the gap you need to close:

Maturity level	Status of enterprise content or design framework	Goal and steps required to get to maturity
Absent	The framework doesn’t exist Prior projects were not governed by a defined enterprise content model or design system	Goal:  a new comprehensive framework Build a comprehensive foundation from scratch Verify that the comprehensive framework can handle all anticipated interaction requirements
Limited	The framework is inadequate for current needs Gaps in coverage exist, or current implementation goes against best practices	Goal: an improved and extended framework Remediate existing framework to fix the technical debt and fill in missing foundations Extend existing framework Verify that the revised, extended framework can handle all anticipated interaction requirements
Emergent	The framework is adequate for previous needs but not sufficient for future needs The new project will introduce novelty	Goal: a more comprehensive framework Extend existing framework Verify that the extended framework can handle all anticipated interaction requirements
Comprehensive	The framework can handle projected future needs The framework can accommodate projected information, tasks, channels, and functionality	Goal: the existing framework is stress-tested for future-readiness Verify that the existing framework will be able to handle all anticipated interaction requirements

Step 3: Determine the readiness of your framework

Know your weaknesses before they bite you later. After reviewing the maturity of your content model and design system, the team needs to figure out if both are ready for the new project. You can’t build an adaptive solution until your foundation is in place. 

For large complex projects, digital teams should hold off on the detailed design and content creation work until they’ve prepared both the content model and design system foundations.

Are you prepared? Evaluate your robustness of each to determine how prepared the team will be to move into detailed design. Pay close attention to content and design patterns that will be needed repeatedly. Once the detailed design is underway, teams must know where the information will come from in the content model and how it will be presented according to the design system. Any significant gaps or unknowns are signs that the foundational systems need enhancement. 

Readiness will depend on having specified all the essentials:

• Content elements (defined within the content model)
• Design elements (components in the design system)

Since your content model and design system may have been independently managed and not coordinated previously, one or both is likely not fully ready for future projects. 

Content structure readiness	Design system readiness	Readiness to build a solution
Are all essential content types and elements in place within the content model?	Are all needed design components available so they can be mapped to content elements?	Can teams connect required content elements with design elements?
Yes	Yes	What's ready: Content structure Design structure
Yes	No	What's ready: Content structure What's not yet ready: Design structure
No	Yes	What's ready: Design structure What's not yet ready: Content structure
No	No	What's not yet ready: Content structure Design structure

A greenfield project covering an entirely new content domain or design for a new platform will generally require extensive prep work. 

Step 4: Strengthen your weaknesses

Ideally, your current content model and design system can handle routine projects like those you’ve done before.  But they may not be future-ready. Your framework will need more development if new projects introduce novel scenarios not covered by your current systems. 

When starting a significant new project, a top priority should be enhancing your content model and design system so they can address anticipated scenarios. Although detailed content and UI design may uncover some less obvious specific requirements, it’s best to plan how to address “global” content and design patterns as much as possible before starting detailed work. 

Build a foundation that will be extensible for future content and UI needs. Your team’s detailed design work will be more efficient and maintainable as a result.