Content types can be considered the 'building blocks' of a website; like the selection of Lego pieces you used to build that unique police-boat-fire-engine-robot. Some can be quite complex, others can be simple little cubes.
Cleve Gibbon explains more tangibly: "A content type is a 'unit of reuse' ... For example, a chapter content type can be assembled into a book, or a series of posts aggregated to create a new blog."
Although content types can be presented as quite abstract and technical (as I've possibly just done), I believe they can work extremely well as a practical tool to help plan and maintain websites, from the start to finish, and used by everyone involved.
While the term Content Types is often locked within the CMS, it can be much more valuable to take a content-type-centric approach right from the beginning of your project. We can use content types as labels to acknowledge these 'units of reuse' or even just patterns in an existing site, to describe what should exist in a new site, and as templates used by authors and project managers to gather and produce content. Finally then, Content Types can be used as highly adaptable and structured formats for publishing content.
Content types first, content types in the middle and content types at the end.
As a lot of agencies and in-house teams work at the moment, it seems that content is constantly changing format and shape throughout projects, and having to be passed on and squeezed and reformatted until its eventual publishing. Content Types are a great way to encourage constant square-peg-square-hole situations.
Content type lifecycles
There's was a lot of discussion around the importance of connecting content models to real content towards the end of last year; making sure these models can adapt to the actual (messy human) content that exists in the production process. The problem people have acknowledged is that content types which have come about from early content modeling processes can often break when they are actually being used in the 'real world', with real content.
I think the process of using content types to not only plan, but also to prototype and produce content (which we can discuss shortly), is a solution to this. This means we can quickly iterate on content types and pass changes down the line. This fits in extremely well with in an iterative Agile workflow.
Design
It's more efficient when planning a site to begin by outlining the patterns that exist, as opposed to listing each individual page that might exist.
The benefit is that the structure of your website is formed around a set of well researched components of content. By using the terminology that stemmed from research, this ties all proceeding work right back to an understanding of your audience, the objectives of your organisation and the patterns that connect these two things. It's a very similar concept to Domain Driven Design.
Since each content type typically has a clear function associated with it, people are encouraged to think of content purposefully (what is this piece of information supposed to do?) and to be aware of the audience (who is going to be reading this?) and the context (where is this content likely to be presented - where might it end up?).
Production
When it comes to actually producing content, content types offer many of the same benefits that Erin Kissane extracts from content templates:
- Collect information more quickly, by giving experts an easy fill-in-the-blank structure to work with.
- Speed up and simplify the content development process by producing more uniform first drafts that are easier to turn into final web copy.
- Improve the structural consistency of your final content.
- Reveal any gaps between the communication needs of the organization's various divisions and the content structure you thought you needed, while there's still time to fix it.
By agreeing that the creation of new content types is preceded by a proper review process; you can make sure your site structure stays locked down. This means that any new content added to the site has to fit into the existing taxonomy, or have a good valid argument as to why this initial 'agreement' should be amended. I'm sure we've all seen chaos reign supreme in a CMS where every post created comes with it's own unique category.
Gov.uk provides a brilliant example of this controlled content creation (or, quite appropriately, 'governance') with their use of content formats.
All authors have to specify the content format before publishing anything, and they can't just go on creating new formats (each post is "not a beautiful or unique snowflake" ).
Finding your inner content types
So we know what they might look like, and how they can help ... but where do they come from?
Content types should exist before the CMS
To reiterate: it's important to establish content types early on, and to avoid restricting them to a technical concept within the CMS.
There are three particularly helpful early stage research processes that can help you establish what content types exist (or should exist) in your project from the beginning:
01. Content types via auditing
When working on (or prodding at) an existing site, it's often the auditing process that helps us define an initial set of content types that are used (or should be used) by an organisation. This is a great way to get a birds-eye view on what types of content exist.
Audits of existing content should, as Paula Land points out, be used to spot opportunities, rather than to set boundaries: "I would use an audit to test the effectiveness of what's there, but unless you're going to create exactly what you have in the current state, you're probably looking for opportunities to break apart the content model, at least somewhat.
"You want to make sure you're presenting each bit of information in the best possible way, which might not be its current state. So this is where tools need to be supplemented by value judgments – looking at each piece of content and deciding what it's purpose is, who the audiences are, what format works best for that audience (at that step of the customer journey), and so on."
It is this analysis process that allows you to make sure each content type you have discovered (or acknowledged a lack of) has a well defined purpose, helps perform a task, and is essentially needed.
02. Content types via content modelling
An inventory of content types can often be the outcome of an early stage Content Modeling process. Another mildly blurry umbrella term; content modelling can involve various exploratory research processes. The outcome essentially being a model of your site's information architecture.
Like content types, content modelling can sometimes be degraded to a presentation and storage concept (more tear jerkingly phrased: another helpful model, trapped in the CMS).
There are, however, a lot of people using content models to plan websites.
Less focussed on pages and hierarchies, and more on content types, and categories, early stage content modeling can be approached quite creatively and collaboratively (yah, post-it notes are like super cool, yah).
It's obviously helpful to have an existing set of research data, but getting your client involved can be good as a means to expose what they see as the essential information components of their website, that you can then go forward and interrogate.
03. Content types via user stories
A third technique worth mentioning is user stories: the necessary content types can become blatantly clear when you frame a specific scenario and consider what content might improve it...
- "Sarah has a carrot and an onion, but doesn't know what to cook."
- "John repeatedly gets lost on his way to work."
- "Nobody knows the janitors' name."
Well this is quite fun, isn't it ...
- "Customers are not returning to our site after purchasing."-
- "Our company needs to educate people about the value of trees."
- "We want people to trust us as the industry experts on plastic bikes."
Avoiding going into the depths of research strategies and analysis: whatever method you use to determine the content types you need in your project; the basic aim is to construct a clear connection between the content you produce and the intentions of your organisation.
The content-type-centric workflow
Once you have content types clearly defined, you can use them as templates to collect content from the people that produce it. Sending someone a template of a page, with empty fields for required content, is a lot more effective than simply asking for "some content for the home page" and receiving a blob of a Word document in return…
Using content types as a collection format, you can include guidelines and notes for each piece of content; telling authors how many words should be in a chunk of text, in what tone it should be written and who it is for. You can also include details about where it will be published, and why it exists in the first place.
Following this collection of content, life should be a whole lot easier when it comes to reviewing, editing and publishing the outcome. The content has been written to measure, and written with purpose.
Farewell to fluff and farewell to squeezing those really long bits of text into that tiny little box on your page.
Since the content types informed the design work, and were defined before the CMS was built... everything should fit together like a well considered Lego kit.
Content Types
When something drastically different is going on in the content development process than there is in the CMS, then there is going to be friction in the transition. By using these same labels throughout the entire process we can simplify potentially complex adaptive outputs. Content types can be used like templates when it comes to content development and they can then be used in your CMS to specify relative end-points.
If they are understood and referenced by everyone involved with defining, designing, producing and publishing content, the process becomes faster, and the content produced is always connected to your original aims and intentions of the project. When things change (as you would hope to be the case!) we can easily pass iterations down the workflow.
Words: Angus Edwardson
Angus Edwardson is the product director at GatherContent, where he spends his time speaking to agencies and teams about content.
