<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" media="screen" href="/styles/xslt/rss.xslt"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:c9="http://channel9.msdn.com">
<channel>
	<title>Comment Feed for Channel 9 - A conversation with Bill Buxton about design thinking</title>
	<atom:link rel="self" type="application/rss+xml" href="http://channel9.msdn.com/Shows/Microsoft+Conversations+with+J/A-conversation-with-Bill-Buxton-about-design-thinking/RSS"></atom:link>
	<image>
		<url>http://mschnlnine.vo.llnwd.net/d1/Dev/App_Themes/C9/images/feedimage.png</url>
		<title>Channel 9 - A conversation with Bill Buxton about design thinking</title>
		<link></link>
	</image>
	<description>
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&#39;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&#39;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&#39;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&#39;t. Those things aren&#39;t sketches, they&#39;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&#39;d start with paper prototyping -- quickly hand-rendered versions, and for the pulldown menus and other objects you&#39;d have Post-It notes. So when somebody comes with a pencil and pretends it&#39;s their stylus and they
 click on something, you&#39;ve anticipated the things they&#39;ll do, and you stick down a Post-It note.

What matters here isn&#39;t the interaction between the test subject and the prototype, because it isn&#39;t really a prototype, it&#39;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&#39;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&#39;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&#39;s a combination of techniques, where none is sufficient on its own.

 
Later in the conversation, he challenges some of my favorite themes. Bill&#39;s skeptical about the notion (popularized by Eric von Hippel) that lead users can be co-designers of products. And he doesn&#39;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&#39;ll find a bunch of duplicate songs called
Adagio. In such a case, Bill admits, you&#39;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&#39;t that you should never deploy heavier design artillery, but rather
 that you should reserve it for when it&#39;s absolutely necessary. Much of the time, he believes, sketching is faster, cheaper, and more productive.
 
</description>
	<link></link>
	<language>en</language>
	<pubDate>Mon, 20 May 2013 13:47:20 GMT</pubDate>
	<lastBuildDate>Mon, 20 May 2013 13:47:20 GMT</lastBuildDate>
	<generator>Rev9</generator>
	<item>
		<title>Re: A conversation with Bill Buxton about design thinking</title>
		<description>
			<![CDATA[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. <p>posted by Jsoh</p>]]>
		</description>
		<link>http://channel9.msdn.com/Shows/Microsoft+Conversations+with+J/A-conversation-with-Bill-Buxton-about-design-thinking#c633164241840000000</link>
		<pubDate>Sat, 02 Jun 2007 23:36:24 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Shows/Microsoft+Conversations+with+J/A-conversation-with-Bill-Buxton-about-design-thinking#c633164241840000000</guid>
		<dc:creator>Jsoh</dc:creator>
	</item>
	<item>
		<title>Re: A conversation with Bill Buxton about design thinking</title>
		<description>
			<![CDATA[
<p>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).</p>
<p>&nbsp;</p>
<p>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.</p>
<p>&nbsp;</p>
<p>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.</p>
<p>posted by iknovate</p>]]>
		</description>
		<link>http://channel9.msdn.com/Shows/Microsoft+Conversations+with+J/A-conversation-with-Bill-Buxton-about-design-thinking#c633907089080000000</link>
		<pubDate>Fri, 09 Oct 2009 18:15:08 GMT</pubDate>
		<guid isPermaLink="true">http://channel9.msdn.com/Shows/Microsoft+Conversations+with+J/A-conversation-with-Bill-Buxton-about-design-thinking#c633907089080000000</guid>
		<dc:creator>iknovate</dc:creator>
	</item>
</channel>
</rss>