Sketching vs. Prototyping: Bill Buxton (was Flash vs. Flex)

26 Jan 2007 - 2:18pm
7 years ago
10 replies
4027 reads
Dave Malouf
2005

http://synapticburn.com/comments.php?id=199_0_1_0_C

A couple of people have asked for more info on Bill Buxton and Sketching.

Bill has written a yet to be published book called "Sketching User
Experience". Some pre-marketing to that book was a presentation to the
Boston ACM-CHI group and Jared Spool had a nice write up that I reference
in the above link.

Enjoy!

-- dave

Comments

26 Jan 2007 - 2:43pm
Josh
2006

It's like a more formalized "paper napkin" approach. I dig it. It's nice to
see someone borrowing methods from other disciplines like the fashion
industry or architecture. And aside from the more formal approach, is it
much different from what we were all doing back in 99 while sitting at
coffee shops? It looks familiar and probably feels just as comfortable.

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.

- Josh Viney

26 Jan 2007 - 5:11pm
Daniel Williams
2005

"In his world, a sketch should communicate how "done" the thinking is.
Rough sketches communicate early thoughts."

I work on Agile projects and use sketching all the time. I sketch with
clients, I sketch with Business Analysts and I sketch with Technical team
members. In fact my final deliverables are usually sketches. as User
Experience people we don't need polished, formalised documents in an agile
environment because the tech guys have been there with us from the start and
know the solution as well as we do (because we have been sketching it with
them), so rough sketches do not have to communicate early thought, they can
communicate enough information to get the completed (and well thought
out) design developed!

On 1/26/07, Jared M. Spool <jspool at uie.com> wrote:
>
>
> 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.
>
> Jared
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

26 Jan 2007 - 5:34pm
Mark Schraad
2006

Every really great designer I have had the opportunity to work with
sketches their ideas out. Most every great thinker I know uses visual
thinking to sort and to explain complex problems and concepts. Visual
thinking is an incredibly powerful tool. Mental visualization
[ though some can do it very well ] going straight to software is not
nearly as powerful.

Mark

On Jan 26, 2007, at 5:11 PM, Dan Williams wrote:

> "In his world, a sketch should communicate how "done" the thinking is.
> Rough sketches communicate early thoughts."
>
>
> I work on Agile projects and use sketching all the time. I sketch with
> clients, I sketch with Business Analysts and I sketch with
> Technical team
> members. In fact my final deliverables are usually sketches. as User
> Experience people we don't need polished, formalised documents in
> an agile
> environment because the tech guys have been there with us from the
> start and
> know the solution as well as we do (because we have been sketching
> it with
> them), so rough sketches do not have to communicate early thought,
> they can
> communicate enough information to get the completed (and well thought
> out) design developed!

26 Jan 2007 - 6:14pm
Jared M. Spool
2003

I'm thinking I wasn't clear. What I meant to say was that rough
sketches communicate that what the viewer is seeing is an early thought.

Rough sketches are different than crudely-drawn diagrams. In fact,
many rough sketches are very well drawn: http://tinyurl.com/2a27ed

Jared

On Jan 26, 2007, at 5:11 PM, Dan Williams wrote:

> "In his world, a sketch should communicate how "done" the thinking is.
> Rough sketches communicate early thoughts."
>
>
> I work on Agile projects and use sketching all the time. I sketch
> with clients, I sketch with Business Analysts and I sketch with
> Technical team members. In fact my final deliverables are usually
> sketches. as User Experience people we don't need polished,
> formalised documents in an agile environment because the tech guys
> have been there with us from the start and know the solution as
> well as we do (because we have been sketching it with them), so
> rough sketches do not have to communicate early thought, they can
> communicate enough information to get the completed (and well
> thought out) design developed!

26 Jan 2007 - 6:19pm
Daniel Williams
2005

"Rough sketches communicate early thoughts"

Maybe I don't understand the above quote, but all I am saying is this is not
always the case. A rough sketch can communicate a fully thought out idea.

On 1/26/07, Jared M. Spool <jspool at uie.com> wrote:
>
> I'm thinking I wasn't clear. What I meant to say was that rough
> sketches communicate that what the viewer is seeing is an early thought.
>
> Rough sketches are different than crudely-drawn diagrams. In fact,
> many rough sketches are very well drawn: http://tinyurl.com/2a27ed
>
> Jared
>
>
> On Jan 26, 2007, at 5:11 PM, Dan Williams wrote:
>
> > "In his world, a sketch should communicate how "done" the thinking is.
> > Rough sketches communicate early thoughts."
> >
> >
> > I work on Agile projects and use sketching all the time. I sketch
> > with clients, I sketch with Business Analysts and I sketch with
> > Technical team members. In fact my final deliverables are usually
> > sketches. as User Experience people we don't need polished,
> > formalised documents in an agile environment because the tech guys
> > have been there with us from the start and know the solution as
> > well as we do (because we have been sketching it with them), so
> > rough sketches do not have to communicate early thought, they can
> > communicate enough information to get the completed (and well
> > thought out) design developed!
>
>

