Sketching vs. Prototyping: Bill Buxton (was RE: Flash vs. Flex)
26 Jan 2007 - 3:32pm
9 years ago
Jared M. Spool
On Jan 26, 2007, at 2:43 PM, Josh Viney wrote:
> One comment though. This method seems to rely on an an old > assumption that I > feel is becoming less relevant in Web development (also consider > what engine > development has done for the game development world). The > assumption is that > technical development is slow, expensive, and a little mysterious. > Not to > try to sell everyone on Ruby on Rails, but I've been amazed over > the last 7 > months by how quickly my developers can prototype. I've sat in hour > long > meetings with clients and had my developers prototype while we gather > requirements. It allows us to engage all of the stakeholders (clients, > developers, designers, etc.) in a very collaborative/iterative > process where > change requests aren't nearly as scary. We've found that because the > technology isn't as expensive, the real value our developers can > add is in > the creative process.
One of Buxton's key points is this has nothing to do with the expense
of development and implementation.
It has to do with how far you are down the concept => design path.
In his world, a sketch should communicate how "done" the thinking is.
Rough sketches communicate early thoughts.
In his presentation, Buxton showed examples of more final sketches
where the artist added in flourishes ("pencil lines through the
endpoints") just to communicate which parts of the diagram were
"done" and which ones were still conceptual.