In almost every project we do, a client reads our proposal and asks the same question: What is this “Information Architecture thing” and why are you charging me for it?
The answer, of course, is because without it, the project will have no foundation. A house without a foundation is only going to last until the next natural disaster. The disaster in this case is unintentional human error.
It’s Not Skin Deep
I like to tell our clients (and anyone else who’s willing to listen) that information architecture is about building the right foundation for the right house. Not every house will require the same footprint, size, materials or wiring. Each project, whether it involves a Web site or Web application, has a different set of requirements that start with the strategy and go right through to the end of construction (including testing and bug fixes). Without capturing these up front in a proven method, how can we expect not to miss the finer details? I’ll give you a great example: A member of the QA team needs to care about your overall site architecture. Why? Because how else would they know what the expected result is if you didn’t set the standard in the first place? The IA and the Designer have a great deal of influence in the project success rate.
The deeper you go into finding the right architecture, the better prepared you’ll be in offering solutions that make sense for all moving parts, not just the client-facing ones. It’s a pretty common thing when you’re halfway through a project to have a client walk over and say something like “hey… we were talking and we’d love to have the whoozit talk to the goobit once a user finishes filling out that form…” and you’re prepared with the right level of detail to give them a resounding “Yes!”, not only because it’ll make them happy they hired you, but because you didn’t waste any of your own time trying to figure out something that you should have already known.
Note: If it’s a less technical project, bring a designer into the discussion. If it’s more technical, bring a developer. Tell them why. Ask them to be engaged to make the meetings more productive.
Prepare Your Client
It’s always important (and I really do mean always) to inform the client (and your project team) just how much information you’ll need to get the job done. A high-level site map immediately following the creative brief is a great place to start. Put it on the wall, have the client and your team drill down a path and see if you can’t find your own pitfalls.
Preparing your client for what they’re about to experience is half the battle. My take: I need them in the room with the presence of mind to knock something down or increase the priority. If they’re not doing one of these things, they’re not engaged. Don’t bore them to death. Give them a task. Encourage them to tell you their business. They should know it a heck of a lot better than you do. Give them a list of things they need to think about before they arrive at your kickoff meeting. While you won’t be able to force them to complete it, they’ll at least know it’s coming.
Iterations, Iterations, Iterations…
Keep a running tab on those hours (not to charge back the client, of course, but to keep tabs on how long you’re taking on each section of the project). Don’t forget that an informed client is a happy client. I would never worry about “bugging” the client with “too much”. If they don’t want it, they’ll “recycle” it. Chances are, if they’re already engaged, they’ll keep up to speed since at the end of the day I’m sure they’d like to see a return on that investment.
- Do a fair amount of iterations to ensure that you haven’t forgotten anything.
- Go as deep on each level as required so that the client gets all their questions answered before they come up.
- Don’t get in the habit of waiting for the client to ask you how something should go.
- Do offer suggestions at every turn; you’re the expert.
Share your experiences with the team. Follow up and ask their opinions. Communication, as always, is key.