How we performed a content audit in 7 easy(ish) steps

When I start a new job, I usually find myself combing through old content for spelling, grammar, style, inconsistencies, and pet peeves. Because I was often the sole content person on a team or at an entire company, it’s been a solo effort most of the time. It wasn’t till less than a year ago that I learned this cleanup process has a name, even when you’re doing it informally and alone.

It’s a content audit. And here’s how my team performed one on QuickBooks Self-Employed.

1. Articulate what you want to do.

The entire QuickBooks Self-Employed team has a habit of winging things, flying by the seat of our pants, and using other hurtling-through-the-air turns of phrase to describe our process. So when my annoyance with the existing web product content reached critical levels, I pitched my idea to the other content designers on the team: Let’s fix our UX content! A sampling of the issues I wanted to tackle:

This marketing-produced dialog that appears when a user chooses to cancel their trial just reeks of desperation.
Here’s a tip: I ALREADY KNOW IT’S A TIP. And GTFOH with that title case and drop-down formatting.
What am I doing here again? Do I know what comma-separated values are? Is there still even a FEEDBACK tab? (Answer: No.)

You’ll also want to select your participants. For us, content designers would be suggesting the content changes, but we also needed to identify which engineers had capacity to implement the changes once we did our part.

Getting clear on what your audit will include, deciding whose job it is, and having examples will help you in the next step.

2. Get everyone on board.

Who could possibly be against improving and cleaning up the words? Yet somehow it falls to the bottom of the list of priorities.

We decided to plan an offsite to get this done — no distractions, no meetings, just an entire day dedicated to correcting as many content problems as we possibly could. And to implement, we confirmed the plan with our engineers very nicely and discussed how we’d work together.

We were lucky to have buy-in from our leadership (it didn’t hurt that we were calling it a “content bug bash” for the benefit of our engineer-driven team), but you might find yourself making a business case. Check (or conduct) qualitative user research to understand how users react to lower-quality content. One reason almost every content-producing organization uses a style guide is to enforce consistency, which bolsters brand perception.

You might have to adjust your timing or your scope, so be flexible. But once you get the go-ahead, shit gets real.

3. Plan.

I highly recommend the offsite approach, but if you’re on your own, you won’t need to do a lot here. If you’re part of a team, delegate. Have a teammate book a space. Ask another to order food (you’ll need it). Make sure somebody plans a freakin’ happy hour afterward.

You must also go in with a plan of content attack. Catalog the content you want to audit in one place, and decide how you’ll record changes. Maybe you already have a CMS set up — lucky you. We didn’t, and we didn’t have a lot of time to execute, so we just took screenshots of the whole product, tossed them into albums on Google Photos.

I forgot to capture a screenshot of this until we had already completed our offsite, but you get the idea.

Efforts like this turn out so much better if everyone feels ownership over the outcome. Delegating tasks instead of trying to control everything yourself is a simple way to do that.

4. Do it.

We showed up at our offsite and followed the plan. I projected the screenshots we took, one by one, on the big monitor. One person recorded the changes, one took notes on interaction recommendations we had, one person had our style guide open, and we all discussed every word on every screen in the web version of our product — all day long.

It us!

How did we plow through the entire product in one day? If we veered off into disagreement or had too many suggestions for one page, we moved the photo into another album to deal with in the following weeks.

Despite tabling about 40 screens for later, here’s what we were able to do in a single day. YMMV.

5. Rest.

We had happy hour and spent, like, a week not even thinking about what we did or looking at any of the results. You might just need a good night’s sleep. Whatever it is, try not to think actively about what you just did. It’s important to let everything marinate inside your brain for a little while, and you really should decompress before moving forward.

6. Implement.

If you’re using a CMS and you can just enter those changes yourself, I want to be like you when I grow up. In our case, we simply let our devs know we were ready for the changes to go live, directed them to our Google albums, and discussed the best ways to carve out time for them and conduct QA.

We gave engineers access to our albums, where they commented to “claim” a change and to let us know when it was done so we could QA. You’ll see that in-person interaction was a factor, too.

Yes, I had to do a bit of nagging, and I bought a couple of rounds of donuts and promised bribes to encourage working sessions. It’s not terribly comfortable, but if you completed the second step on this list, you shouldn’t have to convince everyone all over again that this work is important.

We also followed through on rewriting the screens we set aside for later. We already had weekly team meetings on the calendar, so we repurposed that time for a few weeks to take turns rewriting and making decisions that the entire content team could feel good about.

7. Admire your improved content!

Tiny changes add up! You should feel good about yourself! Share what you did, and toot your own dang horn! Here are a few improvements we made:

UPDATE: no longer thirsty
You know it’s a tip and we didn’t even have to tell you it was a tip. Plus we enforced our preference for sentence case and consistency.
Now we cut to the chase and are honest about our limitations. This screen lets you know what you’re doing, why you’re doing it, and what you still need to do to make it work.

We don’t have a CMS, so we decided to create a wiki of our content (something I wanted to do before the auditing offsite and which would have made the whole process easier, but hindsight is whatever). Now we update the wiki whenever we ship something new, and designers, product managers, and engineers can always see what the latest content is supposed to be. An unexpected bonus: Our localization teams can actually view content in context instead of simply translating the text strings.

Our next step, of course, is to perform a content audit on our mobile apps. But because we have solid and easily viewed web content and a blueprint to follow, it’ll be easier this time around.

If you choose to accept this responsibility, good luck, and please let me know how it goes! If you’re a seasoned veteran of content auditing, sound off in the comments and tell me where I got it wrong.