There seems to be an ongoing debate within our agency on how much time should be spent on information architecture. In retrospect, I think the main reason we previously focused so much time on information architecture was because we needed a client sign off and found it more efficient to make changes in this stage. But what happens when we’re working on one of our own start ups? How should we approach information architecture?
The below snippet is from a 30 page set of wireframes that we provided to Aspen Snowmass when we designed and developed their booking engine user interface. Information architecture was a must for this project because making changes in the development phase would have been extremely inefficient.
37Signals in their Getting Real book, swears by building out the interface first. “Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.”
In some cases, I’m starting to find that the best approach for us is to develop loosely and build out the interface as you adaptively learn the application’s functionality. Every time we’ve focused our energy on user interface it seems to delay the development cycle and I found ourselves unnecessarily changing the UI several times. This approach worked particularly well in the development of DCHistoricTours.com because we had a vision of what we wanted to accomplish but we didn’t know the degree of functionality some of the API’s would provide. In this case, we jumped into development first.
It’s tricky and I don’t think there has to be a standard process. To me it depends on what type of project your working on. Do you have a clear concise idea of what you want or are you unsure?
So with that said, I’m curious to hear what you think on the future of information architecture? Have you had similar experiences? What is your agencies approach? Does it have a set approach? Please comment below.
One Response to “The Future of Information Architecture”
My team and I have found it very difficult to figure out where to start with Information Architecture sometimes. It seems like wireframes should come first and then the design and development, but when the wireframes are constructed there is always overlap. I think a wireframe should just be a semi-graphical, basic document of *everything* that needs to go on every page of the site (form fields, modules, pagination, etc) while tossing the layout to be handled by the designers later on. This way the user experience is still kept very much in mind as modules are planned out, the designers can do what they like, and the wireframes make everything easier for the developers to plan out how they will tackle the code. I think to avoid conflict and make sure all bases are covered, this seems to be the best way to go.
November 17th, 2008 at 12:09 pm