I love getting a good, well thought-out IA. In my work as a designer, nothing is more helpful than knowing what information needs to be displayed on a page, what interactions need to be accounted for, etc. A well-considered IA also allows me to focus solely on crafting a design that meets client and user needs, which is great. Unfortunately, though, it seems that few people give IA the time it deserves.
Information Architecture deals in a world of black & white, boxes & arrows. It’s not sexy; but that’s the point. The lo-fi nature of IA forces you to really focus on what’s happening on each page. Questions of what’s appropriate content for each page can be addressed without being overwhelmed by how the site looks. IA forces you to ask hard questions and take a serious look at the underlining nature of your site.
Oddly, the lo-fi nature of IA is the part that people tend to rebel against it. Everyone wants to jump into the deep end of design and bypass the unsexy part. But not spending adequate time thinking through your site can lead to huge problems down the road. For instance, too often wild assumptions are made about what content goes on the page and what type of interactions are suppose to happen. This leads to more time and money spent in design trying to figure out the IA, as well as the design. At it’s worst, this scenario can lead to a very toxic relationship between designer and client.
The bottom line: IA is very important to the success of any project. It forces you to take a hard look at what is going with a page and think the site through, without getting sidetracked by subjective parts of design.
This is especially important, I think, when working with clients that are less savvy with technology in general or who don’t really know what they want.
In the past few months I’ve developed a couple of websites as “side projects”. What I thought would be easy jobs turned out to be a lot more work because I didn’t do enough IA up front. As the site started coming together, the client kept changing their minds about what they wanted on a particular page.
I’ve realized how important it is to go through that phase and really nail down what a particular page is tying to convey. If you can’t determine that, maybe it shouldn’t be on the site. The concept is so simple, but it’s interesting how often it’s overlooked.
While its clear how important an IA is I find it difficult to delay the design phase, until IA is complete, of any project when working in a small company.
To maintain revenue, and client satisfaction I often have to run them in parallel to a degree. How do you manage to stave off design work and keep those clients happy? So often we’ll confirm an IA and wireframes, yet when the page is designed/built changes are requested.
@Dan: Very true, however they also seem to be the ones that want to bypass the whole IA process and do design. They initially don’t see the value of wireframes and it’s a hard sell to convince them that this is a necessary step in creating a useful site.
@Sam: There is no problem with running IA and design in parallel to some extent. Once IA is far enough along design can get started and changes can be made with little hiccup. That is, if there isn’t a major change in Architecture.
Changes are a part of the the whole process and it’s not uncommon for them to happen late in the design portion or even the build. With a well thought out IA to work from these changes can be less jarring. It’s when pages aren’t thought out that the wheels start to come off.
Kevin,
This is a great post — I’ve ran into far too many projects that haven’t had a strong IA background and have been consequentially run into the ground.
In your opinion as a designer, what’s a good method for a developer such as myself to provide a deliverable to a designer that specifies any complex interactions without limiting the designer’s influence, which wireframes seem to occasionally do? I’ve always felt that wireframes should be one of the last pieces in the IA puzzle and that they should be a collaborative effort between the developer AND the designer after defining another, more basic level of interaction.