<?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: Pattern Based Sketching</title>
	<atom:link href="http://wireframes.linowski.ca/2009/05/pattern-based-sketching/feed/" rel="self" type="application/rss+xml" />
	<link>http://wireframes.linowski.ca/2009/05/pattern-based-sketching/</link>
	<description>Because every IA has something funky up their sleeve</description>
	<lastBuildDate>Wed, 28 Jul 2010 06:45:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Jakub Linowski</title>
		<link>http://wireframes.linowski.ca/2009/05/pattern-based-sketching/comment-page-1/#comment-1777</link>
		<dc:creator>Jakub Linowski</dc:creator>
		<pubDate>Fri, 05 Jun 2009 15:23:47 +0000</pubDate>
		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=908#comment-1777</guid>
		<description>Hi Robert, 
 
Abstracting design criteria sounds interesting. Would you care to submit a few samples of that over to me?  :)  </description>
		<content:encoded><![CDATA[<p>Hi Robert, </p>
<p>Abstracting design criteria sounds interesting. Would you care to submit a few samples of that over to me?  :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Hoekman, Jr.</title>
		<link>http://wireframes.linowski.ca/2009/05/pattern-based-sketching/comment-page-1/#comment-1546</link>
		<dc:creator>Robert Hoekman, Jr.</dc:creator>
		<pubDate>Sat, 23 May 2009 01:42:43 +0000</pubDate>
		<guid isPermaLink="false">http://wireframes.linowski.ca/?p=908#comment-1546</guid>
		<description>Along these lines, it&#039;s extremely helpful to write a list of design criteria, which are rules for a design &#8212; statements about the motivation behind the design that address what it needs to achieve for users and how it needs to work. The key is to focus your energy on the why and how rather than the what. 
 
For example, I recently worked on the design of a Likert scale survey that was to include over 100 questions. I knew I wanted to avoid the obvious solution, which is a single page containing all the questions, listed alongside their accompanying radio button sets, because that would be remarkably demotivating and tedious. In my list of design criteria, I wrote, among other things, that the design should involve minimal mouse movement, should feel fast even if it wasn&#039;t actually fast, and should motivate the user to keep moving forward. As a result, I designed a solution in which the questions rotated into position to move to where the user&#039;s mouse already was instead of making the user move his mouse to the question; I used a color scale for the set of answer buttons (green = strongly agree &gt; red = strongly disagree) so users don&#039;t have to memorize the order of the answers; and I showed just the next two upcoming questions so that users could stay motivated. (Of course, I also provided a way to change a previous answer.) 
 
By getting away from the specifics and writing design criteria, I&#039;m able to focus on the rationale behind a design and come up with better ways of achieving it rather than relying on standards. </description>
		<content:encoded><![CDATA[<p>Along these lines, it&#039;s extremely helpful to write a list of design criteria, which are rules for a design &mdash; statements about the motivation behind the design that address what it needs to achieve for users and how it needs to work. The key is to focus your energy on the why and how rather than the what. </p>
<p>For example, I recently worked on the design of a Likert scale survey that was to include over 100 questions. I knew I wanted to avoid the obvious solution, which is a single page containing all the questions, listed alongside their accompanying radio button sets, because that would be remarkably demotivating and tedious. In my list of design criteria, I wrote, among other things, that the design should involve minimal mouse movement, should feel fast even if it wasn&#039;t actually fast, and should motivate the user to keep moving forward. As a result, I designed a solution in which the questions rotated into position to move to where the user&#039;s mouse already was instead of making the user move his mouse to the question; I used a color scale for the set of answer buttons (green = strongly agree &gt; red = strongly disagree) so users don&#039;t have to memorize the order of the answers; and I showed just the next two upcoming questions so that users could stay motivated. (Of course, I also provided a way to change a previous answer.) </p>
<p>By getting away from the specifics and writing design criteria, I&#039;m able to focus on the rationale behind a design and come up with better ways of achieving it rather than relying on standards.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
