Virtually all websites and apps for organizations will be built upon a CMS (Content Management System), CDS (Content Delivery System) or other platform that allows you to easily manage your content. If you’re designing or building a new site, you’ll most likely need to select one as your platform. Typically, you select your platform very early in the project before design work, perhaps before it even starts. We say: hold your horses!
I’ll get one thing clear straight away: I’m not going to recommend you one here. We have our preferences*, and others have theirs, but that’s not the focus on this article. The simple fact is: there’s no such thing as the perfect CMS. Each has their pros and cons. No developer or agency can be fluent in all CMS systems, so has to specialise, so therefore will have their favourites, and will build a compelling case on why you should pick theirs. What they recommend probably makes good sense, though they will be partisan.
Asking ‘what CMS’ by itself ignores the real question, which is ‘what CMS will best serve our design and content needs?’ For this, you obviously need to be clear what those needs are. Get these covered first, then pick your CMS, not the other way around.
So the focus of this article is not ‘which CMS’ but instead a short guide for clients or project managers on how to approach the design for a site that will use a CMS. Once you’ve done this, your choice of platform will be far more informed, and therefore better.
When clients come to us with issues on their site and the underlying CMS, often it’s not the CMS system itself that is the problem, but the way it’s been configured and the way the architecture and design has been implemented. This often is restrictive, or clunky, or built in a way that making even minor design changes seem like an expedition to the North Pole and back. The CMS is a platform, a foundation after all. There’s plenty of scope to screw it up.
At the route of many of these problems is the ‘template’. Most CMS sites use design templates – full-page layouts employed to build up the site pages. This is wrong. If you are planning to build a site using templates, you should stop now and rethink.
Here’s why:
1. TEMPLATES ARE INFLEXIBLE AND BORING
Templates are the ‘traditional’ approach to CMS site design. The template-driven approach to CMS design leads to a narrow range of rigid templates that give a dull, samey user experience. This approach is out of date for our multi-device, multi-viewport age.
2. TEMPLATES SEPARATE DESIGN FROM CONTENT
Despite best intentions, design and content production are often siloed resulting in the shoehorning of one into the other when they meet (too) late in the project. Templates just exacerbate this problem, with huge chunks of your site designed before you’ve even start creating content. So you end up ‘shovel it in the template’ approach to content. This is not good.
3. TEMPLATES OVER SIMPLIFY THE DESIGN AND CONTENT EFFORT REQUIRED TO CREATE A GOOD SITE
The reality is that creating a good, engaging website is a complex task, and designers and content producers need to work closely together to do this well – with critical input from subject matter experts, business owners and users themselves. Content and design is a page-by-page process (or user journey by journey) and will take shape over several iterations.
The problem with templates is that they hide this challenge, masking it as ‘here’s the space, now write something to fill it – and while you’re at it, pick up a stock photo for the banner’. OK I’m being a little facetious here, but the point is that content design is often the most under-estimated part of a website project. It takes time.
4. UPDATING TEMPLATES REQUIRES SITE-WIDE UPDATES = COSTLY & TIMELY
Sometimes we’re told ‘we can’t update the template as it affects the whole site and is going to take ages & cost a fortune’. (This always especially seems to be the case when an overseas or distant head office team manages the website). This means your site will never change – or will do so at a snail’s pace. Or you end up spewing separate microsites as a way of compensating for this inflexibility. This is crazy and no way to run your site. A base requirement is to be able to adapt and add to your site expediently, so you can keep your site fresh.
So what to do instead? Here’s the approach we take, and one we recommend to clients.
1. STRATEGY FIRST.
Before you go anywhere near design, make sure you’ve covered the basics. This is often called a ‘discovery’ or ‘requirements’ stage. How you do this is not the focus of this article, but don’t go anywhere near design until it’s nailed down. Be very clear about the problems you are looking to solve and the stories you want to tell. We call this ‘strategy first’, and won’t do anything until we’ve got consensus on this.
2. DITCH THE PAGE TEMPLATE AND GO MODULAR
Modules, or slices, or strips, or bands – many names to describe the same thing – are sections of content that you compile into CMS pages. Rather than design a page template, you design a number of modules that you use to assemble a finished page.
This approach gives you far more flexibility: you can build up your content narrative from a selection of content blocks. You can rearrange them as you need (whilst following some common sense structures and rules). You can omit modules that aren’t relevant in some instances, or add in extras. You can design and build new modules and slot them in with minimal knock-on effect.
And it’s pragmatic from a CMS point of view. You don’t need to create loads of layouts that are just variants of one another. Modules have an independence that enables easier evolution and development.
3. THINK ABOUT YOUR NARRATIVE FLOW
Modules allow you to stop thinking about rigid layouts and instead start considering the content itself on a macro and a micro level. This is the important stuff.
On a macro level, we consider narrative flow of each page (and sequence of pages / steps), and assemble the modules to tell this story in the most effective way. Taking this holistic view is important, as without it you won’t get any real flow and there’s a danger of ending up with a stacks of content that lacks overall cohesion.
On a micro level, templates give you a lot more control over the detail. And when you build a site there is a LOT of detail. We have a neat little checklist that we use to make sure we’ve not overlooked anything. You can download it
here
. If you consider all these things during the project design, you’re probably going to be fine.
4. GO VISUAL EARLY
You can create spreadsheets and write big documents about your modules, but we haven’t done this for a long time as no one reads them or (if they do) no one really understands what they mean. It’s far better to get visual as early as possible through prototyping then designing. This allows you to test different options, different ways of assembling the modules, test them with real content, and create clickable tests that give you an understanding of the emerging user journeys. They also enable you to explain it better to your stakeholders (no small consideration).
AND BACK TO THE CMS SYSTEM ITSELF
Our CMS design process iterates through modules from low- to full-fidelity design in a series of sprints. Throughout this process, we keep the devs closely in touch with progress. They hugely appreciate that, and have much valuable input that others won’t consider. But it’s only once clarity emerges around your structure, modules, and design when you should (re-)evaluate the CMS options / check that your preferred CMS can deliver.
Ask this key question of your platform: ‘how’s the editing experience going to work?’ This can determine whether the site lives or dies. We’ve seen modular sites that have lots of flexibility in theory, but in reality have a super-complicated editing experience that defeats most site editors and chokes the publishing process. This is frustrating, and is a fast route to dissatisfaction with the CMS and the agency/web team.
We’d advise taking time to make sure that everyone is clear on how you assemble the pages and how the editor is actually going to work. This may take a bit of extra time and may require some prototyping – so assign a little extra budget on this – but, as with anything, you reap what you sow.
And it’s only at this point, once you are clear on your design and content structure, and how you are going to publish, that you should commit to your CMS. And it’s only at this point that you can really estimate the development effort with accuracy.
(*email me if you want to know what they are)
