<?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"
	>
<channel>
	<title>Comments on: Usability Tools Podcast: Inherent Value Tests</title>
	<atom:link href="http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<pubDate>Fri,  9 Jan 2009 03:17:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Alexander</title>
		<link>http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88711</link>
		<dc:creator>Alexander</dc:creator>
		<pubDate>Thu, 20 Sep 2007 16:08:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88711</guid>
		<description>Very helpful answers, thanks Jared!</description>
		<content:encoded><![CDATA[<p>Very helpful answers, thanks Jared!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared Spool</title>
		<link>http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88445</link>
		<dc:creator>Jared Spool</dc:creator>
		<pubDate>Tue, 18 Sep 2007 13:09:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88445</guid>
		<description>Alexander asked a couple of great questions. First:
&lt;blockquote&gt;&lt;em&gt;The point of least astonishment: how do you anticipate how many people will be needed to reach the ‘point of least astonishment’? Knowing this would enable better planning for how many people to recruit!&lt;/em&gt;&lt;/blockquote&gt;
Great question. A few years back, Will Schroeder came up with an algorithmic approach to predicting how many users you need for a study to reach the &lt;em&gt;point of least astonishment&lt;/em&gt;--that point where you no longer are learning anything new from a study.

Basically, you track how much you're learning from each test by quantifying the new things you learn. As you continue to run tests, you should start to see a increase in the amount of redundant things you see and a decrease in the new stuff you learn. If you plot these on a curve, you can extrapolate where the curve will approach the zero point.

The formula is helpful, but has a flaw: you have to run tests to determine how many tests you need to run. What we've found in practice is experienced usability practitioners get a sense as to how many tests will be useful. If you're not sure, you err on the side of too many. If you finish the study thinking you saw new stuff in every session, without any real decrease in the rate the new stuff was coming to you, then you run more tests in the next study. Like anything useful, experience helps you work it out.

&lt;blockquote&gt;&lt;em&gt;For the interview-based tasks in the ZipCar example, it sounds like you basically have them do the same task but you present it differently according to how they expressed themselves in the initial interview. Or, is it totally open and could you have all 6 people in the second group do totally different things?&lt;/em&gt;&lt;/blockquote&gt;

As with all interview-based task techniques, you'll base the range of tasks for your participants on the range of activities that emerge from the interviews. If all your users do essentially the same things, just with their own terms, you won't see a variety in the tasks. If their needs are more diverse, your tasks will be more diverse.

One of the attributes of interview-based tasks is there may be tasks in your study only performed by a single participant. That makes it hard to produce statistics like, &lt;em&gt;"7 out of 10 users completed the registration task."&lt;/em&gt; You don't want to use interview-based tasks if that type of quantification is important to your research.

However, for the purposes of Inherent-Value Testing, quantification is not the primary objective. Instead, we're trying to learn the design's &lt;em&gt;value&lt;/em&gt;, which is a qualitative analysis. So, it's ok if each user performs different tasks.</description>
		<content:encoded><![CDATA[<p>Alexander asked a couple of great questions. First:</p>
<blockquote><p><em>The point of least astonishment: how do you anticipate how many people will be needed to reach the ‘point of least astonishment’? Knowing this would enable better planning for how many people to recruit!</em></p></blockquote>
<p>Great question. A few years back, Will Schroeder came up with an algorithmic approach to predicting how many users you need for a study to reach the <em>point of least astonishment</em>&#8211;that point where you no longer are learning anything new from a study.</p>
<p>Basically, you track how much you&#8217;re learning from each test by quantifying the new things you learn. As you continue to run tests, you should start to see a increase in the amount of redundant things you see and a decrease in the new stuff you learn. If you plot these on a curve, you can extrapolate where the curve will approach the zero point.</p>
<p>The formula is helpful, but has a flaw: you have to run tests to determine how many tests you need to run. What we&#8217;ve found in practice is experienced usability practitioners get a sense as to how many tests will be useful. If you&#8217;re not sure, you err on the side of too many. If you finish the study thinking you saw new stuff in every session, without any real decrease in the rate the new stuff was coming to you, then you run more tests in the next study. Like anything useful, experience helps you work it out.</p>
<blockquote><p><em>For the interview-based tasks in the ZipCar example, it sounds like you basically have them do the same task but you present it differently according to how they expressed themselves in the initial interview. Or, is it totally open and could you have all 6 people in the second group do totally different things?</em></p></blockquote>
<p>As with all interview-based task techniques, you&#8217;ll base the range of tasks for your participants on the range of activities that emerge from the interviews. If all your users do essentially the same things, just with their own terms, you won&#8217;t see a variety in the tasks. If their needs are more diverse, your tasks will be more diverse.</p>
<p>One of the attributes of interview-based tasks is there may be tasks in your study only performed by a single participant. That makes it hard to produce statistics like, <em>&#8220;7 out of 10 users completed the registration task.&#8221;</em> You don&#8217;t want to use interview-based tasks if that type of quantification is important to your research.</p>
<p>However, for the purposes of Inherent-Value Testing, quantification is not the primary objective. Instead, we&#8217;re trying to learn the design&#8217;s <em>value</em>, which is a qualitative analysis. So, it&#8217;s ok if each user performs different tasks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander</title>
		<link>http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88341</link>
		<dc:creator>Alexander</dc:creator>
		<pubDate>Mon, 17 Sep 2007 18:58:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88341</guid>
		<description>For the interview based tasks in the ZipCar example, it sounds like you basically have them do the same task but you present it differently according to how they expressed themselves in the initial interview.  Or, is it totally open and could you have all 6 people in the second group do totally different things?</description>
		<content:encoded><![CDATA[<p>For the interview based tasks in the ZipCar example, it sounds like you basically have them do the same task but you present it differently according to how they expressed themselves in the initial interview.  Or, is it totally open and could you have all 6 people in the second group do totally different things?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexander</title>
		<link>http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88340</link>
		<dc:creator>Alexander</dc:creator>
		<pubDate>Mon, 17 Sep 2007 18:55:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/2007/09/17/usability-tools-podcast-inherent-value-tests/#comment-88340</guid>
		<description>The point of least astonishment: how do you anticipate how many people will be needed to reach the 'point of least astonishment'?  Knowing this would enable better planning for how many people to recruit!</description>
		<content:encoded><![CDATA[<p>The point of least astonishment: how do you anticipate how many people will be needed to reach the &#8216;point of least astonishment&#8217;?  Knowing this would enable better planning for how many people to recruit!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
