Zelnox 13 Apr 05

Is it sort of a cross between a use case and a persona?

Martin 13 Apr 05

Sorry for posting this here, but it looks like you guys have some competition for Ta-Da!:

http://sproutliner.com/

innocent bystander 13 Apr 05

oh man…the to do list wars is mutha fuggin’ ON!

Marc Robichaud 13 Apr 05

Isn’t that like throwing out the baby with the bathwater? All documents practices are a compromise. However, these “Page Description Diagrams” do not fulfill the same functions as a wireframe.

Mathew Patterson 13 Apr 05

The presentation of the ‘diagrams’ is nice, but the content to me looks very much like requirements docs I’ve used in the past. I’m not sure they would replace wireframes, I suppose it depends on who creates the diagrams.

MarkB 13 Apr 05

Of course PDDs fulfill different functions than wireframes — that’s the point. If they did the same thing there wouldn’t be any reason to choose on over the other.

The problem with wireframes is that the value they provide to the IA is completely different than the value the provide to the client. When a client sees a wireframe they see a rough layout (cool! next we get to see pretty colors, right?), while the IA sees a set of prioritized requirements. In order to get the client and the IA talking about the same thing, we push the layout (which actually isn’t a “designed” layout, since the designer isn’t involved yet) back to a separate step. The problem is most apparent later on in the process when the client starts asking about stuff that was “clearly” addressed in the wireframe. And it’s hard to make a client sign-off on a wireframe when the most obvious aspect of the document — the arrangement of things on the screen — is the one thing that that we’re *not* asking for agreement on.

BTW, using a PDD similarly skirts around the issue of labels — usually at this phase the labels are subject to change but in a wireframe we have to put *something*, which causes further discussion about what *not* to pay attention to. With a PDD, features can be described without being labelled.

Dan Boland 13 Apr 05

Sproutliner wastes their heading on a useless �welcome�, and then takes a paragraph of tiny text to explain what the site is about.

And maybe I’m just an idiot, but their “example” looks entirely too convoluted. The winner by knockout is Ta-Da List.

Geof Harries 13 Apr 05

PDDs are very effective tools for communicating to the non-visual thinker who believes all that they see. Clients, at least in my experience, understand content pertaining to their business first and foremost. As several people have pointed out above, this is where presenting wireframes begin to fall apart. We’re asking non-visual thinkers to visualize, and that’s just not a smart way to communicate.

I’ve started using PDDs now instead of wireframes when showing IA comps to clients. The response has been pretty outstanding - they now see the content, the “purpose”, rather than a series of bordered boxes that they assume will end up influencing, or even being, the final design. Makes my job a heck of a lot easier.

geof

One of several Steves 13 Apr 05

I’ve been frustrated many times by exactly this sort of client reaction when it comes to wireframes. To be honest, in some cases, we’ve stopped showing wireframes - or at least a very reduced set - and waited till we get to comps.

I’d have to see client reaction and design/IA response to PDDs firsthand to see if they’re a good alternative. I can see a lot of the same pitfalls, however, with these docs as other forms. If you have clients who are incapable of visualization, you’re always going to have problems with them not totally “getting” what’s in front of them, no matter what doc you use. In fact, PDDs could exaggerate that. I can think of several people I’ve dealt with who would have ignored these had I presented them, precisely because knowing what’s important on the page doesn’t help them “see” the page at all.

Tony 13 Apr 05

Is this somewhat like a functional spec? Is using a PDD not “getting real”?

Berto 13 Apr 05

Isn’t he just pointing out the obvious? You never send wireframes and IA diagrams to clients and non-developers without walking through it with them or without step-by-step documentation. In my experience, clients don’t prefer one or the other, they need both.

8500 13 Apr 05

“Of course PDDs fulfill different functions than wireframes � that�s the point. If they did the same thing there wouldn�t be any reason to choose on over the other. “

Sorry MarkB - don’t mean to pick on you too much but this doesn’t make any sense. The only reason to choose one over the other is *if* they do the same thing. If they are used for different functions then they are not competing and there should be no vs. in the title of this thread.

Personally, I fall into the two different animals camp. I don’t show many wireframes to customers and when I do, I expect them to treat it as a very preliminary mock up. Why do wireframes at all if your not trying to nail down placement of items on a page? PPD seem (at least according to the provided sample) to be a step before wireframes but not a replacement.

