In the second installment of my Information Architecture Deliverables series, I’m going to talk about one of my favorite (and one of the most tricky) deliverables: the page description diagram. In case you’re not familiar, a page description diagram is a text-based list that explains the importance of content that appears on various pages of a website. Here’s a sample of what one looks like.
One of the main reasons why I love pdd’s is that they effectively remove visual design and layout-based discussions (which should be reserved for the visual design phase of the work) from the IA process. Presenting and discussing only content forces a client to focus on choosing what is and isn’t really important on a given page, helping to communicate their core message.
When I talk about Information Architecture, I don’t want to talk about deliverables. I want to talk about getting people on the same page about what is going to be built or designed. The gist of my job is getting “consensus” (and I don’t mean designing functionality by committee; I mean ensuring that that everyone understands what is going to be built before the development and design happens). Yes, there will always be changes, and yes, agile development can be a great thing. But without some sort of initial blueprint to guide you, the project will flounder around in a visual design and feature development tennis match—on a court without lines or a net. In short, you need a solid plan or you’ll end up with a mess.
So, you need a process for getting people on the same page. In a perfect world a napkin sketch, phone call, and thirty minutes on a write board would be sufficient to give everyone on your project a clear understanding of what’s going to be built, and you’d be ready to move on. But this is a fairy tale. Clearly documenting everything, getting all your stakeholders in the room at once, making time for client feedback, and discussing your work with clients so they see how the site is developing take a lot of time. A whole lot.