UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 934 January 9, 2013

Re-Introducing Page Description Diagrams

There’s no such thing as a “standard” client or project in a typical agency setting, because every business has its own specific goals—not to mention the goals of its users. Because of this, we’re constantly seeking ways to improve our processes and better meet the needs of our clients, regardless of their unique characteristics.

Recently, we discovered the page description diagram (PDD), a method for documenting components without specifying layout. At first, it seemed limited, even simplistic, relative to our needs. But with some consideration, we began to understand the value. We started looking at whether or not PDDs could help us improve our process.

As it turns out, these things have been around for quite a while. Dan Brown devised them way back in 1999 as a way to communicate information architecture to a client in a way that addressed some of his primary issues with wireframes. Those issues were that, looking at wireframes, clients would form expectations prematurely and that designers would be limited in their innovation by a prescribed layout. Brown’s approach was to remove layout entirely, providing priority instead. Each component of a page would be described in terms of the needs it met and how it met those needs, arranged into three priority columns with wireframe-like examples when necessary. The end result looked something like this or this:

So why haven’t you heard of them? Well, we don’t exactly know. All we do know is that they lost popularity at some point. Kristin at Paste Interactive wrote a great blog post about PDDs in which she asked Dan himself, along with several other professionals, whether they still use page description diagrams. In short: they don’t, but the reasons behind the abandonment don’t seem to have anything to do with the method itself. Somehow, PDDs just dropped out of the public eye.

But to the point, are PDDs useful? We think so, and we’re bringing them back.

Reunion Tour

There are a lot of good reasons to bring something like the PDD back. The reason we keep circling is that while client deliverables can be extremely valuable, you should always let experts deal in their expertise. The client is an expert in their own field and you, as a UX professional, are an expert in information architecture, workflow, and interaction. So why would you ask the client for input on IA, workflow, and interaction when you can ask them about what they actually know? That’s what a page description diagram does, and that’s why we’re using them now.

We put goals and priorities in front of the client for their input, but we keep layout, flow, and design behind the curtain. For a convincing argument that goes into greater detail on the topic, head over to Bold Perspective’s blog post entitled “Professionals Don’t Show Clients Wireframes.”

Don’t Throw the Wireframes out with the Bathwater

It’s important to note that page description diagrams aren’t necessarily a good excuse to do away with wireframes altogether. Many would take the opportunity to claim that actual layout is something to be left to visual designers, but there is still value in having a UX professional help define the spatial structure of a page. There is also an additional level of interpretation needed for a designer to translate a PDD effectively without losing sight of the underlying concept. Since wireframes can mitigate these issues, we can use PDDs and still keep control of the facets that align with our expertise.

We retain UX input into layout and structure by keeping wireframes in the process, but they are for internal use only. We don’t replace the value of wireframing with PDDs, we simply replace the client-facing deliverable with them. This lets us specify layout as needed to craft the flow of information again. We also address the difficulty of communicating UX intent by involving visual designers in the wireframe creation process. Each project starts with a co-design session in which UX and visual design teams collaboratively sketch the beginnings of the wireframe. UX designers retain ownership for flow and usability, but visual designers contribute aesthetics and visual innovation at an early stage.

The New Process

The end result is a process that protects our design workflow from armchair advice while involving the client in a way that makes sense: show clients a page description diagram, and then develop wireframes to communicate and collaborate internally with design. We don’t have to explain to a client what a wireframe is and we don’t have to deal with endless attempts to revise colors and other irrelevant details in the wireframes. Perhaps best of all, we still get to put something in front of the client to make sure we’re on the right track. Since the features on a PDD are incorporated directly, our clients still experience buy-in and a sense of ownership when we reveal the homepage design. Overall, there are a lot of wins here.

The primary sacrifice in removing wireframes from the client deliverables is that any major layout revisions have to be made to the production-quality layout. This takes longer than bumping around wireframe components, but is mitigated by the lack of wireframe revisions and the option to choose more efficient methods of communicating layout internally, such as sketches.

