Step by Step
Here’s a typical waterfall approach to website redesigns: UX architects create logical wireframes and structure pages. Designers create beautiful mockup templates. Content creators write noteworthy copy. Then developers place all that into whatever content management system you’re using.
So what happens when contributors need to go into the CMS and make changes? Or when bugs start to bog down your developers? Or a header field is unexpectedly missing from the Beta product?
The answer: sadness, surliness, self-loathing, caffeine, repeat. This defiled process doesn’t make for smooth quality assurance.
The waterfall method is structured and orderly. It’s also detrimental to collaboration, inducing myriad problems when someone, at some point along the assembly line, doesn’t check their work. This will happen.
Sure, too many cooks can spoil the broth… but too few cooks, and your caprese comes out of the kitchen lacking the balsamic reduction you looked forward to all week.
There’s no reason why content contributors and developers can’t cooperate to structure a CMS before content migration and creation. That means your content and development need to play nice with each other.
Don’t Wait — Collaborate!
The waterfall model exacerbates a notion that web teams should silo themselves. Content should focus on writing, and Dev should focus on coding. But the process breaks down if I try to finagle the subtitle for this post in ExpressionEngine as a bulleted list (or if a developer doesn’t know to format my bold writing for narrative emphasis).
Our Systems Architect John Williams wrote a fantastic piece about semantic representation of design and content in CMSs. It was a subversively witty wake-up call. The focal point: “The whole notion of separating presentation from data is fantasy. The two are hopelessly intertwined.”
More here:
“As a result, our content management systems are the most anti-design publishing tool since cuneiform tablets. When [content contributors] find ways around our rules, we lock things down even tighter until finally we are nuking most of HTML from the output-filter orbit.”
It’s about usability. Content creators need CMS training, but they also need to follow the rules. And for developers to customize a CMS that works to your needs, that means conducting some user research from the inside of your team. If you’re having a hard time getting started, here are some suggestions.
1. Know What You Can Do (and What You Can’t).
Choosing the right CMS is actually a lot like coaching a sport. You can’t always have the shiniest tools (or teammates). You have to do the best with what’s around you.
Developers and content creators need to discuss what they can and can’t do. We’d all like to have nice things, like browser window-sized live streaming video on the home page… but can your team actually create that content? A round of technical research can help answer some of these questions:
- How many content contributors are there? What kind of content do they publish?
- How do contributors use the current CMS? What are their likes and dislikes?
- Are there any editorial gaps in the front- or back-end that need to be closed? Conversely, are there too many steps to get content published?
- If we were to suggest another CMS for the site, which ones might be easiest for our team to learn? Which do want to steer clear from?
2. Check Your Work (Heck, Check Each Other’s Work).
That doesn’t mean the content team needs to know HTML, or Java, or Markdown (but it helps). They do need to know how to interpret each content field within the page templates.
Content and Development need to stay on the same page — literally. We list each field and its function in a Content Type Definition document.
Make sure content creators work in tandem with developers on this document. This gets rid of nasty surprises during content creation and migration. Like, for example, realizing a banner image field doesn’t exist for a template where you need it.
You can create this in a spreadsheet, or whatever works best for your team. Here’s an example that Andy Hebrank and I worked on during the redesign for Old Dominion University Online’s redesign earlier this year:
List the following for each page/template in your CMS:
- Field Name: Page Title, Header, Footer, Intro Text, etc.
- Field Type: Text, File, Image, etc.
- Field Specifics: More specifications regarding the field type. For example, a space for student testimonials might include an image, a header, and a WYSIWYG text field.
- Required in Template?: A “yes” or “no” question. Is this field optional, or is it required for every page using this template?
- Help Text: Directions for the content contributor(s). Most major CMSs allow you to create instructions for each field. For example, a text field’s might read, “Less than 140 characters,” or an image’s might say, “Dimensions: 500px X 500px.”
3. Everyone Needs an Editor, Even Developers.
And that doesn’t mean a developer needs a copy editor to check their code’s grammar (maybe that helps), but you should have some system of review in place between the prototype CMS and the final product. Even if you’ve done your job right and all the content fields are there, there are still going to be bugs. Maybe a header in the front-end still isn’t showing up on the page preview, or a text field isn’t constrained to its predefined borders.
For these little guys, it’s nice to have a record. We use BugHerd to log these content gaps and bugs. As soon our QA spots an issue, it’s recorded in BugHerd, which notifies selected parties via email, so it can get fixed ASAP.
Preview and Publish
It takes a little extra effort for two teams to break out of their silos, especially if their professions line up on opposite sides of skillset spectrum.
Content creators don’t have to be great coders, and developers don’t have to be great writers. But for a project to succeed, one needs to have a clear idea about what the other is planning to do.
I can see it now on the marquee: Simon and Garfunkel. Batman and Robin. Content and Development.
Right?
