<?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: Developers and Designers</title>
	<atom:link href="http://www.contenthere.net/2010/02/developers-and-designers.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.contenthere.net/2010/02/developers-and-designers.html</link>
	<description>Enter Content Here</description>
	<lastBuildDate>Wed, 28 Jul 2010 21:53:39 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Martin Aspeli</title>
		<link>http://www.contenthere.net/2010/02/developers-and-designers.html/comment-page-1#comment-2270</link>
		<dc:creator>Martin Aspeli</dc:creator>
		<pubDate>Wed, 10 Feb 2010 11:46:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.contenthere.net/?p=1387#comment-2270</guid>
		<description>In our experience, prototyping using something like Axure is a lot faster, and the tool offers some useful extras, like a way to capture comments and produce something that turns into a functional spec.

It&#039;s also sometimes an advantage that these tools limit the amount of &quot;design&quot; and realism you can achieve: a dumber, obviously throw-away prototype allows the discussion to focus on process flows and functionality, not colours and contours. When you think your prototype is going to be used for the actual build, there&#039;s a temptation to perfect details that are not important for the prototype build, making that phase take longer or focus on the wrong things.

It depends a lot on the team and the project, though. HTML prototyping is certainly a valid approach in a lot of cases.

Martin</description>
		<content:encoded><![CDATA[<p>In our experience, prototyping using something like Axure is a lot faster, and the tool offers some useful extras, like a way to capture comments and produce something that turns into a functional spec.</p>
<p>It&#8217;s also sometimes an advantage that these tools limit the amount of &#8220;design&#8221; and realism you can achieve: a dumber, obviously throw-away prototype allows the discussion to focus on process flows and functionality, not colours and contours. When you think your prototype is going to be used for the actual build, there&#8217;s a temptation to perfect details that are not important for the prototype build, making that phase take longer or focus on the wrong things.</p>
<p>It depends a lot on the team and the project, though. HTML prototyping is certainly a valid approach in a lot of cases.</p>
<p>Martin</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: seth</title>
		<link>http://www.contenthere.net/2010/02/developers-and-designers.html/comment-page-1#comment-2269</link>
		<dc:creator>seth</dc:creator>
		<pubDate>Wed, 10 Feb 2010 11:29:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.contenthere.net/?p=1387#comment-2269</guid>
		<description>I haven&#039;t used Axure but it looks interesting.  My chief concern would be that designers spend a lot of time building a specification in Axure when they could be building DHTML that can be used in the actual application.  Also, in later iterations of the site/product, you will have to keep those Axure specifications up to date.</description>
		<content:encoded><![CDATA[<p>I haven&#8217;t used Axure but it looks interesting.  My chief concern would be that designers spend a lot of time building a specification in Axure when they could be building DHTML that can be used in the actual application.  Also, in later iterations of the site/product, you will have to keep those Axure specifications up to date.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Aspeli</title>
		<link>http://www.contenthere.net/2010/02/developers-and-designers.html/comment-page-1#comment-2250</link>
		<dc:creator>Martin Aspeli</dc:creator>
		<pubDate>Mon, 08 Feb 2010 16:04:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.contenthere.net/?p=1387#comment-2250</guid>
		<description>I&#039;m not sure I believe in &quot;designers&quot; any more than you believe in &quot;casual CMS users&quot;. :)

In the most successful projects I&#039;ve been involved in, we don&#039;t have visual designers. We have user experience designers. They will certainly start in Photoshop to get visual direction from the client. But our designers are all user interface people first and visual designers second. The visual design is driven by a careful analysis of what users actually do with the system, starting from personas and use cases.

The designers also understand how the web works (e.g. the limitations of HTML, cross-browser concerns etc), and how CMS&#039;s work (e.g. the need for content-managed elements to be markup, not images, and the implications for what you can achieve in the design).

The next step from Photoshop is normally UI prototyping, using a tool such as Axure. This is then tested on real users. The idea is to see how the design helps users achieve realistic tasks. For a low-budget alternative, I&#039;ve also used Mockingbird (http://gomockingbird.com)

Once this is complete, the PSD + prototype are turned into an HTML template. I find that having a &quot;plain HTML&quot; template is invaluable. Building anything straight in the CMS tends to cause the design to fall apart in a way that is difficult to counteract. A canonical, cross-browser-tested HTML template gives everyone a common starting point. In many cases, it has also proved useful in other integration work. (In Plone now, we also use tools like XDV or Deliverance which means that applying a plain-HTML template to the CMS is quite easy.)

Of course, the designs and prototypes also become the starting point for more technical implementation work, which is normally specified and prototyped in parallel.

Martin</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure I believe in &#8220;designers&#8221; any more than you believe in &#8220;casual CMS users&#8221;. <img src='http://www.contenthere.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>In the most successful projects I&#8217;ve been involved in, we don&#8217;t have visual designers. We have user experience designers. They will certainly start in Photoshop to get visual direction from the client. But our designers are all user interface people first and visual designers second. The visual design is driven by a careful analysis of what users actually do with the system, starting from personas and use cases.</p>
<p>The designers also understand how the web works (e.g. the limitations of HTML, cross-browser concerns etc), and how CMS&#8217;s work (e.g. the need for content-managed elements to be markup, not images, and the implications for what you can achieve in the design).</p>
<p>The next step from Photoshop is normally UI prototyping, using a tool such as Axure. This is then tested on real users. The idea is to see how the design helps users achieve realistic tasks. For a low-budget alternative, I&#8217;ve also used Mockingbird (<a href="http://gomockingbird.com" rel="nofollow">http://gomockingbird.com</a>)</p>
<p>Once this is complete, the PSD + prototype are turned into an HTML template. I find that having a &#8220;plain HTML&#8221; template is invaluable. Building anything straight in the CMS tends to cause the design to fall apart in a way that is difficult to counteract. A canonical, cross-browser-tested HTML template gives everyone a common starting point. In many cases, it has also proved useful in other integration work. (In Plone now, we also use tools like XDV or Deliverance which means that applying a plain-HTML template to the CMS is quite easy.)</p>
<p>Of course, the designs and prototypes also become the starting point for more technical implementation work, which is normally specified and prototyped in parallel.</p>
<p>Martin</p>
]]></content:encoded>
	</item>
</channel>
</rss>
