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.
That said, I’ve found that there are two scenarios in which Page Description Diagrams might not be the best choice. The first occurs with clients who really don’t want to get involved with anything unless it’s visual. For instance, I recently worked with an architecture firm who told me up front that their group was very visual, and that text-only deliverables weren’t going to enable them to provide valuable feedback. For this client, I chose a more visual-based deliverable.
The second scenario occurs when we’re working with web applications or more interactive-type sites, where discussing interactions is key. Interactions are more difficult to portray textually, so Page Description Diagrams often leave important questions unanswered and aren’t the most appropriate for these types of projects.
Aside from these two examples, Page Description Diagrams are an ideal deliverable—especially for content-heavy sites. They’re a great way for the information architect to focus in on the content and its overall importance per page, rather than visual design and layout only.
If you’re not architecting a site with heavy interactivity, I’d highly recommend them as a great way of getting everyone involved and on the same page during the site building process.
I’m glad you made the point about PDDs being best for websites with a low degree of interactivity, not to mention, lack of emergent content (tags, wiki). When I first used a PDD, I did so on one of these types of sites and it was a frustrating experience with a disappointing outcome. Thankfully, I’ve since learned from my mistake.
@Geoff Harries Yeah, I’ve been there myself. They’re fantastic for content sites but when you start to try and use them for heavy web application type sites there value really starts to drop.
Will you be covering how you approach the IA for interactive sites/ web apps, I’d be interested to hear how you tackle those.
Nice article :)
@Dan Thanks! Yeah, In my next few posts I’ll be talking about how I tackle web applications. There’s definitely not a perfect deliverable out there but I’ve found a few that work well.
Thanks for giving the PDD props - and yes, it’s a deliverable for a certain purpose, but I think it’s pretty useful across the board even if it is never a client-facing deliverable.
There is such a tendency to go straight for the pretty in website design that I find content concerns are easy to lose - and guess what? More often than not, you’re not going to go back and fix them once you’ve started racing along designing fabulous interfaces, so that by the time you develop, you’ve got some icky cleanup work to do that may or may not fit in your design.
Everything is content. If your content fails, your site fails. Even if it’s a snazzy web app. Something I’m working on right now is a process for someone with an IA brain and someone with a visual design brain can work together early on in the process to create an uber-style guide. The bones of the thing. Even if you have low-text, you need to be thinking about what content goes where within the design.
Other deliverables are better for details, and for giving look/feel information, most certainly. But I think giving this stuff consideration early on can save headache later.