In the quest for improving our project workflow, we have tried many methodologies over the years, and while it’s difficult to say that every single attempt has gone as planned, each project has presented its own challenges, which bring us to where we currently stand.

Up until very recently, our projects usually kicked off with the information architecture phase. While there’s nothing wrong with taking that route, as the client can quickly get their hands on some tangible visuals, it’s never an entirely fulfilling process. It also presents lots of questions that delay progress at such a crucial time of the project. There had to be a better way of doing things.

I imagine there is many better ways one would approach things, but our goal for the coming months is to get our hands dirty with a proper content inventory & audit process. These aren’t some new concepts we’re presenting. Content audits have been around for quite some time, and they are as important today as they were ten years ago.

So what are these concepts and why should you care? To sum things up without getting into the details, a content audit consists of gathering up every single piece of content (keeping navigational hierarchy intact), and rating this content with help of user data gathered from an analytics suite.

While that may sound tedious, how great would it be to have someone on staff that is intimately familiar with all the content on a website? From our recent experience: pretty great!

A recent project came up and gave us a chance to put all of the theory we were tossing around into use, and see if it all actually played out as it did in our minds. It’s one thing to constantly talk about topics that begin with “Wouldn’t it be great…”, but it means nothing if it cant be put to use.

While the process will still require some tweaking to make it more useful for us, we’ve discovered that the time allocated to the inventory and audit will save time and frustration at different points of a project. Everything from the early sitemap to the final QA are made easier thanks to the time that was taken before any tangible work was begun.

The information architecture benefits by having a lot of the tedious work all but complete. Sitemaps almost do themselves, and the wireframes begin to have much more meaning to the development team. Previously, wireframes were used to show the client where things go, and how the site will look as a doodle, or a collection of grey boxes. Now, we’re using wireframes as a way to get our development team building the site before design is even touched.

Wireframes are now used as a way to plan out the Drupal configuration. We can visually identify content relationships, and use these as a way to quickly test functionality before we even touch code. We know what content types need to be created, what would work better as a taxonomy term, and how to make use of all that Drupal has to offer.

I’d love to get into every little detail on how a content inventory/audit has indirectly helped our config process, but that will require some more thinkin’ on my part, and it’s something that will require it’s own post in the near future. So stay tuned.

Knowing the content that you are working with seems like such an obvious idea. The truth is, we tend to think more about the design and code than we do about what gives the website it’s purpose. As we’ve discovered, knowing the content can only benefit the design and code.