I was having an interesting conversation with a friend-of-a-friend last weekend, discussing the need for pre-CMS content workflow tools (classic lad banter). More specifically, said friend-of-friend was contesting the idea of decoupling content management systems: having platforms separate from the publishing CMS that focus purely on editorial and production workflows. He believed you could do all of this work directly in the CMS.
While this is a fair point (technically at least), I've since been plagued with the arguments I could have given against this idea of doing everything in the CMS.
At the time, I just criticised the general user experience of writing and managing content production in a CMS, and mumbled Karen McGrane's analogy about printing presses (about the difficulties of having one tool that attempts to do everything).
I’ve since realised that my answer totally failed to confront the most blatant problem with his point: it implies that content production doesn't require a dedicated process.
You Can't Sketch in a CMS
The funny thing about this conversation was that the man actually worked at a UX consultancy; a place where process is obviously a huge deal.
In the context of extreme design research, user testing and business evaluation, it seems a bit mad to suggest that everything surrounding the creation of content can simply be done in the CMS. An afterthought, or at least something which can be executed in a (very general) vacuum.
And that would be my more considered response to the man: that by suggesting content development can be done in the CMS, I think we're in danger of assigning content as an afterthought; implying that it doesn't really require a dedicated process and (more seriously) that it isn’t to be considered a component of the design or UX work.
Here are a few more tangible reasons to avoid a CMS-centric approach to developing content:
1. Projects Run Late
The time taken for content production is often underestimated. This is obviously more likely when production planning is not done up-front (it’s impossible to estimate hours for undefined work).
"We've finished your website, we're just waiting for the content" - the guy
In failing to properly evaluate content requirements at the start of a project, or avoiding any governance around your content production, you can't really complain when estimations are skewed and your project is delayed.
How to avoid these delays:
A popular approach is to run content planning workshops (with people from both the client and agency side of the project) at the start of a project. These can work really well to get everyone onboard with the process for producing content..
As a result of these workshops (/group therapy sessions), everyone will also see how much work is involved and estimations will be more accurate.
It can be nice to focus the workshop on defining the production stages involved with getting a specific content type from draft to published. So you might look at the various research, drafting and review cycles involved with getting an ‘events page’ published (and also keeping it up to date!).
Once you’ve gone through the process, you can calculate the time involved to complete the process, and then multiply this by the amount of pages in your project. People may weep.
2. Budgets Blow-out as the Project Churns
An obvious outcome of failed estimations is a failure to work within budget. An expensive afterthought.
How to avoid breaking budget:
Once you’ve done your workshop, you can very clearly scope content production into your budget in a way that your client will understand. You’ve laid down the ground work, and brought to light the need for an investment in content production.
3. Poor Quality Content Gets Rushed Through Production
Ground-hog day: good quality content takes time to produce. When it's not given the time, research, planning and consideration it deserves, the outcome will be content that fails to engage people. That’s pretty dangerous.
The creation of effective content, in some situations, can definitely end up being more time-consuming and complex (in terms of management at least) than the creation of the technology and the visual design for a website project.
You definitely argue that visual designs are more easily repeated using pattern libraries and style guides, creating a set of repeatable rules. There are also very clear standards and user-expectations when it comes to information architecture and the structural design of websites. It's a lot more obvious when this UI or structural design is inconsistent or doesn’t work (content is a very ‘dense’, and ‘ambiguous’ medium to test).
How to avoid low quality content:
Give yourself time. And define a process.
By having a dedicated process around content (before the CMS), it becomes much easier to factor in tools to help you create content that works.
You should dedicate some time upfront to create a style guide to help people create content that meets the criteria of your project. This can feel a bit daunting but there are plenty examples you can use as templates for creating your own.
You can also use collaborative online editing tools such as Google Docs, Draft, Penflip, or GatherContent to host your content production in a central place; making it easier to manage your process and enforce your style guide.
4. Poor Design Decisions are Made Without a Knowledge of the Content
Quite predictably, this argument leads us back to the idea of a content-first approach to web design. The whole concept of content being left until the CMS suggests a very much content-last approach. It suggests that the research and design take place, then the CMS is built out, and then it's just a matter of filling in the blanks with the content.
How to avoid making decisions without a knowledge of content:
This one’s pretty rhetorical: you simply make design decisions with a knowledge of (and based on) the content. Farewell, lorem ipsum.
There are lots of recent resources on wireframing and prototyping with real content (Typecast is a nice tool for helping out with this).
Even if it’s not the final draft, it just makes sense to use real content in your wireframes and early designs; to see if your communication actually works, holistically.
5. Thus the Overall User Experience Suffers
When design and content are disconnected, the entire user experience is at risk. When we're considering someone's experience using a website, we should be greatly informed (and test) the content they are consuming. Simply testing someone’s journey to the content doesn’t really test the experience. It’s like analysing someone's trip to the cinema, but failing to consider what they thought of the film.
How to avoid a failed user experience:
There’s a tendency for usability testing to neglect content. If you’re doing user testing, you should involve tasks and questions around the information taken from the subjects session. What did they extract from the content? Is it what you expected? Is something important made unclear? Is something too prominent that shouldn’t be? How did this impact their experience.
Even if you’re not doing formal user experience testing, it really comes down to acknowledging that content is always going to be a massive component of someones experience on the web.
6. Hence the Site’s Business Objectives Fail
When content fails to meet the needs of your users, it’s unlikely your business objectives will be met.
And when your business objectives are not met…
this makes the project a failure.
And nobody wants that.
Process
Nobody (well very few people) really believe that content can be left to the last minute. The whole “content is important” campaign is well since over; and the value of content, and of working content-first has definitely been embraced.
But, while we might agree that content is strategically important… there still seems to be a lack of investment in a production process for creating this content. Repeating the words of Karen McGrane:
"I had a client ask me once 'Is the CMS more like a printing press or more like a workflow tool to manage all of our publishing processes?' For many organizations, the real pain is with the production processes that happen outside the publishing system." Karen McGrane
When it comes to the design and technology components of web projects, there seems to be such an advanced set of processes that support the development (and iteration) of well considered solutions. Content doesn’t seem to exist in the same light.
A belief in Word document and CMS content production seems to underline the problem, and it’s why I would continue to argue for the existence of tools, processes and practical methodologies that encourage governance around the production and testing of well considered content. Outside of the CMS.
Do you have a production process for content? I’d love to hear your thoughts in the comments.
