Why you shouldn’t start IA with a Content Inventory

Student Papers by Idiolector on Flickr
I get the feeling that there are some people out there who think that one of the first things you want to do, when starting an Information Architecture project, is a detailed Content Inventory. (Want to get into a discussion about what terms to use and what they mean, go to the IA Wiki – I’d give you a link to the exact page, but the site seems to be down at the minute).
Personally, I am of the opinion that starting your project with an inventory of this kind is probably one of the *worst* ways to go about developing a good IA.
Not only is it the fastest way to lose enthusiasm for a project (hey, you don’t do a Content Inventory for fun… they’re really the most tedious work that an IA has to do). It is also the best way to ensure that you’re *not* taking a fresh approach to how the content might be structured and related.
When you’re doing a content inventory, you’re unavoidably indoctrinating yourself into the way that things are currently done. The IA approach (or lack thereof) currently in use, the way things are named and grouped. The stuff you’re trying to fix. It is very hard, once you’ve been through that process, to divorce yourself from ‘the way it is’ in order to be able to work out ‘ways that it could be’ and ultimately ‘the best way forward’.
And, in the early design stages, you don’t *need* to know every single bit of content and where to find it. You just need to know, broadly, what the really important content is (speaking from a content perspective – there are lots of other things you need to know about your client, your users etc.)
So, rather than doing a content inventory, do a content survey. Have a run through the existing content. Work out what’s there, and find out what’s important. Learn about how much exists, how the content will grow (or not), what content is high priority, what are the different types of content.
Then, while you’re still excited and energised about the project, start designing. Pull out your paper and a pencil and get creative. Imagine all the different ways that you could possibly approach this content.
Design when you’re still fresh, then go do your content inventory and make sure your designs still hold.
I guarantee, not only will you enjoy your work much more, but your work will be more enjoyable for users.
And both of those things, I think, are what it’s all about.
What do you think?
Image Credit: Idiolector @ Flickr

Using Google Calendar to replace MS Project

Tickler Calendar

The more I use Google Calendar, the more I love it.

Yesteday I realised that I could pretty much use it to replace Microsoft Project (if only I could create dependencies between items and spit out a gant chart…. perhaps I’ll just have to train clients to not like gant charts quite so much. What’s with that, hey?)

Google Calendar is SOOOO much better at managing multiple projects + life that MS Project will ever be. (Ever experienced a Project Central implementation? You’ll know what I’m talking about).

When I take on a new project, I create a new Google Calendar and name it after the project. I can then assign tasks to that calendar that appear, beautifully colour coded, in amongst all my other projects and personal activities on one calendar. At a glance I can see when I’m going to be super busy and when I’ll be able to go have lunch out of the office.

Continue reading

Storytelling requirements (and why most focus groups are a waste of time)

So, Malcolm Gladwell got me thinking about focus groups the other day. Actually, he got me thinking about the characteristics of groups and the way that people perform when in front of their peers, as well as perfect strangers.Malcolm was kind of talking about his recent article in the New Yorker, and gave this overview of a ‘taxonomy of reason-giving':

[Tilly says] … We employ four kinds of explanations, he says: conventions (social formulae), stories (common sense narratives), codes (legal formulae) and technical accounts (specialized stories). And we get into trouble when we use one kind of reason in a context where another is necessary….

Continue reading

enjoying analogue wireframing (pencil rules, ok?)


So, I’ve been doing a whole bunch of wireframing lately.

I have to admit that, in the last little while, I’d gotten into the habit of wireframing straight into Visio, maybe after a quick thumbnail sketch on a notepad somewhere.

The site I’m working on at the moment has quite a bit of application type functionality in it, as well as a whole bunch of content, and offers the opportunity to be a little bit creative with the interaction design.

Out of habit, I pretty much launched straight into Visio (after a couple of quick sketches), but the further I got into it, the less satisfied I was with the output.

So, just for a while, I dumped Visio, got a whole pile of paper, some pencils and a sharpener, and just played around with ideas.

Ahhh. That’s just *soooo* much better.

It’s a little bit 37 Signals/Getting Real (although, these *will* end up as Visio wireframes in a functional specification – the size and dispersal of the team on this project demands that kind of documentation), but it does seem to be a popular approach to documenting RIAs. (Jeffry Veen was saying the other day that he’s going from pencil sketch to build these days).

So, what’s so good about pencil sketching your wireframes?

Continue reading