Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Designing for Content Management Systems

Designing and indeed front-end development for a website that will have content edited by non-technical users poses some problems over and above those you will encounter when developing a site where you have full control over the output mark-up. However, most clients these days want to be able to manage their own content, so most designers will find that some, if not all, of their designs end up as templates in some kind of CMS.

By considering the CMS as you design, you can maintain far more control over the final output. If your designs will be implemented and integrated into the CMS by a developer, then taking control at the design phase will help you to keep control over the design as opposed to leaving decisions to the developer or the content editors.

Know your enemy Link

Content Management Systems vary greatly in how much control they give the designer and the content editors. As a designer, you should first find out how much control over the templating system of your chosen CMS you have. Control may vary from simply being able to edit the existing templates to being able to shape the CMS completely around your designs. In some older CMS products you may find that you have little control over the mark-up that is inserted into the pages.

Where the content editors are concerned you should find out:

  • Will the editors be able to insert any HTML tags into content areas, either by way of a WYSIWYG editor or directly?
  • Is content simply large blocks of marked up content inserted by the editor or does the CMS use any kind of structured content?

Editing a Page in WordPress1
Many people use WordPress2 as a CMS. In WordPress, users can add any mark-up to the Page content area

If users of the CMS will be able to insert their own HTML, then you need to consider how your design will hold up when that happens. The ideal situation for a designer is where the user has limited ability to enter their own mark-up and the CMS uses blocks of structured content to guide them into adding content in the right way that can then be marked up correctly by the templates. The more freedom a user has, the more defensively you need to design.

Keep it consistent Link

However flexible your CMS is, it is important to consider the consistency in your design templates. Training content editors is far easier if the elements that they have to work with are consistent across all pages of the site.

If working with any kind of structured content in your design (for example an article listing that displays a list of titles and excerpts from articles on the website), think of each section as a repeating block. With CSS3 we can more easily target every other item, or the last item, but this is not available for older browsers and it may not be possible to edit the back-end code of the CMS to add a class to every other item or the last item. Ensure that the design will hold up if each repeating block is the same — you can always add extra finesse for those browsers that do support CSS3.

When dealing with areas that are essentially large blocks of content where the user has control over the mark-up, don’t assume the user will remember to add lots of different classes to the mark-up to trigger the CSS effects you envisaged. Either keep things simple or use CSS3 selectors3 to target areas of the design.

Do not assume content length or height of blocks Link

On the web it is never a good idea to assume you know how tall something will be — as even where you have control of the content, text resizing can blow your assumed heights right out of the water and cause overlaps or text running off background images.

When designing for a CMS, you have the additional issue of more or less text being added to an area that you envisaged. If creating the initial designs in Photoshop or similar, consider how each box and the surrounding content will react to a greater or lesser amount of content. If providing PSD files to someone else to build, ensure that any background images on these boxes are provided with instructions on what happens if the box is taller. For example do we show more background or matt onto a flat color?

Grid type layouts of boxes can be a particular problem in this situation. A common design might have several boxes with header areas. They look lovely and neat in the PSD comp with regular lengths of lorem ipsum. However, once the content editors have added content, we find that some headings are on one line, some on two and the boxes are wildly differing heights leaving the neat grid looking rather messy. Considering this at the design phase may have dictated a different layout here.

Dubbed Creative homepage4
The lists on the homepage of the Dubbed Creative5 website do not depend on height of content: some points have more text than others. This type of layout looks tidier than attempting to create equal height boxes with non-equal lengths of content.

If you are handing over to a front-end developer, thinking through these scenarios keeps the control on your side. Decide how you want it to look and explain to the developer how it should react to text resizing, additional content and so on and you don’t run the risk of leaving these decisions to people without an eye for design.

Avoid using image replacement for text Link

It is possible to generate images on the server side using PHP and other languages, however your CMS is unlikely to offer this capability as a standard feature. Therefore you should consider how any non-standard fonts will be included in your designs if that text needs to be managed by the CMS.

