Page Description Diagrams
April 04, 2005 | 
21 Comments
Summary: A quick overview of Page Description Diagrams and how I use them.
Since I got back from SXSW and our well received Design Eye for The Idea Guy panel I’ve received quite a few e-mails asking about my use of page description diagrams and how they fit into the design process.
For those of you who are unfamiliar with page description diagrams you can see an example (PDF) over at the Design Eye site.
They are, in essence, a text-only alternative to wireframes. I first heard of their use in an article by Dan Brown for B&A. If you’re interested in some background, it’d be a good idea to start there.
Wireframes can be problematic.
If you’ve shown wireframes to more than a few clients or stakeholders you probably know what I’m talking about. No matter how hard we try, no matter how much we say, “don’t pay too much attention to the design,” clients can’t help themselves. Place a wireframe in front of a stakeholder and they will forever-more have some sort of pre-conceived notion of your design. They’ll “thin-slice” it.
As well, if you’re working on a team with multiple designers, or a designer and an information architect, a wireframe can unintentionally stunt the creativity of everyone involved by leading the design down a part that might not be the best. If nothing else this can lead to a bunch of “samey” designs.
Now, I’m not totally against wireframes. If you look at what Ryan eventually came up with for the Idea Guy, it was great and followed closely the wireframe. However, particularly with clients, they can be taken a bit too literally.
Page Description Diagrams to the rescue!
A narrative can be used to solve this issue. What a Page Description Diagram attempts to do is tell the story (Ah, storytelling, on of my favorite topics of late) of the page, and lay out its design goals—without actually showing the form of the page—thus allowing for the creativity of the designer. A wireframe can still be created, informed by the information contained in the Page Description Diagram, but at this point it’s closer to the design.
You might be thinking that many clients would have a hard time moving forward with just the textual description of the page, but I’ve found that this is not the case. Now, I’ve not been using them to too terribly long, but so far everyone I’ve used them with has understood the reasoning behind them and found them very helpful.
They actually give the client, and the designer, much more detailed information about the form and function of the page than most wireframes do. Couple them with a wireframe (for the designers use only) and you’ve got some great background information you can base design decisions upon.
How are Page Description Diagrams created?
They’re actually pretty simple and can take multiple forms. I use a format very similar to the one described by Dan in his article. For most projects I create one for each kind of page (homepage, index page, content page, etc.) and I break them down to four columns:
- High priority - Things that are essential to the page.
- Middle priority - Things that are suggested for the page.
- Low priority - Thing that would be good, but aren’t needed on the page.
- Goals and overview information - Some general information about the function and goals for the page.
What I do, using the information I’ve got about the project, its users, goals and limitations, is arrange and prioritize the different types of content (images, text, logo, search, what-have-you) into those groups and give a short textual description or small illustration of each. This gives the client (or the designer) a clear idea of what is most important for each particular page and provides the information needed to inform the design and move the project forward.
Of course, the format for a Page Description Diagram is only limited by your creativity.
I’ve found them to be very helpful in my design process, even if it’s just me. When I do a Page Description Diagram it not only provides me with a document to inform my design moving forward, but helps me think creatively about the goals and needs of the project.
If nothing else, they’re just another nice tool to add to the toolbox.
Filed under: IA and Usability
Comments
1. Sanj said:
I hate to belittle the work you’ve done - but I really don’t see any special value in these ‘page description diagrams’.
To me they simply look like requirements (requirement / description / priority)- something that’s more efficiently done in MS Word with a table and three columns.
Pretty soon a page will be called ‘White Rectangular Region’.
Posted on April 4, 2005 07:51 PM | #
2. Keith said:
Sanj – There is no reason you couldn’t do these in Word. However I’ve found that the quality of the actual deliverable makes a big difference in getting clients to pay attention.
Posted on April 4, 2005 08:00 PM | #
3. Michael Wilson said:
I’ve had the opposite experience with wireframes. Perhaps our idea of a wireframe’s core purpose differs, which could account for some of the difference in experiences, but I find them to be a most helpful tool for getting a site on track quickly. All of my wireframes include a flavor of what you call “page descriptions”, but rather than detailing only content and content position on a particular page, my wireframes detail functionality and processes and contain exactly zero graphical elements. I only include information about the page’s functionality, goals, exits (links to other pages or processes), and any server side processing or business logic that needs to be addressed. By completely eliminating all graphical elements from the wireframe, the client is forced to focus on the tool’s purpose—defining functionality. I don’t have to tell the client to ignore the design, because there is no design presented. Rather than presenting an article page with a series of faux headlines, publication dates, and lead in teasers, I provide a simple paragraph that explains what the page will contain—headlines, publication dates, and lead in teasers—followed by an explanation of what happens when the user interacts with the various page elements.
I find this approach helps my clients to understand the processes that take place on a particular page or within a series of pages such as a multi-page form submission and further helps to identify any issues in those processes that need to be addressed or corrected. I rarely get a “sorry, but we missed this” or ““this doesn’t work right” email or phone call when I’m almost finished with the prototype.
If you are talking about using wireframes only for simple blog-like or client-side only functionality, I agree that their usefulness is somewhat limited and simple page descriptions may work just as well. For more complex sites or enterprise applications, a description of where a certain chunk of content resides on the page or how important that content may be is far less useful to the development team and the client than a sharp understanding of how the page or site functions (what happens when a user clicks this?) and what goals we will be helping users to achieve (How does a user accomplish this task?). Once I have the functionality under my belt, I begin layout and design, which starts with simple positioning (your idea of page descriptions in a quasi-graphical format) and evolves into more defined branding and presentation. After final designs (usually Photoshop or Illustrator mockups) are approved, I develop and test the HTML prototype, which is a fully functional (minus server side logic and processing) site with dummy content. At this point, if minimal server side programming or processing is required, the site is 90% complete and real content is added to finish it off. If more programming and database work is required, we have a completely templeted framework to which we can add any dynamic processes or a tiered framework.
I suppose allot of the benefits to either approach depends on the complexity level of the project, the type of client, and the extent to which functionality reigns over form.
Posted on April 4, 2005 08:43 PM | #
4. Sally Carson said:
Keith, what I really like about these Page Description Diagrams is that the content is prioritized. I have found that when using wireframes it’s often the case that layout choices are made without ever discussing what elements on the page should get the most visual prominence, so the design decisions can be somewhat arbitrary.
I think some non-designers might not realize how deliberate we can be with what the users notice first, second, third, or not at all, so they think constructing wireframes is just a game of paper Tetris.
I’ve been in a situation where the entire site has been redesigned by committee, I’ve had no involvement in those discussions, and I’ve just been handed a stack of wireframes and asked to flesh them out. I think going into something like this with no background information is such a mistake, Page Description Diagrams would have really helped.
Posted on April 5, 2005 06:12 AM | #
5. Tom said:
Hmm.. I tend to agree more with Sanj here. I see your point Keith… but I know my stakeholders will look at this document and say “we’ve seen the requirements already…” and they want something they can visualize. I realize their visualization is the problem… but nevertheless - I think it’s up to us to manage that.
I can see this being a useful tool for a designer for sure. But I think it is hard for a non-design type person to work with something so abstract.
Have you used this in a real production pipeline? I’d be interested to know if you did, how it fared.
Posted on April 5, 2005 06:52 AM | #
6. Jason said:
I actually like this idea a lot. I think if you limit each area to a set # of items, you can force the business owners to really think about what’s actually important, rather than going with the mindset that “it’s all important”.
I think this falls between the “requirements” and “wireframes” steps and could alleviate a lot of headaches. Thanks!
Posted on April 5, 2005 07:50 AM | #
7. CM Harrington said:
I think this idea goes a long way to deal with how to properly annotate a wireframe. That said, in your above scenario, you’re dealing with a very simple website. Most of the websites I architect are actually full-blown applications that happen to have a web interface. The wireframe must exist to show every element on the page, and its importance (through the use of size and placement).
My clients would flip out (alas) if they were only handed the annotation portion of the document. That’s why I appreciate the point you (Keith) make, in that this is a piece of the whole, not the total sum. The irony being that my clients still flip out when I show them a wireframe. In my latest project, most of the errata are copy/label changes. Not really something that should matter in a detailed wireframe.
One last point. I would suggest putting the wireframe on half of a tabloid/A3, and the page description/annotations on the other half. That way, you are making a direct association between the object and its definition.
Posted on April 5, 2005 08:07 AM | #
8. Keith said:
Tom – we’ve used these with every project I’ve worked on at PBDH. And they’ve fared very well, as I said in the post. They’re supposed to be more useful to the designer than the client, but we’ve found that they do work well for the client also. The thing is they are a one piece of many, and we’ve used them in conjunction with wireframes many times.
As Sally (#4) mentioned, these can be much more helpful than a wireframe only.
Wireframes have always been problematic. If nothing else you can use PDDs to set up a wireframe.
Also, it’s important to note that we don’t skip from these PDDs straight to a finished design. We’ve got several rounds of design in between. We take the requirements from the PDDs (which the client has bought-off on) and use those to do wireframes and visual design options.
One more thing – in my example we’re dealing with a very simple Web site, BUT, and this is a HUGE but (that’s kind of silly), most of the real projects we work on are much more complicated.
PDDs can scale to fit just about anything. They don’t need to be “page oriented” at all and could be used to describe flows, forms, whatever you want.
It’s all about using prose, or storytelling, to help explain a process, a page or whatever.
Posted on April 5, 2005 08:41 AM | #
9. Kevin Tamura said:
Well written Keith. I have been moving in this direction for my own work for the last several months and introducing it here at e&a. I’ve found that it’s very similar to the methodolgie I would use to design posters.
As for wireframes being troublesome, I couldn’t agree more. For designers you feel locked into a way something should be and for clients, well they just don’t get them. Page describtions are much more tangable and useful for all.
Posted on April 5, 2005 09:33 AM | #
10. Elaine Nelson said:
I was showing this to my assistant, and he remarked that it would really well with the greyscreen prototyping that we’ve been using for site development (not applications so much), especially in places where the content provided by the client is still pretty thin.
Client vs. Developer Wars is a good piece that describes the prototyping process. We’ve been using it for almost a year now, and it makes a huge difference in keeping our clients focused, and also in saving ourselves work that the project isn’t “ready” for.
Thanks for sharing…that goes for all the other commenters too!
Posted on April 5, 2005 10:24 AM | #
11. CM Harrington said:
Keith,
You’ve hit it It�€™s all about using prose, or storytelling, to help explain a process, a page or whatever.. Using full sentences and complete thoughts will only lead to clarity. Frustration comes from interpretation of a bullet point, or phrase. Edward Tufte has gone on ad nauseam about exactly that point, and I agree with you both.
What really frustrates me is when I get blasted for trying to do just that. Clients are so very used to the dumbed-down PowerPoint-view that they get scared when they actually have to read. The end result (for said bad clients) usually means a compromised project. Luckily, some clients are beginning to see the value of an up-front approach to Information Architecture.
Posted on April 5, 2005 10:44 AM | #
12. Geoffrey said:
The key to the success of the PDD is the idea of being literal. As Keith mentioned, the storytelling. A wireframe will typically have a box with the word “content” in it. Or big dense slab of Lorem Ipsum. This doesn’t do anything to help the designer visualize what the content is, nor does it do anything to inspire the client to think of the content as anything other than filler.
A sentence with a subject and a verb can do wonders, and in this age of bullet-points, can also be quite refreshing. Use them in tandem with a wireframe and you have the start of a very useful blueprint.
Sanj: If you have ever tried to present to a roomful of clients, you will find that presentation itself is just as important as the concept. The content of the PDD Keith has linked to could easily be done in Word, but I doubt it will have the same effect.
Posted on April 5, 2005 10:23 PM | #
13. Dan said:
A page description diagram does not describe the requirements of a system, but the design of a system. Requirements shouldn’t look like (or smell like, or feel like) a page description diagram, because requirements must describe what the system does *independent of design*.
In other words, requirements shouldn’t be expressed in terms of pages or content areas. Requirements say what needs to be done and design documents (like PDDs, wireframes, and comps) say how to do it.
Although I devised PDDs years ago, I’m finding new ways they’re better than wireframes. Livia Labate brings up a good point about how wireframes are the result of a design process. Like her, I’m frequently frustrated when they’re used as a requirements elicitation process. Proper requirements elicitation is usually glossed over, and we jump straight to wireframes.
Avoiding this is preferable, but if unavoidable, it’s much easier to make changes to a PDD (which, as someone pointed out, is just columns of text) than a wireframe.
One last comment: this was a technique I invented to address a number of issues I was facing. I agree that some circumstances do not call for such drastic measures. If wireframes (or some other deliverble) work for you, go with it.
Posted on April 6, 2005 06:45 AM | #
14. Christian Watson said:
What the heck has Word got to do with anything? Sanj, are you trying to say that Keith’s presentation of the PDD is too professional-looking?
You could easily create a document that looks the same as Keith’s in Word (hmmm, I feel a template coming on - ah, if only I had the time), so I’m not sure why the medium used to present the PDD would matter.
I think PDDs provide a great middle ground between requirements documents and wireframes - the former can be too abstract and the latter too design-constricting.
I agree with Keith’s point about the potential for wireframes to restrict design choices, no matter how general you make them. PDDs seem like a good step before wireframes, particularly when you’re developing highly visible pages like the home and hub pages which will have a lot of competing priorities.
Thanks for the tip, Keith, this one’s a keeper.
Posted on April 6, 2005 11:38 AM | #
15. Adam Michela said:
I’ve been doing this for awhile, although in not such a well structured way.
I typically grab my Moleskine, listing out everything each page should do, starring key items, sometimes writing unimportant items in small text.
Fast way to do a similar thing. Although I never thought much about what I was actually doing.
Thanks for this structure! This can really help improve my process. Better, it gives me something I can use to show other people (clients/partners) versus my personal notes that go into how I mockup my design.
Posted on April 6, 2005 12:17 PM | #
16. Nicole Ramsey said:
I’ve been using Ryan Singer’s An Introduction to Using Patterns in Web Design concepts successfully for awhile and I think PDD is a great idea to incorporate in the design process.
Posted on April 6, 2005 04:07 PM | #
17. Marko said:
Full sentences should clear things out for the designers and development team. Once established and approved, the concept should be pretty easy to remember and associative for everyone in the team.
From my experience there were times when site specs listed in pure bulleted list tend to be misinterpreted after a while, or misunderstood in the first place. This spends too much valuable working hours.
Wireframes are on the other hand two-dimensional in most cases, not giving the clear explanation of the epicenter of the page, not telling the story, emotions or message that should be delivered. Also, wireframes are kind of limitations for designers, which sometimes lead to frustration.
Keith, what’s you experience about designers and information architects constructing and sketching wireframes together?
Posted on April 6, 2005 11:23 PM | #
18. metafeather said:
Glad to find a full discourse on PDDs +/- Wireframes I can refer my PM’s too.
I’d like to add that one of the most useful aspects of a PDD I have found is that the text based content allows for easier collaboration than that of a graphical wireframe.
We use a wiki template for the PDD layout, and links between PDD pages for the control flow (sometimes with a overview flow control wiki page), allowing team members to easily reflect changes in requirements and other functional related decisions.
The PDDs can then not only feed the Visual Design process, but also provide a (virtual) paper prototype of the site functionality, from which coding tasks can be derived.
Currently its not perfect, but it has served us much better than the creation of separate monolithic documents in a rapid development environment, and provides a lot of transparency to the management of the project about the impact of decisions.
Posted on April 10, 2005 04:18 PM | #
19. Iva Koberg said:
We have been doing PDDs (though we call them “live storyboards”, or more precisely - I’d consider them the first stage of our “live storyboards”) for a while and have had much success with clients for these main reasons:
What we do differently is that we use our CMS, so we can iteratively develop these into an evolving storyboard with structured, semantic markup, add styling, develop the content into the actual content, add functional components… until these rought descriptions of pages become the actual finished site.
While I agree that PDDs as described in this post can be a useful additional tool, the risk is that you may end up with yet another set of documents (especially if you do these in something like Word and circulate in emails) that need to be updated as the project evolves. Keith mentioned developing wireframes for designers at a later stage - wouldn’t time be wasted if you have to update PDDs for a client, wireframes for designers? In addition, PDDs let you communicate the site structure, navigation elements and perhaps how pages are linked contextually - why have to redo all that later rather than use these as a foundation to add to?
Posted on April 14, 2005 06:17 AM | #
20. Jamin said:
“Keith mentioned developing wireframes for designers at a later stage - wouldn’t time be wasted if you have to update PDDs for a client, wireframes for designers?”
I have recently experimented with bringing PDDs into my team’s process, in addition to the HTML wireframes we typically create. And Iva’s question above came into full light.
I created a PDD and then built the wireframe. There were then changes to the PDD based on client feedback. While talking to the designer about the PDD I found myself explaining that the new changes were not incorporated into the wireframes yet. And then I started to wonder if I helped the process or created more work for myself.
Posted on April 14, 2005 12:02 PM | #
21. Nils T. Devine said:
Since I was at exactly the right phase in the pre-design process when you posted this I took the idea and ran with it. Here’s what I ended up with for the home page of an author’s personal site:
http://www.divinentd.com/pdd.html
Two noteable updates:
Thanks for pointing out this technique!
Posted on April 15, 2005 12:45 PM | #
Comments are now closed