A few months ago, I was happily managing one of my first Sparkbox web projects. I did the content audit and had an approved architecture. Then, I went to kick off wireframes with the UX team and learned that audit and architecture weren’t enough to build effective wireframes. I needed something else.
As a project manager, I needed a solid place to start UX design. But as a content strategist, I didn’t have all the content, only the ideas behind the content. I developed the content priority guide to fill in those gaps. It’s part content modeling, part stripped-down wireframe, and it's useful throughout developing a site.
The Guide Tells You…
The content priority guide identifies all the content on each unique page of a site. It breaks the content into items with elements and puts them all in their priority order using only text.
The content priority guide highlights what content is shared across the site. As you build more and more templates, you discover what content needs to live on the different pages of the site and where you have common elements shared across pages that need special reuse attention in a CMS.
We like to build modularly, with flexibility and fluidity of content in mind. The content priority guide aides that effort by identifying which content elements appear on which pages and which elements are optional (sometimes almost all of the content is optional). This is especially important for design and CMS planning.
The guide also lets you add notes about how many of these items to accommodate on the specific template and how the elements get pulled onto the page (automatically by date, curated by tagging, manually selected, or something else entirely).
How It’s Structured
The content priority guide helps you realize how you should structure your content within your CMS. Knowing the content well allows you to understand when something is uniquely identifiable, such as date and location, versus when it’s a text field that could feature a variety of content. Whether you use separate text fields or inline editing, you’ll be much happier if you find ways to chunk content in a CMS that lets you share content everywhere.
Why I Like the Guide
It's nimble and collaborative. In the spirit of creating a responsive web design process that makes our clients our partners, we’ve done the content priorities in Google docs and invited our clients to review and edit them. The guides take thought and planning, but since they’re all text, the creation and editing are quick. Unlike some other mediums in which we work, a client is probably fairly comfortable editing a Google doc. The doc gives you version control, while giving your clients all the freedom to edit away and demonstrate their value and critical roles in projects.
It isn’t design. You can’t confuse the content priority for design. This is a shared benefit of a content prototype and content priority guide. They both allow your client to focus on the actual information that will appear on the page and its degree of importance. Expect to be asked, “What will that look like in the design?” Clients are usually curious what the design is going to look like and will probably ask some of those questions and give some of that feedback when reviewing the content priority. And that’s ok. Their questions and comments now, on a document that is very easy to edit with them, are going to be valuable to each of the next steps in the process. So I take notes on the client’s visual feedback/direction and keep them with the content priority guide to pass along to the team.
It isn't actual copy. The benefit I see in the priority guide compared to a typical prototype is that the guide lets clients think about what content will need to be created, and it allows them to offer feedback about the value of that type of content, instead of your exact wording. It gets deeper into the “what” and “why” that can easily be overlooked when you jump directly to actual copy.
These tactics are part of our effort to get fruitful feedback from clients early in a project.
The content priority guide is useful to get feedback on exactly what content needs to be on the page and what sort of priority order each piece of content has compared to the rest—with an added bonus of allowing you to dig into content modeling and start to think about your CMS early on. And if you use the same names for the content elements as you would in the CMS, it makes setting that up a lot faster too.
The projects we’ve tried this with so far have resulted in much less time spent wireframing, minimal edits where we’ve done wireframes, less design changes than expected, and quick CMS setup.