The situation with fonts is becoming far easier as there are now a number of services that allow you to use fonts that are not installed on your user’s computer but that would otherwise be difficult or impossible to license to include on your website. If you need a specific font you may be lucky and find that one of the below services have it available, or they may have something available which is close enough to get the visual effect you want.

The Fontdeck website6
Services such as Fontdeck7 and Typekit8 mean that using images for text is not neccessary to use a specific font.

Consider the CMS when designing navigation Link

The CMS that you are using is likely to dictate the navigation to some extent, so find out by checking the documentation or speaking with the developers what will be possible. It is useful to know what control content editors have over navigation. If they can add elements to the main navigation for example, it may be that you are best to avoid a neat row of tabs at the top of the site as additional tabs added by users may wrap.

Tabs on the Long Hollow website14
An attractive row of tabs such as these on the Long Hollow Church Website15 may look untidy if editors have access to add new top level navigation elements.

Questions you should get answers to include:

  • How many levels of navigation will be displayed? Is this configurable?
  • Can content editors add to or change the main top-level navigation?
  • Can you highlight the current page or section?
  • Does the CMS offer breadcrumb style navigation?
  • What mark-up will the CMS output for the navigation? Can we change it or add classes?

Design and create CSS rules for all possible HTML elements Link

In your design and dummy content you may only use two levels of heading and never add an ordered list or blockquote, However, if these elements can be added in the CMS, then at some point someone will use them. If you have used a CSS reset stylesheet16 you may not have styles defined for these elements at all — which will mean they look rather strange when used. Ensure that you have created CSS for all HTML elements in the content areas of your site.

I find it helpful to start my stylesheet with the default styling for all elements as this then acts as a fallback if I don’t add specific rules for styles later on in the document. I can always overwrite this CSS to make level 2 headings look different when they are in the main content area to when they are the heading of a sidebar box, but if I don’t add any specific CSS and then the user adds these elements, they do have some thought put into them.

Assume HTML elements can be stacked in any order Link

When creating your design, it is easy to assume that the content will look very much like your structured sample content. The h1 will be followed by a couple of paragraphs, never stacking headings and so on. The reality will be different once content editors get their hands on the design, so test the elements in different combinations.

Ask yourself questions such as:

  • Does the design still hold together well with stacked headings? Is there appropriate spacing between them?
  • What happens if a heading is used inside a list item?
  • What happens if different list types are nested? Is the spacing correct at the bottom of each list?
  • If the user can insert and align an image, what will then happen to the text around that image? Will there be a margin or will the text run right up against it? What happens if they put an image inside a list item?

Use CSS to enforce the style guide and semantics Link

This is something we tend to see once users become comfortable with their CMS: they begin to realize that, for example, an h1 heading gives them large bold text. You then start to find h1 headings in all kinds of strange places — wherever the user thinks something should be marked as very important. This can include half of the content of some pages. In the first instance we all need to try and educate our users and provide them with a style guide to help them understand the importance of semantics and correct usage of mark-up but the person you originally train will probably not be the person who manages the content forever and ultimately you will find users being creative with their mark-up.

A considered use of CSS can prevent this from happening. For example, we generally only want one h1 per page. If the main page heading is in a container, then you can use CSS selectors only to target that h1 with the main heading styling and reset the browser defaults on all other h1 headings to the same as the main body copy. This means the user has no benefit to using h1 in a non-semantic manner. The advanced selectors found in CSS3 can be very useful here.

CKEditor screenshot17
CMS Editors may want to get creative when given a “WYSIWYG” editor such as CKEditor18 – use CSS to protect your design as much as possible.

Test with real content Link

