Color Health: Content basics documentation for non-content designers

How can the content design team be enablers instead of bottlenecks?

It starts with a familiar story: there was more content design work than the content design team could do.

With a small team (5 ICs and a manager), we were asked to support more projects than we had people, so content designers at Color sometimes found themselves in the unfortunate position of being the bottleneck for design projects. This wasn't ideal.

I led a series of team discussions and workshops to help us improve overall, and the need for a "content guidelines for non-content designers" resource came up.

Inspired by Beth Dunn's excellent "Cultivating Content Design" book, I was inspired to find new ways for our content design team to build relationships and add value at the company. This idea for a content basics resource was one of the results of that work.

The need for this resource became even more acute.

We sadly lost two of our extremely talented content designers in a layoff and needed to scale our content practices even more efficiently, as well as protect the time of the remaining designers.

Process

Here's how I went about developing our content basics resource.

Started by grounding in the audience

Color's products vary widely in their audiences. There are testing and research programs for people who are likely not familiar with medical terminology, may have limited English proficiency, and are often trying to use interfaces under stressful conditions. At the same time, there are clinical tools for highly specialized medical and laboratory professionals.

I began by writing "5 Ws (and an H)" to help get people in the mindset of the content they'd be writing.

Adapted existing resources

I'd worked other places with similar documentation, so I took pieces of the things that worked and put them together for our resource.

For example: One team I'd worked on had a very handy cheat sheet of the basics around style and mechanics, which made it easy to find specific guidelines. I adapted that format, using similar information architecture.

Shared and iterated

I shared this with the content design team for feedback, of course, and some other stakeholders who could be the users of the documentation. Based on their reactions and feedback, I made changes, such as changing the formatting of our "dos & don'ts" to be more easily scannable.

The result? An internal resource to help guide non-content designers when writing content

Though it was published only shortly before leaving the company, I was able to share this resource with numerous partners when they requested content help that we couldn't staff. Anecdotal feedback indicated that it was helpful.