Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

A conversation with Bill Buxton about design thinking

Download

Right click “Save as…”

  • MP3 (Audio only)

In the latest episode of my Microsoft Conversations series I got together with Bill Buxton to talk about the design philosophy set forth in his new book Sketching User Experiences. Nowadays Bill is a principal researcher with Microsoft Research, and before that he was chief scientist at Alias/Wavefront, but his involvement in the design of software and hardware user interfaces goes all the way back to Xerox PARC. Along the way he's accumulated a fund of wisdom about what he calls design thinking -- a way of producing, illustrating, and winnowing ideas about how products could work.

I haven't yet received my copy of his book, but my background for this conversation was a talk given last November at BostonCHI, the Boston chapter of the ACM's special interest group on computer-human interaction. In that talk (which summarizes key themes from the book), and also in this conversation, Bill lays down core principles for designing effective user experiences.

He proceeds from the assumption that sketching is fundamental to all design activity, and explores what it means to sketch a variety of possible user experiences. His approach is aggressively low-tech and eclectic. He argues that although you can use software tools to create fully-realized interactive mockups, you generally shouldn't. Those things aren't sketches, they're prototypes, and as such they eat up more time, effort, and money than is warranted in the early stages of design. What you want to do instead is produce sketches that are quick, cheap, and disposable.

How would you apply that strategy to the design of, say, the Office ribbon? When Bill talks about sketching, he means it literally:

You'd start with paper prototyping -- quickly hand-rendered versions, and for the pulldown menus and other objects you'd have Post-It notes. So when somebody comes with a pencil and pretends it's their stylus and they click on something, you've anticipated the things they'll do, and you stick down a Post-It note.

What matters here isn't the interaction between the test subject and the prototype, because it isn't really a prototype, it's a sketch. Rather, what matters is the interaction between the test subject and the designer. The sketch need do no more than facilitate that interaction.

Continuing with the same example, here's how an eclectic strategy keeps things simple and cheap:

Now that will give you the flow and the sequence of actions, but it will not give you the dynamics in terms of response time. To show that I'd use exactly the same things, photograph them, and then make a rough pencil-test video so I could play back what I think the timing has to be to show it in realtime. It's a combination of techniques, where none is sufficient on its own.

Later in the conversation, he challenges some of my favorite themes. Bill's skeptical about the notion (popularized by Eric von Hippel) that lead users can be co-designers of products. And he doesn't think that logging interaction data is as useful as I think it is. But he agrees with me that a key weakness of paper prototypes is their inability to incorporate the actual data that animates our experiences of products and services. One of his examples: MP3 players think in terms of songs, not movements, so if you load one with classical music you'll find a bunch of duplicate songs called Adagio. In such a case, Bill admits, you'd like to have used a more fully-realized prototype that could have absorbed real data and flushed out these kinds of problems. His point isn't that you should never deploy heavier design artillery, but rather that you should reserve it for when it's absolutely necessary. Much of the time, he believes, sketching is faster, cheaper, and more productive.

Tag:

Follow the Discussion

  • Joshua RossJoshRoss Niner since 2004
    I like to prototype my user-controls on cocktail napkins. There are a few pinned up on my things-to-do wall. Its a good idea to put your designer hat on and make 3-5 mockups. However, adding the interactivity is a pain. I would like to see something like Blend that would produce a WinForms form or UserControl.
  • iknovateiknovate Rotkä​pchen

    Bill does note that the design of software cannot be inherently separated from the hardware. What he doesn't mention is that the design in this case is really related to the total experience...which is what ALL design must honor (even if it gets more specific along the way).

     

    His response about the ribbon is a classic design FAIL. The problem is (which indeed is still the problem with the ribbon) is that it is still too enmeshed in the concept of the functions that are available rather than what it is that people inherently want to DO most often.

     

    Another example of this is in Tom Kelly's book on innovation at IDEO (The Art of Innovation) where he offers an entire example around how they redesigned a water bottle. Only they failed in their original problem statement which was too 'solution' focused from the beginning: a water bottle. A truly great design problem statement is worded from the lowest-common-denominator perspective: delivering fluids to someone who otherwise has one or more hands unavailable. Had they done that, they would have gotten to the water bladder that much sooner in the marketplace. They did not.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.