One of the biggest challenges for any website design, redesign, migration or development is getting the content ready to launch. The text, images, media, meta data, alt text, calls to action, micro copy - it’s slippery stuff and if you’re not careful, tends to be everywhere and nowhere at the same time.
What do we need? Who has it? When we get hold of is it it appropriate? Who knows enough about the content to be able to edit it? Who has the authority to approve it before we go live?
Keeping track of content is a big enough job for one person, but throw programmers, project managers, designers and clients into the mix and it starts looking so complicated no one wants that kind of responsibility.
Recently, I needed to advise a group of academics about creating a website to showcase their research. I work at a large University and we have many constraints when it comes to the web so the technical side of things was relatively easy nail down - there are a bunch of rules and criteria and documentation that cover all that. What we don’t have is the same rigour when it comes to the content that will populate that site and of this project, that meant tons of words and images and videos that I don’t know anything about. I don’t know where it is, or who looks after it. That’s what the academics know, and there were a lot of them on this project.
My challenge was to gather content and use that process it to bridge the gap between:
- the researchers knowledge and what they wanted to showcase on the site
- the developers and designers who would build and populate the new website
- the people who would look after the site once it launched
- the site’s intended audience.
Now, I’m not pretending that one tool can make this process perfect. In fact, this is a very messy process no matter how you do it; but I am suggesting that a very useful tool in your arsenal may well be a good old fashioned stack of papers with tables of information on them.
It was time to turn to my trusty friend the Page Table.
Content Kit to the rescue
Page Tables come in all sorts of flavours depending on the need; they’re templated information for every page of a website. We’ve recently migrated to a new CMS so I based my latest page table template on what I knew we needed for every page for that system - so yours may differ but the idea is the same. In this case, I rebranded my Page Tables to “Content Kit" make more sense to the project team and shared it via Google Drive so it was accessible to everyone who needed it.
The Content Kit was a set of pages that ended up looking something like this:
First page: name of the project, website, brief context around what the site was about and why, list of project contributors
Second Page: a site map or architecture of the new site including a unique ID for each page
Page Table templates: one for every page on the site (identified from the site map)
- Page ID
- URL
- Subject Matter Expert (SME) - who’s the person who knows this content?
- Approver - who’s the person with the authority to sign off on this content?
- Objective - why is this page part of this website?
- Title - what is the H1 title of this page
- Sub heading - supporting the title of the page
- Description - short blurb to support objective of the page
- Tags/keyword - any meta data required by CMS
- Share/Content reuse - will this content be shared or reused
- Body copy - type in the content or provide a link to where the content can be found e.g.: on a shared drive or file system (best to have a local copy with the Kit)
- Images - information about what image to use and where to find it; include filename, alt and caption text, meta data needed to support file in digital asset manager of the CMS
- Media - information about which media and where it is; include filename, type, alt and caption text, transcript, meta data etc.
- Call to action - which ties to the objective of the page.
The great thing about keeping this kit on a service like Google Drive is that anyone in the team who can contribute content to the website can work on it in one place. Everyone has better visibility over the scope and progress of the content development and it is a lot easier to see where there are gaps in the content or structure of the site.
- Designers can see and use real content when developing templates
- Programmers can understand what functionality they need to develop to support the content
- Project Managers have a ‘base of operations’ for content gathering
I've found that this centralised approach spreads up the content population and QA phases as most of the questions that arise during the process of completing the Page Tables have already been raised and answered.
It's a beautiful mess
Describing this process here makes it seem organised and foolproof. Unfortunately, like many things where people are involved, it is neither of those things. But it is a heck of a lot better than trying to keep track of content with post it notes, emails, and memory. So next time you’re needing to wrangle a group of people to gather content for a project, consider the humble page table. I’ve found it to punch above its weight, especially if brought into the process early.
