March 9, 2009
Stress-Testing a CMS-Driven Design
The architecture of dynamic content
When a site goes from design comps to development site, a lot of change has taken place. Once the design is being populated with real content, and the navigation is functional, you should stress-test the design in two key areas: translative and invasive stress testing.
Translative stress testing
The designer should carefully go through the development site to ensure that all key design aspects have properly translated from the approved design. Any inconsistencies should be noted and fixed before a site launches.
Focus on proportions, colors, margins, and padding. It can be helpful to take screenshots from the development site and overlay them on top of your design comps at 50% opacity. This will quickly point out if there are any major placement errors that need correction. Pixel-perfection is possible, so insist upon it if it is important to the design.
Stress testing typography
If the layout and colors are lining up how they should, focus next on type. Ensure that the details of your typography have properly translated to the development site. Stress test by creating a page from the CMS that duplicates the typography you designed. In this manner, you can test to make sure that all the tags you designed for are, in fact, displaying properly.
You should also stress test the design and type elements when they are scaled up (or down). Use a browser that scales text proportionally without the layout (like Safari), and make sure that positioning and alignment are retained as the scale of type changes. For example, if a particular block in the design should left align with another block, it should retain that alignment regardless of scale. If it does not, that may mean that the developer used absolute right positioning rather than absolute left positioning (something that is easy to fix, but must be pointed out). For more details and examples, see the article on scaling dynamic type which is part of this series.
Next, stress test the code translation. View the source and confirm that the output is actually populating with the correct markup. If you designed headlines to output in an
<h1> tag (for example), then make sure that’s what is happening. An unknowing developer might bundle your headlines into an anonymous
span tag, thereby making the markup structurally unsound. As the architect, you should care about this structural integrity and must insist upon proper markup. The accessibility of the site depends on it.
While you are there, investigate the
<title> tag in the
<head> section of the document. Make sure that this
<title> tag is relevant to the page being viewed and not a generic tag-line, company name, or worse… blank.
It can also be helpful to stress test the code translation by using a code validator, like the W3C XHTML validator. But exercise enough restraint here so as to let your developer determine what is important and actionable.
Invasive stress testing
During invasive stress testing, the designer and/or developer invades the design by over-and-under populating values in the CMS. In essence, you are trying to break the design with the inputs provided by the CMS.
Overflowing the design
Examples of invasive stress testing with overflows may include actions such as inserting a 50-word headline and navigation item into the design, or populating a sidebar with twice as much text as the body copy. Does the design react gracefully, or does some element overflow into another? Do these tests reveal potential problems with line height or positioning?
Underflowing the design
Examples of invasive stress testing with underflows could be excluding, or under-populating specific fields. For instance, you could exclude a sub headline or summary text in an article. Does the design react in the way you expect?
Some of these scenarios may seem more likely than others, but they can be helpful in revealing issues that may crop up a lot sooner than you’d expect. Overpopulating a headline with 50 words may reveal issues that would likewise affect a 12-word headline. Rather than waiting for problems to crop up as they occur, invasively stress test your design with unlikely values in order to locate problems quickly. The examples mentioned in this section are only starting points. What boundaries you set for your own invasive stress testing should logically be determined by content, site and CMS.