<?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: Getting Real with IA</title>
	<atom:link href="http://applestooranges.com/blog/post/getting-real-with-ia/feed/" rel="self" type="application/rss+xml" />
	<link>http://applestooranges.com/blog/post/getting-real-with-ia/</link>
	<description>Writing about design, the user experience, web technologies, and the latest happenings on our online world.</description>
	<pubDate>Sat, 31 Jul 2010 08:53:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: billg</title>
		<link>http://applestooranges.com/blog/post/getting-real-with-ia/comment-page-1/#comment-110</link>
		<dc:creator>billg</dc:creator>
		<pubDate>Sun, 21 May 2006 23:55:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.applestooranges.com/blog/post/getting-real-with-ia/#comment-110</guid>
		<description>&lt;p&gt;"...building the interface first is the best way to come to an agreement with your client about what the software will do and features it will contain."&lt;/p&gt;

&lt;p&gt;Having spent several years at the taxpayers' expense as the government point guy with both the internal client and the contractor building the site, I can second that. People need a frame of reference. Specs don't provide that for them. Looking at the site, even a mockup, does.&lt;/p&gt;

&lt;p&gt;If you just show them the specs, invariably they'll wander off trying to translate what they've, probably, poorly understood into a visual image of the site. Equally invariably, they'll get it wrong. That means the customer thinks you're building a different site than you actually are building. That way lies unhappiness.&lt;/p&gt;

&lt;p&gt;Show them the interface, often and early.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>&#8220;&#8230;building the interface first is the best way to come to an agreement with your client about what the software will do and features it will contain.&#8221;</p>
<p>Having spent several years at the taxpayers&#8217; expense as the government point guy with both the internal client and the contractor building the site, I can second that. People need a frame of reference. Specs don&#8217;t provide that for them. Looking at the site, even a mockup, does.</p>
<p>If you just show them the specs, invariably they&#8217;ll wander off trying to translate what they&#8217;ve, probably, poorly understood into a visual image of the site. Equally invariably, they&#8217;ll get it wrong. That means the customer thinks you&#8217;re building a different site than you actually are building. That way lies unhappiness.</p>
<p>Show them the interface, often and early.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nemrut</title>
		<link>http://applestooranges.com/blog/post/getting-real-with-ia/comment-page-1/#comment-109</link>
		<dc:creator>Nemrut</dc:creator>
		<pubDate>Sun, 21 May 2006 23:54:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.applestooranges.com/blog/post/getting-real-with-ia/#comment-109</guid>
		<description>&lt;p&gt;This can be good way to iterate in small,informal teams but tends to break down for larger projects with multiple stake holders.&lt;/p&gt;

&lt;p&gt;In the latter, it is often more efficient to seperate the content/funtionality/presentation layers in parallel or sequential paths.&lt;/p&gt;

&lt;p&gt;Nemrut&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>This can be good way to iterate in small,informal teams but tends to break down for larger projects with multiple stake holders.</p>
<p>In the latter, it is often more efficient to seperate the content/funtionality/presentation layers in parallel or sequential paths.</p>
<p>Nemrut</p>
]]></content:encoded>
	</item>
</channel>
</rss>