26 Jan 2007 - 6:39pm
Jared M. Spool
2003

Then, in Buxton's world, it's not "rough"

It may be crudely drawn (as opposed to finely drawn with more care
and advanced tools), but if it's fully thought out, it's not a rough.

Jared

On Jan 26, 2007, at 6:19 PM, Dan Williams wrote:

> "Rough sketches communicate early thoughts"
>
> Maybe I don't understand the above quote, but all I am saying is
> this is not always the case. A rough sketch can communicate a fully
> thought out idea.
>
>
>
>
> On 1/26/07, Jared M. Spool <jspool at uie.com> wrote: I'm thinking I
> wasn't clear. What I meant to say was that rough
> sketches communicate that what the viewer is seeing is an early
> thought.
>
> Rough sketches are different than crudely-drawn diagrams. In fact,
> many rough sketches are very well drawn: http://tinyurl.com/2a27ed
>
> Jared
>
>
> On Jan 26, 2007, at 5:11 PM, Dan Williams wrote:
>
> > "In his world, a sketch should communicate how "done" the
> thinking is.
> > Rough sketches communicate early thoughts."
> >
> >
> > I work on Agile projects and use sketching all the time. I sketch
> > with clients, I sketch with Business Analysts and I sketch with
> > Technical team members. In fact my final deliverables are usually
> > sketches. as User Experience people we don't need polished,
> > formalised documents in an agile environment because the tech guys
> > have been there with us from the start and know the solution as
> > well as we do (because we have been sketching it with them), so
> > rough sketches do not have to communicate early thought, they can
> > communicate enough information to get the completed (and well
> > thought out) design developed!
>
>

26 Jan 2007 - 7:47pm
Dave Malouf
2005

Intent to me is the key differentiator, not the tools or mide of
conveyence, or even audience.

The dichotomy of goals that Bull discusses, really strikes a chord with me.

I find that too often the designer in software circles is rushed to deliver
something complete, often in a "first round". There is never any room for
exploration and it is to me exploration that is at the core of sketching.

I do agree that roughness, which comes from handmade work allows for an
"affordance" to a deliverable being understood as a sketch, but there are
other modes of communicating that may be required that can't be done well
in hand.

Dave

...... Original Message .......
On Fri, 26 Jan 2007 18:44:43 -0500 Jack Moffett <jmoffett at inmedius.com>
wrote:
>I think the difference here is in who your audience is.
>
>When showing rough sketches to a customer or management, the purpose
>may be to communicate that it is not a finished design.
>
>But, that does not preclude Dan from using rough sketches to specify
>a UI design for a developer.
>
>Jack
>
>
>On Jan 26, 2007, at 6:19 PM, Dan Williams wrote:
>
>> "Rough sketches communicate early thoughts"
>>
>> Maybe I don't understand the above quote, but all I am saying is
>> this is not
>> always the case. A rough sketch can communicate a fully thought out
>> idea.
>>
>>
>>
>>
>> On 1/26/07, Jared M. Spool <jspool at uie.com> wrote:
>>>
>>> I'm thinking I wasn't clear. What I meant to say was that rough
>>> sketches communicate that what the viewer is seeing is an early
>>> thought.
>>>
>>> Rough sketches are different than crudely-drawn diagrams. In fact,
>>> many rough sketches are very well drawn: http://tinyurl.com/2a27ed
>>>
>>> Jared
>
>
>
>
>Jack L. Moffett
>Interaction Designer
>inmedius
>412.459.0310 x219
>http://www.inmedius.com
>
>
>My goal is to build elegant products.
>The products that don't make people think
>when they should be doing,
>make people think
>when they should be learning,
>compel them by relating to them,
>and simply work.
>
> - Robert Hoekman, Jr.
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://listguide.ixda.org/
>List Help .................. http://listhelp.ixda.org/
>(Un)Subscription Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org
___
David Malouf
dave (at) ixda.org
http://synapticburn.com/
http://ixda.org/

26 Jan 2007 - 8:03pm
Jared M. Spool
2003

On Jan 26, 2007, at 7:47 PM, David Malouf wrote:

> I do agree that roughness, which comes from handmade work allows
> for an
> "affordance" to a deliverable being understood as a sketch, but
> there are
> other modes of communicating that may be required that can't be
> done well
> in hand.

