Page Description Diagrams- Facts and Opinions.

06/23/10 Kristin

We’ve been thinking a lot about Page Description Diagrams lately, and how they might fit into a workflow which frequently interacts with clients. Simply put, we’re fascinated with website planning, and always interested in ways to make Jumpchart better.

From our research, and conversations with those in-the-know, we’ve broken down the concept of a PDD to be a simple text list of items that go on a page ordered by rank of importance. Simply put, you textually describe the element, or feature and then rank it.

Back to the Primer.

Here’s how we phrased it in our previous article:

To make a PDD you can choose any text editor, spreadsheet, or page layout program. You can even use the oh-so-beloved by office workers, Powerpoint if you choose.

You’re shooting for something that looks roughly like this:

Page Description Diagram Example


The columns indicate a general hierarchy level, 1 being of most importance and descending from there. You can stack as many items in a column as you like, but not everything can be a “1.” You can establish your own rules, but I would try for less than three “1s” five “2s” and five “3s.” If you are working on a really large or complex site, it’s possible that you will have more elements, or columns in your plan.

We wanted to know: Do people use them? Have they morphed into more complex formats? Have they been integrated into regular workflows? We’ve talked about PDDs before, what we take away from the concept, and why we think they’re useful. But we wanted to hear it not only from the creator, but from other IA professionals. So we asked Dan Brown himself- and he graciously answered. Here’s how he came up with the idea for page description diagrams in the first place:

“In my original conception, they definitely were meant to replace wireframes. At the time, I positioned wireframes as doing two things:

  • Showing WHAT goes on the page.
  • Showing the RELATIVE PRIORITY of those things.

The layout was a device to communicate priority. The problem is that it communicates other things as well (like what the page looks like). Typography can also be used to communicate priority, but it has “downstream” implications that may cause conflicts later.

Since the job of the wireframe wasn’t to show layout, but instead to show priority, the PDD was a good “pure” form of wireframe.”

It was created as a way to hone in on a more specific aspect of website planning and information architecture.

The Pros and Cons.

The conversation continues: are PDDs useful? And if so, for whom?

We asked for the opinions of three additional IA professionals who have used PDDs in their workflow. Garrett Dimon, designer and developer of Sifter, D. Keith Robinson, user experience expert and designer, and Nick Finck, UX/IA professional, speaker,community cultivator and owner of Blue Flavor, all weighed in on PPDs with us.

After talking with them, we gathered what seems to be the consensus for the pros and cons of PDDs.

Pros

  • They’re flexible and abstract.
  • They’re generally simple to comprehend- anyone can make one.
  • You can provide as much or as little detail as you’d like.
  • They’re easily used in conjunction with wireframes to add depth and context to a deliverable not otherwise easily described.
  • They can be used as a stand-alone document, or as a supplement.
  • They let a designer focus on interaction, content and features.
  • They’re a clear hierarchal prioritized way of thinking about the information and interactions and forcing those to be organized relative to each other while still leaving flexibility for a designer

Cons

  • They’re abstract and simple- sometimes too abstract that the client can’t comprehend them.
  • Sometimes it’s difficult for clients to become engaged in a conversation about them.
  • Can be more effective as just a brainstorming tool.
  • It’s easier for things to get lost in translation when handing it off to a designer unless that designer has a solid understanding of the underlying decisions and principles that guided the thought process.
  • It takes a fairly experienced designer to take PDDs and really create something special from them

The Pros outweigh the Cons, but it would appear the trend is moving away from PPDs. Garrett, D. Keith, Nick  and Dan all admit to using them less in their current workflow.

“Honestly, I’m not really using them any more because I’m full-time on my own application on which I’m the IA, designer, and the developer. So, while I apply a lot of similar concepts, it all happens in my head as it’s a bit of overkill for me to formally put them on paper. I do a lot of sketching and note-taking, but I don’t go to the trouble to formalize or explain my thinking to anyone else,” said Garrett.

Keith uses them when they’re appropriate… but right now he’s the only creative, and he’s not working with clients as much these days.

“There is little reason for me to use deliverables to communicate design decisions to anyone else.  I still use PDDs as an organizational/brainstorming tool, but I don’t create any kind of formal deliverable.  Having said that, I used to use them all the time. I don’t use them much any more, simply because my job function has changed, but have found them really helpful to my process, and more importantly, clients love them.”

Why Not Use Pictures Instead?

One of the aspects of PDDs is that you use words rather than pictures to describe what’s on the page. Dan argues that verbal explanation (and therefore, PDDs) isn’t really necessary because pictures are generally better. In our opinion, while pictures definitely do a better job of illustration, not everyone is capable of drawing well, or illustrating changes over a period of time. Storyboards may work most effectively for those at the top of the profession, but it’s possible those starting out may have a more comfortable time using PDDs to get their points across. Plus, while pictures may offer more detail, textual descriptions might be slightly less mis-leading when presented to the clients.

Moving On.

It seems that even Dan himself is moving away from them- but why? Has technology, IA and website planning evolved into something much more sophisticated? The industry has indeed changed, but there’s more to it than that.

Different job titles require more or less use of PDDs based on the level of involvement, not to mention each project seems to have a mind of its own.

Garrett said, “I think PDD’s can be a great tool, but as with anything, it depends on the project, makeup of the team, and the client’s level of sophistication.”

Nick thinks so, too.

“There is really no such thing as a normal project with a standard process. Every project is different.”

Dan has more of his own reasons for moving on.

“I’ve been using OmniOutliner a LOT as a precursor to the design process. I love making lists and outlines are natural hierarchy communicators. A PDD is really just a bunch of lists, right? So the outline tends to serve the same purpose. There’s nothing special about the outline, but it does give me more flexibility because I’m not even necessarily having to describe what goes on the page. The outline might include additional requirements that don’t easily fit into a PDD.”

Wrapping Up.

Like all other planning methods, PDD’s have their drawbacks, and benefits. When the creator of a concept sees the concept waining in importance, it may be time to move on. But even if PDD’s are obsolete, they’re working towards an important goal that we as an industry need to be concentrating on; the page level description of hierarchy during the planning phase.