What We’ve Learned

Not surprisingly, we encountered several issues when we introduced PDDs into our process. Overall, however, we believe that our process has been enhanced by the method.

Maintain Clear Priorities

One of the first things we learned is that we needed to standardize definitions for what made an element high, medium, or low priority. These priorities are key to both defining the layout of the elements and encoding the users’ needs, so they need to be both consistent and clear. We came up with the following definitions:

  • High Priority: These features are vital to a user’s understanding of the fundamental concept and goals of the site.
  • Medium Priority: The site should include these features to function well and provide for the majority of a user’s needs.
  • Low Priority: These features are useful, but not vital to the user’s operation or understanding of the site.

Without these definitions, the “high priority” column may be filled with “always there” page elements such as logos, navigation, and footers. But this doesn’t speak to the actual importance of these elements. The priorities of a site should be organized by how important they are to accomplishing the user’s goals, not by the mere expectation that they should be on the site.

To explain this, we sometimes use a car analogy. An example of a high priority item is the engine—without it, the car simply fails to function. A medium priority item would be seats—you could ride in the car without them, but the experience suffers. Low priority items would be cup holders or a sunroof, which complete the car, but are effectively optional. By this metric, the logos, navigation, and footers, though ever-present, should be medium priority items: important to the experience, but technically non-vital to the primary goal of establishing identity and directing the user to a product or service. High-priority items are more likely to include identity messaging and calls-to-action, and low-priority items might be news, social media, and newsletter signup.

Create One Diagram Per Page

It is important to focus on one PDD for each page. Home pages will likely require the most effort, so we have found it helpful to complete this diagram first. Some of the features that are initially brainstormed for the homepage may overflow into or be repeated on sub-pages.

In our experience, PDDs are also helpful for second-level pages since they are often used to provide an overview of the content in their section, but lower-level pages are usually more repetitive and content-heavy, making a PDD less valuable.

Leverage PDDs for Mobile-First Design

PDDs work very nicely with mobile-first and responsive design techniques, as well. When designing for mobile, you can use your PDD to easily prioritize content; sometimes that can be as simple as flowing most elements down the page in order of priority. Later, when you design checkpoints for other devices, you can refer to your PDD again for guidance on the size, positioning, and visual weight of page elements.

Keep Them Digital

Paper and sticky notes are great ways to start your PDD, but building a digital version in Microsoft Word or your favorite wireframing tool makes it much easier to share. If you don’t have time to type it up by hand, you can at least take a picture of your paper version and send it to everyone.

We recommend creating a template in your tool of choice, but if you use Balsamiq Mockups, we have created a template that you can download here.

Create Them Collaboratively

Perhaps the most important thing we have learned is that PDDs cannot be built in a silo by one information architect. Gathering input from stakeholders and the rest of your team will yield a shared sense of ownership and a more robust set of features than going it alone.

Conclusion

If you’re having trouble with clients engaging too little about what matters (goals and priorities) and too much with what doesn’t (“Can you add some whitespace between those buttons?”), consider using page description diagrams. With them, you’ll find it easier to prioritize features of your website design and increase buy-in for project team members while also reducing the need to show clients wireframes. It has worked very well for us so far.

 

Image of colorful pyramid courtesy Shutterstock.

ABOUT THE AUTHOR(S)

User Profile

Colin Butler is a graduate of North Carolina State University with an MS in Human-Computer Interaction. He believes that the key to creating a good user experience is good communication and process, but a little cleverness has been known to make a good experience into a great one.

 

User Profile

Andrew Wirtanen is a Lead Product Designer for Citrix and 2013 President of the Triangle UXPA. He is a graduate of Bentley University with an MS in Human Factors in Information Design. He has experience with many usability engineering and interaction design methods. Prior to joining Citrix in 2013, he worked in consulting environments for six years.

Add new comment

