As I’ve spent time researching different aspects of information architecture and interaction design on the web I realized, there’s a lot of good IA resources out there but there isn’t much, if anything, about getting started. Seeing the need, I’ve put together a few of the basics to help those of you out there just getting started in the field.
Information Architecture happens regardless
If you don’t formalize your process for information architecture, it’s going to happen anyway, and it will happen at times when you should be focusing on other aspects of the project inevitably causing delays and hang-ups. On almost every project I’ve worked on, even with a thorough IA process, things that should have been address get missed and end up happening during the design or development phases. With information architecture the goal is to spend as much time as you can thinking about your content, labeling, categorization, information hierarchy, and how everything interacts before you dive into the specifics of visual design and development.
I hear all the time that there isn’t one “correct” way to do a process, and that’s true but not thinking about information architecture is like setting sail on creating your website without charting a course. The site will get built, and it will likely go astray, get lost or never reach port. Without at least thinking about the information architecture your site will likely not be that useful, fun-to-use, or exciting to users. Setting that course is critical.
Information Architecture is both the most important phase and least important phase of your site
Information Architecture is often called a blueprint, or foundation of your site and when looking at it in that way it is the most important. But when you realize that none of the deliverables created are actually final deliverables it can seem like the least. Information architecture should never be over engineered, but it should always be thoroughly thought out.
A successful information architect/interaction designer is a great communicator
Your deliverables need to get people on the same page. You need to communicate your vision of how the site will behave and function as quickly and as comprehensively as possible. If the visual designer understands the site plan but your client is clueless then you’ve failed. If the client gets it but the visual designer(s) you’re working with don’t see what you’re trying to do then it’s just as much of a failure.
Information architecture shouldn’t live in a vacuum
Involving as many people on your team as possible before you get to far along is incredibly important. A kickoff meeting, a few brainstorming sessions, or just a quick get together with some people on the team are all good options. There’s really no correct way to do this, it’s just making sure everyone is involved and knows what’s going on. Not only does it help build excitement about the project it also helps spur new ideas and it usually helps come up with creative solutions to tricky problems. When I’m in these meetings I try and take lots of notes and act as much like a sponge recording and remembering as much as possible.
It’s not about the deliverables it’s about understanding
When I’m working on projects doing information architecture or interaction design my biggest concern is being a clear communicator. If wireframes are going to work for the client and the visual designer I’m working with then that’s what I’ll use. If the visual designer prefers working with page description diagrams instead of wireframes because they feel it infringes on their creativity and the client is understanding the page descriptions then that’s all I’ll do initially. If I can get everyone on the same page with a napkin sketch and few notes then that’s what I’ll do. It’s rare that everyone “gets it” just from something that simple, which is why there’s navigation structures, site maps, process flows, page description diagrams, and wireframes, but if a napkin sketch is all it takes then that’s all that needs to be done.
It doesn’t end at the hand-off
Like I was saying previous, information architecture and interaction design happens throughout the entire web design and development process. Just as an architect comes back to the job site and checks in on the construction you too should check in on the process. You’ve spent a lot of time thinking about problems and solutions and no matter how clearly you’ve tried to convey them questions will always come up. A successful site is in the details and making sure those details are fully recognized is important.
Conclusion
In the end information architecture and interaction design is about clearly communicating to everyone involved in a project so that people understand what’s going to be created and how it will work. It’s a big task but doesn’t have to be an overwhelming one. The best advice I can provide is to not focus on the deliverables and focus on making sure you’re communicating with them.
Resources
Here’s a few good resources to get you started:
All very true and well thought out points. I couldn’t agree more. Nice work.
Nice and concise, Tom!
The one thing I’ll add: even the smallest project can benefit from a focused information architecture phase. That phase can be as fast as making a sketch on a piece of paper, but part of the advantage of doing more formal diagrams is that the formality forces you (and your team) to work a bit slower and more deliberately, and you can notice things that you might otherwise speed past.
As you said: “it’s not about the deliverables it’s about understanding.”
@Garrett Dimon: Thanks!
@Jay Fienberg: Agreed. The more formal deliverables encourage clients and internal teams to look at things closer and really suss out those problems you might miss from just a sketch on a napkin. People may think they’re all on the same page but in reality they weren’t because they hadn’t thought of thing “x” yet.
Great post Tom.
After recently suffering through a project with wireframes that were provided to me with what seems like no thought at all <em>(it’s still not been made clear who exactly created them, though it is clear they were designed by a committee of people who have next to no understanding of building web applications … ick!)</em>, I wish I had your post to show them earlier to help explain where they were going wrong.
There was little thought put into the app itself it seemed as it was just a watered-down amalgamation of features from x-app and y-app with no clear focus. I could barely wrap my head around what was provided to me to design around.
It wasn’t until I was able to get them to just stop that things started to turn around.
Taking the time to really think about what was important, how to structure information within the application so that it would make sense to users without requiring them to develop new mental models for the app and its features really helped bring the project back into focus and actually progress instead of continue spin in circles.
@Scott: Thanks, yeah I’ve found my experience with project management has really helped, especially when starting in on the IA initially. Getting everyone on the same page with what’s going to be built can involve a lot more politics and communication then wireframes and page description diagrams.
Thanks all..
Thanks a lot.
Great post, Thanks Tom
Tom, It’s very goog job. Continue!!!!