How much freedom is enough?

Some pages are easy to turn into a template.

A title goes here. An image goes there. The article body follows. Maybe there is a quote, a gallery or a related story at the bottom.

For Harper’s Bazaar Serbia and Grazia Serbia, premium pages were much less predictable. We were building a separate system specifically for those premium pages.

Before that, every premium page was built as a custom project. A designer might define the page first, then a developer would build it.

The idea was to stop treating every new premium page as a custom development project. Editors should be able to assemble a premium page themselves from a set of predefined building blocks.

We started without a finished design system or a component library to implement, only a goal and a rough idea of the kinds of pages we wanted to support.

What should those building blocks actually be?

Finding the building blocks

We started by looking for patterns.

We went through editorial sites, campaigns and promotional pages, collected screenshots and compared the compositions that kept appearing.

Text and image combinations came up constantly. Sometimes the image was dominant. Sometimes the text was. Sometimes they sat next to each other. Sometimes one overlapped the other. There were grids, carousels, image stacks and larger compositions built around background media.

Not every idea became a new component.

Some were too specific. Some did not justify a component of their own. Others looked different at first, but were better treated as variations of the same component.

A library with a separate component for every layout we found would have solved very little. We needed a more compact vocabulary that could cover enough real cases without turning every variation into its own component.

If two layouts were close enough to belong to the same component, what should the editor be allowed to change between them?

If a component could support several compositions, should those become explicit choices or stay fixed? And if editors could reorder everything on the page, how much flexibility could we expose inside each component without making the result unpredictable?

Over time, this became a library of reusable components rather than a collection of one-off page designs.

The harder part was not adding more of them. It was deciding how much of each component should be editable.

Keeping the page intact

Editors could combine components freely and change their order.

That meant each component had to work in many different contexts, not just in one intended sequence.

A text block might sit next to a large image on one page and between two dense visual sections on another. A carousel could follow a quiet section or another highly visual component.

The page could change a lot without the components knowing what would come before or after them.

So each one had to carry enough of its own layout logic to remain stable in different combinations.

That was one reason predefined compositions mattered. The component already knew how its internal parts related to each other. The editor could move the component around the page without having to redesign those relationships every time.

The page could change without every rule becoming editable. That was the kind of freedom we wanted.

What does the editor actually decide?

We used Prismic for the CMS, where these reusable components were built as Slices.

Once the page could be assembled from those components, we had to decide what should actually be editable.

A component could expose almost anything. That did not mean every possible setting was useful.

A text block, for example, could be narrow, regular or wide. It could use a small, normal or large text scale. Those choices described a result without asking the editor to think about grid columns, pixel values or breakpoints.

In the frontend, those options mapped to predefined layout and typography rules. The editor chose the intended result, while the component decided what that meant at different screen sizes.

A spacer could be small, medium or large, while the responsive spacing values stayed inside the component. A text and image block could offer a normal or reversed layout without exposing its column proportions.

A richer composition could combine background media, a foreground image and text. The editor could choose from a few supported arrangements and image sizes, while positioning, responsive behaviour, parallax and animation details stayed inside the component.

Once the system was in place, editors could assemble and publish premium pages themselves using the existing component library. New development was only needed when we wanted to add a new composition or capability.

Every option has a cost

CMS controls can look almost free. Add another value to a select. Add another toggle. Let the editor adjust one more property.

But every new option creates another state the system is expected to support.

A text block might offer three widths, three text scales and several positions. Each of those choices still has to work with different content lengths and on different screen sizes.

The same applies to structural choices.

A text and image component could expose arbitrary column proportions. Or it could offer a small number of compositions that were already designed to work.

The second gives the editor less freedom, but it also gives us far fewer combinations to support.

There were also things the system could not protect against.

It could constrain layout, but it could not make every piece of content suitable for every composition. A portrait image placed into a wide visual slot was still a portrait image. The component could define how that image behaved, but it could not guarantee that the editorial choice itself would look good.

Where should the choice live?

Not every useful choice belonged inside a component.

Theme was a good example. Instead of letting each component define its own basic colour treatment, we limited that choice to the page level. The editor could choose between a light and dark theme, and the components followed it.

That gave editors less control at the component level, but it kept the page visually consistent.

Animation raised a similar question.

Giving every component its own animation settings would offer much more control, but it would also create many more combinations and make it easy for different parts of the page to behave independently.

For animation, a page-level setting seemed like the better direction. A few defined treatments could apply across the page, while timing, movement and other implementation details stayed inside the components.

The editor would make a single, simple decision, which each component would then have to support properly.

With around thirty component types, each animation treatment would need to work across text blocks, image grids, carousels, overlapping compositions and the rest of the system.

The complexity was still there. The difference was who had to deal with it.

Choosing what to expose

Some decisions matter to the content. Should the text feel narrow or expansive? Should the image lead the composition or follow it? Should the whole page use a light or dark treatment?

Others are mostly consequences of those choices. How many grid columns should the text span? What should that width become on a smaller screen? What spacing keeps the composition balanced? How should an animation be timed?

Making all of those values editable would not necessarily make the system better. It would mostly move more of the work onto the editor.

A good content system does not maximise freedom. It puts freedom at the level where it is meaningful.