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.
12 thoughts on “A conversation with Bill Buxton about design thinking”
What do you think of tools that try to blend the informality of sketching with some enhancements like linking? I’m thinking of DENIM, I’m sure there are others out there. http://dub.washington.edu/denim/
I just heard a great podcast in which David Heinemeier Hansson (37signals) talks about why he thinks it’s important to require designers to work in HTML (rather than Photoshop, etc.). The idea is that it’s important to constrain the interface to fit with the medium early in the design process. Of course, he’s talking about building software that will ship this year vs. long range research, like Bill is doing. Interesting listen, anyhow: http://www.hanselminutes.com/default.aspx?showID=82
“What do you think of tools that try to blend the informality of sketching with some enhancements like linking?”
I’ve seen the demo of Denim and I’m much more bullish on that kind of thing than Bill is. At the risk of putting words into his mouth, I’m guessing that — from his point of view as someone who’s used just about every UI sketching and prototyping tool under the sun — he’d reiterate that it’s really hard to outperform pencil and paper. But when he says that, he means that the person using pencil and paper is really competent not only at making hand-drawn sketches, but also at using them to facilitate the dialogue with prospective users which is where the real action is.