don’t knock the whiteboard
Quickly, because I am tired and sleep is more important than these scribblings:
As with most things, I approach documentation from a perspective of appropriateness – I try to match the amount and fidelity of documentation to the problem I’m solving or the concept I’m trying to communicate. I look at design deliverables as a series of cognitive artifacts, representations of all the thinking that’s gone into a particular product or interface.
In other words, I’m a big fan of documenting responsibly. I think it’s necessary and valuable.
So it was with some pleasure that I noticed that Dan had written in defense of documentation this week on the blog. “Right on. We’re not &%*$-ing Kings of Documentation… but we sure as hell recognize what it’s good for and how to do it right.”
There was one thing he said that I disagreed with, tho:
I can sketch all sorts of unbuildable, illogical designs all day on whiteboards, but until I take the time to really write them down in a logical way that communicates the design–and my thinking–clearly, the design is half-baked. Indeed, the documentation crystalizes my thinking, making me think through all the issues and present the solution to them in a way that makes sense–to me and to those who are paying for and building the design.
I don’t put any more faith in a design if it’s built in Graffle than if it’s drawn on a whiteboard. While working with Flickr, Tim and Jeff reinforced the value of our whiteboarding sessions by photographing the screens we mocked up and dropping them into a quick and dirty screen detail template. We could add notations, hilight issues, and give a general idea for context and behavior. It was immediate and raw, and both of those factors worked in its favor.
Like Dan, I fill whiteboards with my ideas. I just don’t agree that a photo of what you mocked up with some notes attached isn’t “real” enough to get the job done.