<?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: Ignoring Users when Designing</title>
	<atom:link href="http://www.peterpixel.nl/writings/ignoring-users-when-designing/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.peterpixel.nl/writings/ignoring-users-when-designing/</link>
	<description></description>
	<lastBuildDate>Thu, 02 Feb 2012 16:12:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Andrew</title>
		<link>http://www.peterpixel.nl/writings/ignoring-users-when-designing/comment-page-1/#comment-23</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Tue, 20 Mar 2007 20:07:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.peterpixel.nl/writings/?p=15#comment-23</guid>
		<description>I&#039;m afraid to say I don&#039;t agree that &quot;The worst thing you can do though, is design for the client.&quot; At least not entirely.

I would argue that you design for the user to use, and for the owner to own; each set of needs is different and not necessarily incompatible.

I think Dr. Pete said it: the distinction is artificial in practice. A site the user loves but the owner hates will end up removed or defaced in fairly short order.</description>
		<content:encoded><![CDATA[<p>I&#8217;m afraid to say I don&#8217;t agree that &#8220;The worst thing you can do though, is design for the client.&#8221; At least not entirely.</p>
<p>I would argue that you design for the user to use, and for the owner to own; each set of needs is different and not necessarily incompatible.</p>
<p>I think Dr. Pete said it: the distinction is artificial in practice. A site the user loves but the owner hates will end up removed or defaced in fairly short order.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Pete</title>
		<link>http://www.peterpixel.nl/writings/ignoring-users-when-designing/comment-page-1/#comment-21</link>
		<dc:creator>Dr. Pete</dc:creator>
		<pubDate>Tue, 20 Mar 2007 18:48:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.peterpixel.nl/writings/?p=15#comment-21</guid>
		<description>Although I agree with you in theory, it&#039;s a bit different outside of the classroom. Designing for the client isn&#039;t so much something many of us want to do, as it is a necessary part of the client relationship. Since I was a psychologist first and then a businessman, I always work to educate my clients and help them be effective, but it&#039;s their dime at the end of the day, and I can&#039;t build good, effective sites if they stop working with me.

There&#039;s another way to think about it, too. Any specific client exists in a particular industry or domain, and the client knows that domain and its users better than we do. So, doing our job well means compromising between our general knowledge of usability and their domain-specific knowledge. Even with task-based design, you have to know what tasks to anticipate, and it&#039;s usually the client who gets that ball rolling. So, in some ways, the distinction is artificial, at least in practice.</description>
		<content:encoded><![CDATA[<p>Although I agree with you in theory, it&#8217;s a bit different outside of the classroom. Designing for the client isn&#8217;t so much something many of us want to do, as it is a necessary part of the client relationship. Since I was a psychologist first and then a businessman, I always work to educate my clients and help them be effective, but it&#8217;s their dime at the end of the day, and I can&#8217;t build good, effective sites if they stop working with me.</p>
<p>There&#8217;s another way to think about it, too. Any specific client exists in a particular industry or domain, and the client knows that domain and its users better than we do. So, doing our job well means compromising between our general knowledge of usability and their domain-specific knowledge. Even with task-based design, you have to know what tasks to anticipate, and it&#8217;s usually the client who gets that ball rolling. So, in some ways, the distinction is artificial, at least in practice.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