I'm definitely not being clear tonight. :(

Many of the "rough sketches" that Bill showed in his talk were
machine drawn, using CAD programs. They had artifacts (pencil-style
lines and colors, lines through the endpoints, inaccuracies) that
made them appear hand-drawn, but everything was about looking like it
was an early concept versus a finished design.

Think this: http://www.pingmag.jp/images/article/experiencedesign06.jpg

Versus this: http://www.pingmag.jp/images/article/experiencedesign05.jpg

(Borrowed from this great article: http://www.pingmag.jp/2006/05/12/
new-levels-of-experience-design/ )

Jared

26 Jan 2007 - 9:16pm
Jed Wood
2005

One thought that I don't think has been mentioned here yet (sorry if
I missed it). Most of the discussions I see about lo-fi versus hi-fi
prototyping (however you choose to define fidelity :) ) seem to focus
on either time and resources to create, or expectations and
perceptions of how finished and unchangeable the product is.

For me, regardless of the fidelity, there's value in _interactive_
prototypes when you're designing "rich" interfaces full of
transitions. Issues arise and insights are gained during both the
design and testing of these kinds of prototypes that are hard to
derive from paper or even clickable screen-to-screen prototypes
(again, regardless of fidelity).

-Jed

27 Jan 2007 - 9:36pm
dszuc
2005

Good discussion!

If it was good enough for *Da Vinci* - I am sold - "Da Vinci Sketch Hidden
Under Painting" -
http://www.livescience.com/history/ap_050701_da_vinci.html and sketches -
http://tinyurl.com/2zowgk

"The experts believe the artist was planning a picture of the adoration of
the Christ child, but changed his mind."

It seems like its OK to *change your mind* in the design process ;)

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

The Usability Toolkit - http://www.sitepoint.com/books/usability1/

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of David
Malouf
Sent: Saturday, January 27, 2007 8:47 AM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Sketching vs. Prototyping: Bill Buxton (was RE:
Flash vs. Flex)

Intent to me is the key differentiator, not the tools or mide of
conveyence, or even audience.

The dichotomy of goals that Bull discusses, really strikes a chord with me.

I find that too often the designer in software circles is rushed to deliver
something complete, often in a "first round". There is never any room for
exploration and it is to me exploration that is at the core of sketching.

I do agree that roughness, which comes from handmade work allows for an
"affordance" to a deliverable being understood as a sketch, but there are
other modes of communicating that may be required that can't be done well
in hand.

Dave

...... Original Message .......
On Fri, 26 Jan 2007 18:44:43 -0500 Jack Moffett <jmoffett at inmedius.com>
wrote:
>I think the difference here is in who your audience is.
>
>When showing rough sketches to a customer or management, the purpose
>may be to communicate that it is not a finished design.
>
>But, that does not preclude Dan from using rough sketches to specify
>a UI design for a developer.
>
>Jack
>
>
>On Jan 26, 2007, at 6:19 PM, Dan Williams wrote:
>
>> "Rough sketches communicate early thoughts"
>>
>> Maybe I don't understand the above quote, but all I am saying is
>> this is not
>> always the case. A rough sketch can communicate a fully thought out
>> idea.
>>
>>
>>
>>
>> On 1/26/07, Jared M. Spool <jspool at uie.com> wrote:
>>>
>>> I'm thinking I wasn't clear. What I meant to say was that rough
>>> sketches communicate that what the viewer is seeing is an early
>>> thought.
>>>
>>> Rough sketches are different than crudely-drawn diagrams. In fact,
>>> many rough sketches are very well drawn: http://tinyurl.com/2a27ed
>>>
>>> Jared
>
>
>
>
>Jack L. Moffett
>Interaction Designer
>inmedius
>412.459.0310 x219
>http://www.inmedius.com
>
>
>My goal is to build elegant products.
>The products that don't make people think
>when they should be doing,
>make people think
>when they should be learning,
>compel them by relating to them,
>and simply work.
>
> - Robert Hoekman, Jr.
>
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>List Guidelines ............ http://listguide.ixda.org/
>List Help .................. http://listhelp.ixda.org/ (Un)Subscription
>Options ... http://subscription-options.ixda.org/
>Announcements List ......... http://subscribe-announce.ixda.org/
>Questions .................. lists at ixda.org
>Home ....................... http://ixda.org/
>Resource Library ........... http://resources.ixda.org
___
David Malouf
dave (at) ixda.org
http://synapticburn.com/
http://ixda.org/
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/ (Un)Subscription
Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

Syndicate content Get the feed