As a content creator and editor, I’ve always relied on Word to communicate ideas to the designers and developers on my team. To “paint a picture” of web content, I’d format, label, and highlight. Word was my go-to tool.
Recently, though, I gave it all up in favor of managing content in WordPress. And I'm loving it.
The Oodles of Source Content Challenge
A client came to us with great information hidden in the depths of a poor site experience. Among other things, they needed the content re-organized so users could find and use it.
Some months earlier, I'd remarked “Wouldn't it be great if we could put all of the client’s existing content into some sort of CMS and start moving it around?” The answer was yes. Let's do it on this project.
This was a classic “be careful what you wish for” moment for me. Without Word, I wouldn’t have a concrete deliverable that I controlled. Instead, we’d all have a living, breathing code base to share.
But, after confirming that we could rollback, compare changes, and even spit out a trusty Word doc if necessary, we decided to dive in.
Mapping It Out
While I went about researching, reading the old site and gaining all the knowledge I could about the client's business problem, development imported all the “source content” into an in-house instance of WordPress.
When debate ran high about the new site map, I used menus within WordPress to quickly create prototypes and test our organizational theories. In no time, it seemed, we had a new site map approved.
Then the Fun Really Began
I created the new site structure in WordPress — a slew of properly named, lovely blank pages. Then I went through more than 200 pages of source content, scanning for bits and pieces to populate those pages.
There was no need for a content audit spreadsheet. Each source content page retained its original URL, so we could document where it came from. Plus, I noted new page destination(s) or whether content was being retired and why, right in the CMS.
Meanwhile, wireframing sped along, informed by an in-depth knowledge of the type, length, and spirit of the source content as well as our strategy for refining it to support new site goals.
As the wireframes were being approved, I was already polishing pages that supported the templates. Once visual concepting began, I was able to point designers to plenty of content available for use in their comps.
No version control worries. No fighting over docs on the server. I just gave them a link and let the collaboration begin.
Oh But There’s More … More Productivity, That Is
Unlike in Word, I wasn’t creating to-do lists for dev to handle later — I noted keywords, added meta descriptions and refined page titles and URLS. I styled headlines and subheads and tables. I uploaded .PDF assets and added inline links. I made anchor, internal and external links, always making sure they were tagged with a good link title.
When I had pages ready, I added them to a queue for QA, who made changes on the fly. I could compare versions to see what had changed, then pass it along to the client.
We gave our client access to the content on WordPress, advising them when to make changes, when to comment, and when to call us. And they reviewed at lightning speed. As I watched their comments roll in real-time, I got better at making choices they would approve in the next round.
Bye Bye Word
I thought I would miss Word. After all, a CMS is an ever-changing code base, not a document I can lock up. But, the empowerment and efficiency it affords across disciplines is so worth letting go.
One complaint: I can compare changes between versions in WordPress, but sadly, am forced to accept or reject all of them as a package. In Word, I could jump from change to change accepting, rejecting or modifying as needed. The latter is better for a control freak, for sure.
Still, I’m not going back. We've already modified WordPress to suit our needs, and I know we can go further. Next time we have a project with tons of existing content, we will.