Key Points
- Set up your systems so that you can optimize all pages of a particular type, including those already published
- Avoid the total flexibility or locked-down control flip-flop — get just enough flexibility to allow broad optimization
- Architecting for broad optimization over time is most important for sites with large swaths of similar content
We need to innovate and optimize over time. And creating one-offs won't do that. Also, we aren't solely talking about making completely global changes (like the header or footer). We need to make changes broadly, but only for a specific type of page. For instance, if you have a hundred case studies, you may discover that a different presentation works better (perhaps you publish all the hundred case studies with the client name first and then the key outcomes — you should be able to switch those across all pages you have already published without making manual changes to each case study).
A successful implementation of this use case both increases consistency, limits fragmenting one-offs, and allows innovation and optimization.
Steps
Create template for a logical type of page (for instance, a product page with pricing at the top, an image next, and the description last)
Publish pages using that template (for instance, three specific product pages: widget, thingy, and doohickey)
Product team requests a change that impacts all pages of that type that is not simply a CSS styling change (for instance, switching the placement of the pricing and image)
Technical team can rapidly make the change.
The change ripples through all affected pages / renderings (an not other pages) without manual intervention on each page (so the widget, thingy, and doohickey product pages each now have the image first and the pricing, with no one needing to make any manual changes).
In describing this use case, we can get tripped up on terminology. Different CMSes use different terms, as does each team. To simplifiy the discussion for this article (and to avoid spending the whole time defining terms), I'm going to use the term "page" a lot. Of course we're all sophisticated and want content to flow around, be structured, get rendered in different contexts, etc. But to clearly describe the problem in a generic way I will rely on the term "page." When actually defining this use case for your organization, you need to tailor the language for your usage.
Things to watch out for
Step 5 is the one to pay the most attention to. In general you want to make sure to test that this type of change is possible. This is a bit counter-intuitive since for example if you are redesigning you are focused on what the pages look like at launch — but you need to confirm that you could make template changes (which you may want to do shortly after launch).
Mitigating factors
Obviously this is more important the larger a site gets, or, more precisely, the more pages of the same type and the frequency of optimization. Small sites probably do not need to worry about this one quite as much.
If your system isn't already architected and implemented to make this sort of change, it may only make sense to attempt implementing this use case during major redesigns. This is a time when you will probably be mucking with the content broadly anyway, and also be making the deep structural changes that may be needed.
Flexibility vs. control
Teams usually flip flop between excessive flexibility and control. This is partially because it is easy to open the floodgates (for instance to allow any HTML to be entered into a page), resulting in crazy variance across the site, and then to lock down the site in response. This actually pushes toward opening the floodgates again since it's easy to do so. CMS vendors frequently jump on this tension, and offer content publishers to layout pages etc. But this means that optimization isn't possible. So we are shooting for a middle ground between flexibility in control to allow that optimization.