Designing for a CMS Website

I recently wrote this set of notes and guidelines to help our designers think in terms of how a CMS website works

Posted 28th October 2021

When we hand a website over to a client, we give them the ability to go and build new, unique pages after launch. This document outlines some good practices to bear in mind when designing for a website running on a CMS (Content Management System), or at least how we do it with Craft.

A website driven by a Craft is made up of templates (re-usable files where information from the CMS fills in the gaps). That might be, for example, a home page, blog listing, blog detail page, and a contact page.

Clients can add new pages to the site after launch. To give them flexibility & control over the content, layout and structure of those new pages, we give them a Matrix field that lets them add pre-designed & coded blocks to the page in any order.

Design for Re-usability

  • Think in terms of re-usable sections rather than designing a whole page at once
  • Content blocks should work when they're surrounded by other blocks, or used on their own.
  • Blocks should have consistent spacing inside and between each other. Consider what they'll look like if they're not used in the original order from the design.
  • Design high level re-usable content "types" instead of designing for specific copy (text, text + image, video etc).

If you can draw a line between blocks, it's a good indicator they can easily be re-used.

Design for the Client

Think about which options the client will have & don't make it too complicated. Every slightly different design of a block will have options in the CMS so the client can change it. Craft is very flexible, but it can be overwhelming when creating new content.

For example, a text block might have a heading, text and a button. If the design has that block with two different background colours, that'll be an option in the CMS, which might have a knock on effect to the colour of the text and buttons. If there's also an option for a background image, how does that interact with the option for a background colour?

  • Consider which parts of the block would be editable by the client. Some of it may be fixed every time, some might be editable

Design for Responsive

If the design file is 1920px wide, think about what will happen when the screen is wider - like a 27" desktop - or smaller like a tablet or mobile.

Think about how the content might change and how that would affect the design. For example:

  • If a text area is designed to look best at a specific height, what happens if a user adds more or less text?
  • What happens if your sentence is designed for 10 words but the client writes 50?
  • What happens if your blog listing assumes a three-word title for an article, but the real titles are really long?
  • What happens if some of the elements are missing? Do the other elements stay where they are, or close the gap?

In some cases, we limit the amount of text a client can enter, but it's best to assume things will have different lengths of copy.

Design File Checklist

Usually it's not necessary to do a mobile design unless there's something specific that needs to happen on mobile that isn't obvious from the desktop design. For example, the mobile navigation and footer are nearly always different to the desktop version.

  • Mobile designs should be ~350px wide to account for all devices. Doing a mobile design at 1000px wide means that font sizes will be incorrect when turned into code. It also helps to visualise what you can fit on a small screen.
  • Design files should be in in RGB format, not CMYK (this more relates to Photoshop and doesn't apply to XD)
  • Design files for web should have font sizes in px (pixels). Print files use pt (points); they're not interchangeable units
  • Send the list of brand colours to the developer
  • Create a "Style Guide" which includes Headings 1-4, buttons, form controls and body copy (see below)

If you're working with clients and developers, it would be useful to show your designs to the developer to make sure everything is possible, before showing anything to a client.


Making websites accessible is important for every country, but especially in the USA it's a law, not optional. Typically meeting the requirements of this law is done by using the WCAG 2.1 AA standards. A lot of that is related to development work, or content - but some of them also apply to designers. Particularly worth paying attention to are:

  • Check contrast ratios are at least 4.5:1 with WebAIM
  • Don't rely on colour alone to convey information (1.4.1)
  • Don't use images of text (1.4.5)
  • Clearly label form fields
  • Content that moves automatically like carousels need a pause button (2.2.2)

Create a global style guide

The client will be able to add all of the following HTML elements to a site through the CMS. Creating a global style guide first will not only help the developer know which HTML tags to use when coding the design, but also helps to create a cohesive design style across the site, and makes sure that none of the common HTML elements are missing when the client tries to add them later. Those elements are:

Heading 1 (Page titles)

Heading 2

Heading 3

Heading 4

Paragraph text with bold, underlined, italics, and inline links.

  • Unordered list items
  1. Numbered list items

"Blockquotes. This might be quite long, and would usually have an author or citation underneath it in some form too"
- Author Name, Company


Oh, and forms!