Comments on Coherence, Context, Relevance: Special deliverable #2

christina — Fri, 26 Jan 2007 14:50:19 GMT

http://radio.weblogs.com/0100887/2002/06/13.html#a300

“Where Cooper departs radically from some now-fashionable practices—release early and often, extreme programming—is in his insistence that designs can and must be worked out in essentially complete form on paper, on whiteboards, and in the brains of the designers, over a long period of thoughtful iterative refinement, and then delivered as a complete description of the personas, their goals and tasks, and the required software behavior. In other words, a specification.”

I do believe that drawing aids thought, and produces better designs. How much drawing, which drawings and how to maintain those drawigns are where the interesting questions come in.

adam c — Fri, 26 Jan 2007 14:50:19 GMT

I wholeheartedly agree with the statement that documentation should justify its own existence. Where that statement falls a bit short for me is in the “how.”

I couldn’t be more against deliverables for deliverables’ sake. All too often, I’ve seen IAs create or propose to create long-winded documentation that seems to be more of a justification as to why there is an IA involved in a project rather than mechanisms to move a project forward.

In my opinion, deliverables should be concise and meaningful. In terms of how deliverables can justify their existences, each deliverable, when placed in context of the other should be the end-to-end rationale for every IA decision made.

In my case, a User Needs Assessment combined with a Featuremap begets a Site Map. A Site Map begets Wireframes. Wireframes beget a Prototype and a Prototype is the blueprint for all visual design and coding efforts. Postmortem, a styleguide and final build book are created to detail the decision making process from beginning to end and provide a platform for any future efforts.

7 deliverables and rarely an ounce of wasted effort.

just my $.02

Melvink2 — Fri, 26 Jan 2007 14:50:19 GMT

Hi Christina,

In the company I previously worked in, the system I set up was that all deliverables go through different versions…we track the changes and record them…and update the documents later.

The client is always in the loop of all changes and verifies it.

At the end of the project when it has been launched, we will create the final version of the document.

This is done so that if any problems or queries came out later from anyone, we can always refer back to the deliverables and clarify the query or the problem. It has help us diffuse situations regarding changes to the project.

christina — Fri, 26 Jan 2007 14:50:19 GMT

Aother question (for Dan, and anyone). I liked the comment about documents justifying their existance. What do you think about deliverables that are no longer accurate by the end of design and code. Should they be updated? or tossed? or kept as is as a memento of the hope that was eventualy squashed? or…?

My personal feeling is that while deliverables are blueprints, they are not the final word, and design and engineering will and should make changes as the project matures, and perhaps correcting IA deliverables is a waste of time? Better a final styleguide/spec be made. But maybe others disagree?

dave parker — Fri, 26 Jan 2007 14:50:19 GMT

A question for you, Dan:

In what form do your deliverables usually appear?

I found and printed out some of the documents you had made available somewhere on the Web, and some of them were huge: 36” square or bigger. Did you present these by printing them and hanging them on the wall during a client meeting? Did you have the deliverables in different formats, so they could be seen on the Web or printed and discussed “live”? What is the best format for deliverables, or does it depend?

Thanks.