IA with content or IA with code?
September 20, 2005 at 3:00 PM
Garrett Dimon has posted a great article about Information Architecture as part of his series on redesigning his site step by step (also see Getting Our Act Together). One thing about the new article is it talks a lot about page description diagrams which are an interesting way to do IA shorthand. While this technique works well I have heard other IAs going the other direction and taking IA closer doing HTML wireframes or even programming. Which do you prefer and why?
You and I have talked about this a bit already offline and you know I'm a fan of PDDs, but I think it really depends on the project. IA, much like anything else we do, needs to be adaptable to the project. PDDs do some things very well: * They provide guidance without dictating form and design. * They provide clients with an idea of the direction without giving them any preconceived notions of what the pages are going to look like. * They allow you to expand on nuances and details via a narrative, sometimes providing much needed details, again without dictating form. They're not actually "shorthand" wireframes at all. They are simply a different deliverable. One that is in narrative form as opposed to visual. I like the idea of HTML wireframes, or prototypes also. It can save lots of time and also lay a road map for not only your designer, but your developer as well. Another benefit is showing more complex interaction -- like AJAX enabled pages. Then again a PDD is good for that as well, given it's narrative and can describe, with words, an interaction. I guess I didn't answer your question. I don't prefer one of these to another. As a designer I don't really like wireframes "traditional" or HTML as they don't leave as much room for creativity. They tend to lead the form a bit too much. Also, they can sometimes create problems with clients who confuse them with mockups. They live in that very fuzzy line between IA and Design. However, they can also be very helpful. It also depends how they're done. As far as programming goes? Heck, I'd love to learn to program.
I too do both (and static wireframes as well). I use page description diagrams when I'm working on a site that will be more heavily visual or experiential than content-rich, when part of my role is to identify what should be included, but perhaps not so much where things will be. I do static wireframes for most regular content-rich sites, when working with a team where someone else will develop the site and where it is important for me to communicate about the wireframes (lots of good annotations). I do XHTML wireframes when I have more time, when doing my own work, or when working on a smaller site that I will ultimately build (not that I do many of these). I'll probably do them more often as I become faster at them. Maybe one day I'll learn to program. Or maybe I'll stick with knowing lots of other stuff that no-one else knows ;)
For years I had a process of site-map, wireframe, mock-up, test and deliver. What I found was that too often clients would get hung up on the visual aspect of the wireframe and wanted that shape for the actual visual layer. Also too often the importance of each element became skewed. So now I do the PDD and then only wireframe navigation. Then provide several creative mockups. Clients seem very happy with this process. Several have commented that they had never before considered what information was truly valuable. I believe this process yeilds a better visual design, a clearer information architecture and a more functional site. jds