<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 5 Things People Get Wrong When Talking to Users</title>
	<atom:link href="http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/</link>
	<description>an experience design blog</description>
	<lastBuildDate>Mon, 16 May 2011 06:16:55 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Laura Klein</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-2208</link>
		<dc:creator>Laura Klein</dc:creator>
		<pubDate>Sat, 16 Jan 2010 00:18:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-2208</guid>
		<description>Hi Katie,

Excellent suggestions for recovering from complete participant failure. I do similar things once the user is well and truly lost. I&#039;ve often found that inexperienced moderators err on the side of not letting the user fail for long enough, which is why I was so adamant about not helping out. 

But, of course, you&#039;re right. At some point, the test must go on, and that often includes prompting the participant in various ways. 

On tasks where I expect people might fail or where people have failed in the past, I&#039;ll frequently have a set of prompts that I use in a particular order so that everybody gets the same hints. Then I can figure out how much help people needed on average.</description>
		<content:encoded><![CDATA[<p>Hi Katie,</p>
<p>Excellent suggestions for recovering from complete participant failure. I do similar things once the user is well and truly lost. I&#8217;ve often found that inexperienced moderators err on the side of not letting the user fail for long enough, which is why I was so adamant about not helping out. </p>
<p>But, of course, you&#8217;re right. At some point, the test must go on, and that often includes prompting the participant in various ways. </p>
<p>On tasks where I expect people might fail or where people have failed in the past, I&#8217;ll frequently have a set of prompts that I use in a particular order so that everybody gets the same hints. Then I can figure out how much help people needed on average.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Katie Albers</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-2206</link>
		<dc:creator>Katie Albers</dc:creator>
		<pubDate>Fri, 15 Jan 2010 23:56:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-2206</guid>
		<description>Like you, I&#039;ve observed all these behaviors on the part of new facilitators and I agree with you on all of them, except I have a slightly different take on the last. I let users fail, wait for a while, hint around, then I ask them to narrate the screen to me - right to left and top to bottom - which I find often jogs their minds into an idea they might not have had otherwise, but I believe it&#039;s still important to note that point as a problem and to follow up with them after the task is over about what happened to them there: what did they expect, what did they not understand, etc. Also, in cases where the tester is completely stymied and unable to find a way out, I will take them to the next step. I do that because I now know that there&#039;s a problem at point A (and as in the first instance, I&#039;ll follow up on it later) but I still need the information about where the problems are in the rest of the interaction. This has worked well for me as a method for getting as much information as possible from each test.</description>
		<content:encoded><![CDATA[<p>Like you, I&#8217;ve observed all these behaviors on the part of new facilitators and I agree with you on all of them, except I have a slightly different take on the last. I let users fail, wait for a while, hint around, then I ask them to narrate the screen to me &#8211; right to left and top to bottom &#8211; which I find often jogs their minds into an idea they might not have had otherwise, but I believe it&#8217;s still important to note that point as a problem and to follow up with them after the task is over about what happened to them there: what did they expect, what did they not understand, etc. Also, in cases where the tester is completely stymied and unable to find a way out, I will take them to the next step. I do that because I now know that there&#8217;s a problem at point A (and as in the first instance, I&#8217;ll follow up on it later) but I still need the information about where the problems are in the rest of the interaction. This has worked well for me as a method for getting as much information as possible from each test.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Siherd</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-1428</link>
		<dc:creator>Siherd</dc:creator>
		<pubDate>Thu, 22 Oct 2009 12:35:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-1428</guid>
		<description>Some really good points, thanks, I&#039;ve marked this up for new facilitator to take onboard.
 Another related one about scenarios is about unintentionally leading participants. For example don&#039;t as &quot;how would you find a Christmas gift for your pet dog fido when &quot;gifts for pets&quot; is one of the options presented. Stive to avoid the possibility of users latch onto any words you have used. Sounds obvious but I&#039;ve seen it happen.</description>
		<content:encoded><![CDATA[<p>Some really good points, thanks, I&#8217;ve marked this up for new facilitator to take onboard.<br />
 Another related one about scenarios is about unintentionally leading participants. For example don&#8217;t as &#8220;how would you find a Christmas gift for your pet dog fido when &#8220;gifts for pets&#8221; is one of the options presented. Stive to avoid the possibility of users latch onto any words you have used. Sounds obvious but I&#8217;ve seen it happen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura Klein</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-1043</link>
		<dc:creator>Laura Klein</dc:creator>
		<pubDate>Thu, 17 Sep 2009 17:50:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-1043</guid>
		<description>Thanks, Bill! It&#039;s amazing how hard it is NOT to say anything, isn&#039;t it? When doing with observers in the room, I always need to spend some time with new observers before each session and explain that they must not, under circumstances, grab the mouse from the participant or explain in detail what the person is doing wrong. I learned that the hard way.</description>
		<content:encoded><![CDATA[<p>Thanks, Bill! It&#8217;s amazing how hard it is NOT to say anything, isn&#8217;t it? When doing with observers in the room, I always need to spend some time with new observers before each session and explain that they must not, under circumstances, grab the mouse from the participant or explain in detail what the person is doing wrong. I learned that the hard way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-1040</link>
		<dc:creator>Bill</dc:creator>
		<pubDate>Thu, 17 Sep 2009 15:56:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-1040</guid>
		<description>Keeping my mouth shut was the hardest skill to learn. Next hardest was letting the user fail on his/her own. Good article, Laura. Thanks!</description>
		<content:encoded><![CDATA[<p>Keeping my mouth shut was the hardest skill to learn. Next hardest was letting the user fail on his/her own. Good article, Laura. Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://www.slicedbreaddesign.com/blog/index.php/2009/08/5-things-wrong-when-talking-to-users/comment-page-1/#comment-542</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Wed, 19 Aug 2009 08:53:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.slicedbreaddesign.com/?p=617#comment-542</guid>
		<description>Some &#039;cool&#039; advice here Laura. Thanks :)</description>
		<content:encoded><![CDATA[<p>Some &#8216;cool&#8217; advice here Laura. Thanks <img src='http://www.slicedbreaddesign.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
</channel>
</rss>