Once your design has been developed into (X)HTML and CSS, test your assumptions in terms of how the content will behave. I find it helpful to do this before the templates are incorporated into the CMS. Points to test:

  • Take each headline or small box in the design. Put in three times the amount of content you would expect it to have. How does it look? Does the box expand nicely or do you run off the background image or overlap another element?
  • Grab a chunk of HTML from anywhere — just View Source on some site and grab a bunch of content complete with HTML tags. Paste it into your main content area in the template. How does it look?
  • If using structured mark-up to display an event or similar — does the design hold up if certain items are removed or do you end up with obviously empty areas such as the word “Tel:” with no phone number after it if a phone number was not entered for a contact?

Help your content editors to maintain the design Link

If you hand over the CMS with little instruction for your users, then you can’t really expect them to read your mind and maintain the design as you would like. Even if your initial content editor is thoroughly trained on how to edit the site, as time passes by they may forget, or decide to get a little bit creative, or the initial editor may leave and someone else takes over with little training. At the end of the project, keep control over the design by helping your editor to do things the right way.

Remove functionality from the editor Link

The WYSIWYG editor in your CMS may by default give the user the ability to add all kinds of styling, even adding inline CSS. However, with many editors it is possible to trim down the toolbars to just offer a limited subset of icons and therefore functionality that is exposed to the user. If you can trim down the editor to only offer the ability to add basic HTML elements, you will have far fewer problems to deal with.

Add CSS to the WYSIWYG editor Link

If content editors have access to a WYSIWYG editor when editing content, add the CSS rules used on the site to the editor CSS. That way, editors can see how their changes to the content will actually look. In combination with using CSS to enforce the style guide, this can help users to maintain the consistency on the site.

Create a style guide that also includes semantics Link

Include a style guide for the site as part of your handover documentation. It is easy to just handover documentation on how the CMS functions and forget to also explain to content editors which elements they should be using when adding their content. This is particularly important if editors have a lot of control over the mark-up which they enter.

By considering how content will be edited on your site and the possible ways in which, over time, that content will grow and change, you can maintain far more control over a CMS website than you might think. If you have any additional tips or would like to discuss problems you have encountered when designing for Content Management Systems, leave a few lines in the comments below.

Further resources Link

Here are some additional resources that might help with your own CMS based projects:

(vf) (ik)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Rachel Andrew is a web developer, writer and speaker and one of the people behind the content management system, Perch. She is the author of a number of books including The Profitable Side Project Handbook. She writes about business and technology on her own site at

  1. 1

    Like it as well, but to be honest I do not see many differences to designing a normal webpage! Maybe because of my english knowledge and I just don’t get the point from this article! I am quite shure you did a great job!

  2. 2

    This is great. I really wish I read this a few years ago before I redesigned the North Shore-LIJ site (which has since undergone further redesign not under my watch). It was the first time I ever had to design for a CMS. Also the site had a ‘democratic’ approach to content creation. Essentially anyone could create content which meant lots of unforeseen situations.

    With that said, much of what I learned is encapsulated in this article.

    I would stress the fact that text will always grow longer and wider than you anticipate. That is the single greatest factor in designing for a CMS. Also, accounting for styling of all possible CSS and HTML elements is crucial. (Yes, people will add tables and charts!)

    Solid article.

  3. 3

    I feel the best and most consistent CMSs are the ones that break everything down into tables.

  4. 4

    Jann Mirchandani

    November 22, 2010 8:16 am

    Great article, as others have said.

    I think the thing that was my “aha” moment was when you said to force semantic use of CSS. That’s one thing I always struggle with after turning over projects to clients. Your suggestions were very helpful in that regard.


  5. 5

    utf-8 helps a LOT! … but not everything.

  6. 6

    I completely agree. I use MODx for exactly that reason, although I’ve heard a lot of good stuff about Expression Engine.

  7. 7

    Need graphical header generation with non-standard fonts and image manipulation? TYPO3 can do this out of the box, and best of all, it’s free and Open Source.

  8. 8

    A simple way to overcome user-styled content is by the proper use of the !important keyword in CSS. Simple, but powerful. Even better is of course to not to allow them to style content too much in the first place.

  9. 9

    You can say that again…. and again… and again.. like I have to repeat it daily to my clients when they say “help my site looks horrible, there is a ‘bug’ in the development”. Kill MS Word!

  10. 10

    Interesting article. I’ve had to deal with a lot of these issues. From my point of view, the hardest part is when writers and editors with no web experience start contributing to the sites. There are far more ways to screw up a web site than you can imagine until you’ve been through it a few times and seen it happen. Your point 10 is enormously important, but it’s perhaps not sufficient. You need to proactively strip out any mark-up other than a few basic tags.

    The real culprits are those who paste from Word. If you’re not stripping out all the horrid mark-up, then a site can go downhill fast.

  11. 11

    Nice article , thanks for sharing!
    I liked the “don’t assume height or width” of a certain element, i think it’s important keep that on mind also if you design for a multilanguage website, so navigation and other translatable elements’ dimensions can be really different based on the language they are in (check also right-to-left or left-to-right language direction).
    Another suggestion is to keep WYSIWYG functionality to the minimum (headings, underline , bold, anchor , list …… what else?) and properly design the content type from the theme/template layer.
    that’s my 2 cents, keep up the good work.

  12. 12

    The CMS I have been working on the for the last few years is very designer friendly, and I wanted to make sure that it was (being a designer myself). The templates, the CSS and the Javascript editor is really easy to use with full version control and it basically makes building sites a breeze. Also it has a website import that brings in all the HTML/CSS automatically. Would love your thoughts:

  13. 13

    I think one of the hardest things is to think of all of the combinations of element stacking that is possible. Think about the sheer amount of elements in HTML and how many of combinations they all represent. It can be daunting. I would be curious to know if anyone has a resource that might provide some of the most common ones? Or if anyone would be interested in such a thing?

  14. 14

    “The real culprits are those who paste from Word. If you’re not stripping out all the horrid mark-up, then a site can go downhill fast.” That is so important to remember. And something you don’t always realize until you get dollar signs and asterisks in place of quotes.

  15. 15

    Joel Sutherland

    November 22, 2010 7:48 am

    It’s also important to pick a content management system that doesn’t require that you design for it!!

    Don’t go with a CMS that generates code, go with one where you can control all of the markup. This will allow you to design freely and know that you’ll be able to put it on the CMS. The only two CMSs that my company will use are Expression Engine ( and HiFi ( for this very reason.

    We also make sure that we also set up a stylesheet that can handle ANY of the elements our clients throw at a WYSIWYG editor. This ensures that the site will look good even after we hand it over. This is the baseline stylesheet we use:

  16. 16

    Sergiu Dragomir

    November 22, 2010 8:03 am

    Very interesting article. I work as a web designer, and i do layouts mostly. I’ll have to say i thought i had everything covered up when dealing with CMS layouts but you touched some very interesting points that i actually wrote down.
    Thank you :)

  17. 17


    I perfectly agree, a CMS should not stand in the way of any design(er), nor should it force you to adapt the customer’s demands to the capability of the tool (a process called consulting sometimes ). To make things worse demands are not static but tempt to be varying with time.

    This is why we developed ( a model driven CMS platform (or a system to build systems as one of our solution partners calls it) in the way we did it. And so far, the flexible approach kept its promises. I invite you, to add it to your list of useful CMS products ;-)

    Regards from Dortmund, Germany

  18. 18

    Thanks Rachel. I think it’s also important to consider localization during UI design and CMS development. Here is a case scenario: we open a store in France, business growing well, we need to open a store in Russia. Difference in language can make it difficult to go through CMS redesign. If you have enriched menu structure it may take some effort and cost.

  19. 19

    I don’t comment here often, but just wanted to say genuinely useful and interesting article, I have had many problems with these sort of issues.

  20. 20

    Good article, with some sound point.
    In the corporate world of CMS, I find that the majority of problems with CMS design and implementation come down to browser version (many clients, especially public sector still use IE6), users having too much control of content formatting (so don’t give it to them!), and finally as mentioned above – the dredded pasting of MS Word html!


↑ Back to top