Dan H 13 Apr 05

I also thought what Tony I saying here, but finally I came to realize just how not-func-spec-like and “getting real” the PDD is. A functional spec may look kind of similar to the PDD, but a functional spec misses the point that things are flexible. The example PDD we’re given does tell the story of Dirk’s homepage layout, with out simply stating requirements like I figure a bulleted-list func.spec is like.

The key point is the story telling. In doing things the PDD-way, you’re starting a productive dialogue between you and the client you’re proposing the ideas to. In the func spec world, as was mentioned earlier on this blog, they are only items both parties can agree on, but interpret differently. I think that’s the distinction between Func.spec and PDD.

These are all grand ideas. I need to make more time to do this kind of stuff. Thanks everyone. -Dan

PS, sproutliner beta* is hardly competition to ta-da in my opinion, not only is the concept unclear, but it’s messy and more like a shared spreadsheet by my quick evaluation.

PPS, * beta is meaningless anymore. Sigh.

sloan 13 Apr 05

I would think we ALL do PDDs before or while creating wireframes. It is just that some of use write the prioritization down in a list vs. a visual layout. I use PDDs with an overall statement of what the page’s purpose is. A high level of the story of the page, and then get into the details of priortization. Really, a PDD can be part of your final wireframe deliverable with 3 parts: 1) PDD, the story, 2) Wireframes, the layout and 3) Specifications, the interactions. PDDs are a great way to check your layout to make sure it meets its objectives.

Geoffrey 13 Apr 05

I think using “vs.” in the title of this post might be where people are getting confused. And perhaps Keith’s original post presented PDD’s as an alternative to wireframes, when really they are an addition to the Web design process. I think Keith wanted to communicate that PPDs can be a great alternative to what we show clients, but that wireframing will always be a part of the process either way.

Micah 13 Apr 05

For god’s sake…

After almost ten years of listening to IAs debate clients, documentation forms, and upper management problems, I am sick of it. I would hope some of you would have realized that, with a few notable exceptions (JJG, etc.), you have nothing new to contribute that hasn’t already been set forth on a preponderance of listservs and Wikis. So for God’s sake, go sell or do some work, and quit wasting your time surfing blogs for something to critique into the ground.

Micah 13 Apr 05

…and yes, I do see the irony. ;-)

Anusha Perera 13 Apr 05

PDD’s look nice if paired with rough UI comps.
As for the notes section we use DevNotes, which has worked wonders. DevNotes let users/customers add concerns/questions for each wireframe page.

MarkB 13 Apr 05

8500: “The only reason to choose one over the other is *if* they do the same thing”

Sort of… the way we’ve used them in the past, they are trying to accomplish the same *goal* (communicate the page-level requirements from the IA’s work), it’s just that the effect on the client and process is different.

8500: “Why do wireframes at all if your not trying to nail down placement of items on a page? PPD seem (at least according to the provided sample) to be a step before wireframes but not a replacement.”

Yes, exactly. Why should the IA waste time on a layout that’s going to be discarded anyway?

humidhaney 14 Apr 05

we use both at my studio. Actually depends on the client. If they trust us and we trust we know them well we do Wire Frames for our sake. If we need to be clear on every detail with the client we will follow site maps with PDD and then move to the wire frame. All while planning the page structures and content.

then css, flash etc.

Keith 14 Apr 05

First of all, I’d like to thank Micah for elightening all of the designers who are just now getting into this stuff, oh and the people who might be a bit green when it comes to anything Web. Thanks! At least we know what to look forward to…

ANYway. I didn’t really mean my original post to be a “vs” thing. Wireframes can be really useful, but they can also be problematic. As has been said here a few times, PDDs can help set up a wireframe, which can be really helpful. As with everything, it depends and milage may vary. I hope this stuff helps someone out there…

Michael Spina 14 Apr 05

I’ve been using them for some time now. For my clients (small businesses) it’s been working very well.

I try to combine as many visual elements as I can without arranging them in any way other than strict priority, and I’ve been using a top-to-bottom rather than left-to-right layout.

joy gupta 18 Jun 05

need some more documentation

Waris 16 Jan 06

We Offer Low Cost & High Quality Custom Company Logos Design, Corporate Identity Service and Business Stationery Design. Specialize in Cartoon Character Logo Design and Professional Vector Illustration.