Freedom has a cost for the person using it
When designing a content editor, it is easy to treat another setting as another improvement. More layout choices, more colours, another way to arrange an image.
But every option also asks the editor to make a decision. If the purpose is to publish a useful article, choosing spacing and alignment for each section can become work that distracts from the writing.
The question I keep returning to is not how much freedom an editor can offer. It is which decisions the person publishing the page should need to make.
Reuse the meaning before the layout
Imagine an interview that includes a quotation, a photograph and a short introduction. The quotation has a job: let a person’s words stand out while keeping their attribution attached. The photograph needs a description and perhaps a caption.
These are meaningful pieces of content before they become arrangements on a screen. If they are treated only as boxes that can be moved anywhere, the editor may have to recreate their relationships on every page.
A reusable component can preserve those relationships. It can make the attribution part of the quotation rather than a convention somebody has to remember.
Boundaries can leave room for expression
A predictable component does not require every page to tell the same story. A quotation can appear at different moments. An image can support a technical explanation or a personal observation. The content and its sequence still give a page its character.
The more difficult boundary is deciding when an unusual page deserves a new pattern. Adding a setting for every exception gradually makes the common task harder to understand.
I would rather ask whether the exception has a reusable editorial purpose. If it does, a distinct component may be clearer. If it does not, a one-off design decision may be more honest than pretending it belongs in a universal block.
Ask who owns the next change
Reusability is also a maintenance promise. When a shared component changes, someone needs to consider the existing pages that use it.
That responsibility belongs in the design conversation. What should remain consistent across the site? What may vary from article to article? Which fields would an editor reasonably expect to keep working after a visual update?
My Wagtail case study looks at the technical side of reusable sections. The question here comes earlier: what kind of editing experience are those components meant to protect?
For me, a useful editor makes the important content decisions visible and handles the repetitive presentation decisions consistently. That is a more practical form of freedom than having to configure everything.