Ryan Cramer


Web Site Design Longevity and CMSs

The architecture of dynamic content

The longevity of a web site design will depend on several factors, some of which may be out of the designer’s control. But the most important factors behind creating a long lasting design are within the designer’s influence, and should be accounted for. These factors are:

  • How well the designer has planned and executed the design specific to the client’s current and future needs.
  • How well the design holds together, both visually and conceptually, when populated with the diverse reality of dynamic content.
  • How few design or stylistic decisions the client has to make when adding/editing content.

This series of articles has provided some practical tips on the first two items, but the third item is one that designers usually disregard or consider outside their area of influence. If design longevity is important, the designer has to take an active role in this.

Clients’ Perspective

Clients are empowered by the control provided by CMSs and typically have a natural inclination to introduce style into the content they publish, whether by necessity or creative interest. When clients introduce their own style into such content, they do so without the training or knowledge necessary to maintain proper consistency with the overall branding and design system.

Over time, this leads to degradation of the design, and reflects poorly upon the designer and the client. But the client, who is not trained in design systems, is not likely to understand this, nor should they be expected to. This ultimately reduces the longevity of the design as the site begins to look outdated by lack of consistency. How do we solve this?

Keep the client focused on editing content, not styling it

The fewer stylistic decisions the client has to make, the better. If possible, ensure the CMS places technical limitations on the ability of the client to make stylistic decisions outside of those you have defined. Ideally, the CMS provides separate custom fields for specific pieces of content (like headline, subhead, body copy, date, summary, and so on), rather than large multi-purpose, blank-canvas fields. The more specific, the better.

As shown in the screenshot above, keeping the client focused on input goals through highly-specific content fields limits the need for stylistic consideration on their part. These specific content fields should map directly to XHTML markup so that all styling is handled from the stylesheet, not by the client. Ensure that you as the designer have properly accounted for all the client’s potential typographic needs in your design.

Structure–not style–in body copy

Some content fields naturally require the client to work with both text and structure. An example would be a body copy field. These fields may have a structure of paragraphs, secondary and tertiary headlines, bold and italic text, links, bulleted and ordered lists, etc. But there is a gray area between structure and style, and this is where the breakdown occurs. Keeping the client focused on structure is critical.

Considerations with rich text WYSIWYG editors

If the client is given tools to make arbitrary changes to the properties of text (font style, size, color, etc.) that creates a conflict of interest between structure and style. This is especially a problem with rich-text WYSIWYG editors in CMSs. Despite the impressive power afforded by such tools, if limitations aren’t placed upon their power, they can eat away at a site’s consistency like a disease.

If a WYSIWYG editing tool is provided to the client, ensure that options for making arbitrary typographic changes are disabled. Less is more with these tools. Disable any other features you haven’t specifically planned for in your design. In particular, giving the client the ability to make arbitrary changes to font face, size or color is asking for trouble. At the same time, take advantage of the tool by enabling those typographic features that map directly to the tags you’ve designed. Examples include headlines, bold and italic text, lists, etc.

Avoiding or limiting HTML/XHTML

Many clients may have a passing familiarity with certain HTML tags. They know just enough to be dangerous. If your CMS allows the client to enter HTML into content fields, you should assume that they will do so. This can be dangerous towards maintaining the site’s long-term design integrity. It can also be detrimental to the site’s operation … an unclosed tag in one field can literally de-style and destroy an entire page. Furthermore, many of the HTML tags familiar to clients, like <b> and <i>, are deprecated in XHTML. Lastly, if a client begins to apply HTML towards introducing style, then the portability of the content will be compromised for future redesigns.

HTML/XHTML is an obvious way for clients to populate necessary structure into body copy fields (structure like tertiary headlines, lists, blockquotes, etc.), and this is desirable. But the broad scope of this markup, and the dangers of unclosed tags make it less than ideal for a client to use. If the CMS is enabling use of HTML/XHTML, ensure that it is placing limits that are consistent with what you’ve defined, and ideally have the CMS verify the validity of any client-entered markup.

Lightweight markup languages

LMLs provide a desirable alternative to HTML and WYSIWYG editors. They provide a means for the client to structure their content in a simple manner, without introducing style. Most are immune to the dangers of unclosed tags, and are thus very safe.

While the output of lightweight markup languages is ultimately translated to XHTML, they provide a simple and safe middle-ground that is beneficial to the the design’s longevity and the content’s portability. Markdown is an example of a good lightweight markup language to consider if supported by your CMS.


The disadvantage of lightweight markup languages is that the client may be averse to learning something new. They may perceive lightweight markup languages to be more complex than they are. Clients can immediately grasp how to use a rich-text editor for basic edits, but a lightweight markup language takes more investment on their part. Providing the client with a cheat-sheet of syntax goes a long way towards mitigating this. Lightweight markup languages are very easy and simple, but explanation is required.

Communication leads to design integrity

Clients want to protect their investment, and designers want to protect the integrity of their design work. This is a common goal. Make a point to communicate with the client about how they can protect the design integrity of their investment. Here are a few tips that may aid in this goal:

Explain style and structure

Explain that the CMS is there specifically for content edits, and that the look of that content has been predefined in a manner that most benefits the longevity and consistency of the site. Communicate the difference between style and structure, and why it’s crucial to maintain that separation.

Document the typography

Provide the client with a document outlining the scope of typography you’ve outlined for the site. Make sure they understand how the styles visible in this document translate to the edits they make in the CMS. While we want clients to focus on structure, it’s often simpler for them to visualize structure as style. This document makes that possible.

Maintain the relationship

Establish a relationship with the client whereby they will consult you (the designer) if an unmet stylistic need arises. In this way, the need can be properly addressed in a manner that is structurally sound, consistent and complimentary to the design.