Comments

44
53

Dara: We did make an assumption there--mostly based on the lack of discussion surrounding them. Glad to hear you still use them!

Bob: Thanks for the comment! Yes, PDDs are very similar to page tables. In fact, I often use a priority list (similar to page tables) for sub-pages. PDDs simply tend to add more detail, including a sketch when it's useful.

41
54

Great read. I would be careful in making the assumption that people have stopped using PDDs. I use the constantly in my process. It is a wonderful way to get client agreement on the information that will be on the page. More importantly, I can had it off to my production ux/vx designers so that they can easily understand the goals of the page and design from there.

43
54

Great read. Thanks for reintroducing page description diagrams. We were originally intrigued with the idea by way of Kristina Halvorson's Page Tables (Content Strategy for The Web, Halvorson, 2010). I'm interested in revisiting this type of tool, and considering its introduction into our workflow.

50
47

Mathew: Storyboards, flow diagrams, and site maps/outlines are good tools for IA and PDDs help refine that broader view into the context of actual implemented pages, but we found that wireframes are still useful for fulfilling the interaction design component of the process. Adding a PDD can actually free the visual designer from the prescribed layout provided by a wireframe by giving him/her the information that supports the decisions made in that layout. If your designer has a differing idea on how something could or should be presented, he/she can review that idea against the rationale encoded in the PDD to see if it's an equally effective solution.

I agree with you that the ideal arrangement is definitely close collaboration throughout the process without strict boundaries between teams, but some people work in companies that don't follow a model like that and there's nothing that can be done to fix that completely. We just found that PDDs help bridge the client-to-UX-to-visual-design path more smoothly when you do have to deal with departmental boundaries.

45
52

I've not tried using PDDs for several years after a few failed attempts of bringing them into our internal process. To set the background, this was an agency situation where stakeholders would work with the IA (me) who would then work with visual designers.

Admittedly, I don't recall every using PDDs as a communication/collaboration tool with stakeholders. Instead I'd focus more on understanding critical user flows (storyboards/flow diagrams are great here since you focus on tasks that people complete rather than 'pages') and scope (asking stakeholders to do a constrained card sort by picking 12 features is a great group technique).

For me PDDs were more a tool that I hoped would help visual designers work without being biased towards the layout they saw on the wireframe. Unfortunately I discovered this put too much stress on my design team (which admittedly had a lot of work to get through) especially when I would return with feedback on items that had different priorities, but were related to each other so needed to be chunked somehow.

A lot of the time, I feel these tools are created to communicate ideas in teams set up in a division-of-labour model (e.g. research, design, develop, test etc) which in my mind are a false economy. My best work has been done when I'm paired with an excellent visual designer and we work end-to-end throughout the full process.

44
46

Actually, Jon W, your second point is somewhat obviated by a novel approach to creating PDDs that involves collaborating with stakeholders from the very start. There may be another article soon on how to create PDDs in a workshop setting, so stay tuned.

46
48

PDDs are a fantastic tool for getting stakeholder buy-in on content, functionality and hierarchy before you invest days in generating wireframes. Their fast to create and easy for non-tech, non-design people to grasp. We've found Keynote or PowerPoint (gasp!) to be great tools for creating them as 1) it lets you skip a step and go straight from creating to presenting and 2) sometimes you need to let clients sit with them for a while and share internally, and PPT is perfect for that.

45
59

I used to make "wireframes" on a similar methodology, where I used a 4:2:1 scale of UI element size to establish importance, but, as you noted, this starts to build expectations. Organizing it this way makes a lot of sense.

45
59

I've definitely found this to be a useful concept, even when when not passing it over as a deliverable to someone else. It's a nice way to lay out all the parts before figuring out how to put them together. Nishant Kothary wrote on a similar concept a few years back, which is what got me started: http://visitmix.com/Articles/The-Future-of-Wireframes

48
52

Thank you for breaking it down. This will definitely help working with clients.