Balancing Flexibility and Structure in Content Strategy Implementation

During the buildout of a new content management system (CMS), content creators often want page layouts to be as flexible as possible. This is also exactly the kind of request that keeps engineers up at night. An engineering team wants to build fixed templates for simplicity and maintainability; content admins want to be able to create pages that don’t perfectly fit the templates that were imagined at the start of the project. How do you define and implement your content strategy to strike this balance? A team I led recently had a chance to put this into practice.

First, some background

The project at hand was the migration of an existing site on an unwieldy CMS over to a new, more maintainable headless CMS with a new information architecture and visual design.

By the time this post picks up the thread, we’ve already worked alongside the client to define an initial set of content types, conduct a competitive analysis, review site analytics, conduct stakeholder interviews, set product goals and metrics for the new site, and build out a new information architecture.

I have one quick note on terminology before moving on. We used multiple words — pattern, component, block, module — that had slightly different implications for a particular thing’s role in the design system, the component library, our individual designs, and the code. In this post, I’m focusing on the individual composable elements that are visible to the CMS admin, and I will use “block” as a simplified catch-all. Even though I’m simplifying, these distinctions are still important! If you’re working on a similar project, I recommend taking some time to think about how the roles of each element differ and what terms you can use to name these differences.

You have to start somewhere

Ultimately, this is what all advice for building something new boils down to, right? You have to get past the blank page. On this project, we started at page types. Flexibility is the negative space around structure, and page types were our structure.

We decided a lot about structure when we worked with the client team to build the information architecture (IA). Having this IA fully defined early on was a necessary condition for success. With it, we knew that the site would have a homepage. We knew they needed blog articles. Our client was a service-based organization, so we knew that we needed ways to show individual services and lists of services.

Those were easy to point out and say “these are different page types,” but not every decision was that simple. Did every top-level page defined in the IA need a different page type? Should lists of articles be handled differently from lists of services, and did we need lists for anything else? Would each content type get its own unique page template?

We set our initial list down in a Page Type table which tracked the name of each page type, whether it had a fixed layout or a modular layout, and which pages from our IA would use that page type. (I’ve replaced service names below with placeholders from an imaginary party rentals company.)

At the same time, we knew that a rigid set of page types wouldn’t satisfy the need for flexibility, so we also needed to look at the level of composable blocks. Any successful CMS implementation will have a limited number of blocks that can be reused in multiple contexts.

We started a Blocks table to catalog unique blocks as we designed them for each page type, and to track where we were reusing them.

These tables let us track that (for example) the Home Page used the Carousel block, the Hero block, and Block Z; and that Block Z was used on the Home Page, the Service Page, and Page Type C. Notion made this easy to maintain by letting us build these tables in an actual database with a many-to-many relationship. This meant that when we listed three blocks as being used on Page C, each of those blocks’ entries in the Block Table automatically brought in Page C. This was much easier to maintain than a spreadsheet.

Building out the catalog

The combined catalog that we built for pages and blocks above became our bible as we worked through design and development.

We used it to track which page types had been wireframed, which then automatically tracked which blocks had been wireframed. When the client approved a given wireframe, that approval flowed through to all of the blocks on that wireframe. And because we reused blocks wherever we could, we moved much more quickly through the latter half of page wireframes.

In the meantime, our development team built out the site one approved wireframe at a time, implementing each of the individual components in the design as actual unstyled blocks in the CMS. By the time we were moving on to high-fidelity designs, the development team had already built out an unstyled frontend along with working APIs that populated that frontend with live data from Sanity, our CMS platform.

The catalog tracked all of these statuses: wireframes pending, wireframes complete, unstyled development complete, etc. Below is an example of what this looked like near the end of our design process:

This catalog grew to contain all of the unique content types that we defined at the beginning. One of the most significant page types for achieving our goal was the Block Page. On this project, a Block Page was a special page type with no hardcoded or templated elements aside from global site navigation. As long as a block didn’t rely on any special layout or hierarchical conditions, it could be used on the Block Page. This was our secret sauce for protecting flexibility while building structure.

Taking stock

As the end of our project timeline drew closer, we stepped through our pages and blocks catalog with the client to see what still needed to be built.

We had skipped a few potential page types in our buildout, including many of the top-level pages, because they didn’t represent unique ways of presenting information or modes of interaction. (As my teammate on this project Rayna wrote up in their own blog post: “Do not spend time defining every possible style you may need.”) We asked “Is there still something unique about these pages, or can we already build them with the blocks that we have?” and found that for most of these remaining pages, the answer was the latter.

With our content structure implemented, we asked “Is there still something unique about these pages, or can we already build them with the blocks and page types that we have?” and found that the answer was usually the latter. We found a few small gaps which we patched quickly.

Wrapping up

Getting from a content strategy to a set of composable blocks feels like a daunting task. You need structure in the data so that it can be maintainable for developers and admins. Those admins also need flexibility to handle situations that do not perfectly match the original designs. With solid content strategy foundations and careful tracking systems, we delivered a CMS which satisfied both of these conflicting priorities.