Understanding how content strategy tools can be used by the whole team is a good first step to creating a content-first design process. But process and workflows need to be changed too. Instead of waiting for content to be ready, projects that use a content-centric process prepare content at the start, so that it’s ready for a system to accept it.
In a previous article, Content Strategy Tools for Everyone, we talked about how anyone can use content strategy tools to shift the focus of the design process on content. Now we’ll look at a process initially intended for a digital agency team that included a project manager, content strategist, visual designer, front-end developer, and CMS developer. I modified it slightly to fit an in-house team that included the same roles plus a programmer in a different department and an external CMS developer. Both instances involved working with clients and stakeholders who were not professional writers, and usually not web experts.
It will likely take a few tries to set a new course. Each project will get you closer to a process that works for your team and also involves clients or stakeholders early and often. Whether you’re the strategist, designer, or developer, you can steer the change to a content-first design and development process.
Collaborative Documentation
In a collaborative process, it’s not just working together that is important. The documentation itself needs to be collaborative. No spreadsheets hidden on a hard drive, no wireframes stashed away in a personal folder. Bring them all out and share with everyone on the project!
Create a Central Worksheet
At the heart of collaborative documentation is what I call the Site Build Worksheet, a Google Doc for all team members to add to as they move through the phases of a site build or redesign. It includes tabs for Content Inventory, Content Type, and Views. (“Views” is a Drupal term for dynamically displayed content. Adjust as needed for your CMS.) Consider this template a living document, or a gift that keeps on giving. It starts as a content inventory spreadsheet and expands throughout the life of the project. Make it collaborative so everyone can access and update it at any time – Google Drive works well for this. It will save time, money, and pain as long as it is maintained.
Using the worksheet to guide collaboration starts by becoming intimately familiar with the content through the content inventory, which likely resulted from creating a new site map. If your content inventory usually includes only site pages, go deeper and include all the content components. Think of the &ldquo page” as a display concept, made up of a bunch of different components. You’ll start to tease out content types and start noticing patterns and structure, potential reuse opportunities, image requirements, governance rules, gaps, duplications, and more: in other words, the content requirements. Each content component needs its own row on the spreadsheet. Add columns as necessary to make sure all your team’s information needs get documented for design, development, and content entry. Depending on the size of the site or product you are working with, this could take as little as 2 hours or as much as 8-10 hours. It may sound onerous, but it’s time well spent to avoid that much unexpected time or more just before launch when things aren’t quite right.
Review as a Team
With the content requirements in hand, have a meeting – probably many meetings (more than 2 hours at a time and people start dropping; allocate 2 hours per every 6 content types in your inventory) – in which the project manager, content strategist, designers, and developers are present and participating. Get the team together and walk through the content inventory. Discuss and document everything in the worksheet, including notes about decisions made and questions that can’t be answered yet. It is important that all the nuances be discussed, and expertise shared across the team. For example, back-end developers know how to best set up the CMS to accommodate a particular dynamic display, while front-end developers can chime in about how to best structure something to make an element work in a responsive framework.
Schedule the meeting to coincide with the first round of wireframes, or even before, if possible. Designers love when content is ready to be added before they begin. In addition, there is now cross-documentation and artifacts for future use.
Define Better Content Types
One of the main outcomes of the meeting is a full definition of content types. Too often, a high-level list of content types gets handed off to a developer, who is left to make guesses about the best way to set them up. When it’s time to enter content, the build may not match the actual content. But a collaborative build planning process facilitates discussion early, and makes for smoother implementation.
Content types can be simple or complex, and each content has elements and relationships, which can be created in multiple ways. It’s vitally important for the content strategist, designer, and developer to agree on the content types, so that they are set up appropriately for the project at hand.
For example, a Press Release is typically a straightforward content type, including the following elements:
- Content type fields: headline, date, city of issue, body, media contact information
- Template display fields: headline, date, city of issue, body, media contact information
- Listing page rules: Display the headline that links to the release and date (Month DD, YYYY), descending date order (learn and use the language of developers – that means most recent first), 20 per page, with a pager element
- Business rule: Automatically unpublish any press releases older than current year + 1 (not just older than a year, which implies a year from today)
By contrast, an Event may look straightforward but could have many relationships with other content types, and may even need to be broken down into multiple content types, though it might start with 5 simple fields:
- Event Name
- Date
- Time
- Room Name
- Description
Once you really dig in, it might turn out that this Event includes Sessions, which are part of an Event, or part of multiple Events. That makes Sessions and Events content types that link to each other, thus establishing a relationship. Both the Events and Sessions could have Speakers, Sponsors, Locations, Price, and a Track – all possibly different content types. And the Event might need to connect to a separate registration system. And more questions arise: How will the Sessions be displayed? What about the Event? It is easy to see how quickly this can get complex. It’s best to have more than one brain to tease out all the parts and their connections.
Do Early Testing With Real Content
When a team has collaborated on the structure, they can easily test early in the implementation phase. By defining the content types, we also identify how much sample content we need in order to test the system. When determining sample content, be sure to consider both the “detail display” version of the item as well as any listings where the item’s content elements will appear dynamically.
For example, let’s pretend we’re designing a site for a conference. “Speaker” is likely to be one content type. There will be a page displaying the details about the speaker, or the “Speaker page.” We have questions to answer:
- How many different ways can this content type be displayed?
- What content is required for each display scenario?
- Is additional information needed to determine which items should appear and in what order?
- Does everyone have a bio and a photo, or do some not? We’ll need to be sure to enter sample content for both instances, if so.
There will also a list of all the speakers somewhere on our site. If there is a separate listing of keynote speakers, concurrent session speakers, and workshop speakers, there need to be at least two of each type to make sure each display works within the page design. In this case, the specification for sample content (which is a column in the Content Type tab) would be:
- 2 of type = Keynote
- 2 of type = Concurrent Session
- 2 of type = Workshop
- At least 1 with photo
- At least 1 without photo
The earlier you have real or sample content, the better. Rob Mills explains in detail how to make content meaningful and useful at this stage of a project. When all else fails, write out the character count and instructions or specifications for the future content, instead of lorem ipsum. Be sure to use character limits, not words. You can’t predict the length of text when you specify the number of words. Also, CMSs are better at enforcing character limits than words.
Advantages for Content Creation and Production
When complete, the worksheet will document which content we’re going to publish (inventory), how that content is structured (content types), and how it will be represented in the interface (views). It also sets up authors for success and allows your team to more easily manage content.
Author Support
When authors have very specific instructions and structure, the editorial process will go more smoothly. You won’t end up with blobs when you need chunks, authors writing 150 characters for a design that can only accommodate 75 characters, or sentences in place of button copy. When given the specifications ahead of time, in the place where content is being written, it is more likely to be right the first time.
We can also represent the structure for the content creation in content spec sheets (see Content Strategy Tools for Everyone), as a guide for authors. Be sure to chunk up the spec sheet to match the fields defined in the worksheet as much as possible. This makes content entry much easier when the time comes. Spec sheets done in a Word document are fine if you have few authors and a relatively small amount of content to create. For more complex sites with multiple authors and an editorial workflow, you can use a content production tool like GatherContent to work even more collaboratively. (GatherContent even has connectors that allow you to publish right to a CMS.)
The CMS can support authors too. When defining the content types, think about ways the content management system can be set up to give context and tips right at the point of content entry. Some of the ways to do this include:
- Help text for certain fields
- Notes on character limits
- Putting fields in logical order and grouping them with labels
- Enforcing rules like file size limits and file types allowed
In other words, use principles of good form design when setting up the CMS.
Keeping Track
Once the content, design, and CMS are ready, you can continue to add columns to the worksheets as needed. In the Content Inventory tab, initial columns cover content identification. But when the CMS is ready, we turn our attention from content identification to content management. We can create new columns to manage the content creation, content entry, and the QA process. For each piece of content, I like to assign authors, editors, and due dates, plus reviews and final sign off. Make simple X entries to note when something is finished and ready for the next step or use dates or initials if that helps. By checking off each step, everyone can easily see what’s done.
Bonus: Add a formula at the bottom of the entry columns to see instantly the percentage complete! Everyone is accountable. Continue this through final review.
Likewise, on the Content Types and Views tabs, there are columns to track every step of the build and testing. In this process, the content strategist gives final sign off on content types and views. This means that it is built so that content can be entered properly and styles are accurately applied. Start with the content, end with the content. And check on the content at every step of the way.
Making it Happen
Whether this process is implemented in an agency or in-house, education is essential. The biggest challenge is educating clients and stakeholders on the need to slow down at the beginning to make sure the end product is right.
Just as research should come before design, planning comes before content creation. With the content definition work done upfront, it takes less time to reach consensus about visual aspects. When exact specifications for your CMS are discussed and documented, it takes much less time to build it out. The secret is for everyone on the team to know just enough about what each person does best and ask for input rather than making guesses. It’s a smart investment that will make what you create more valuable and easier to support in the long run.