<?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: Paper prototyping</title>
	<atom:link href="http://www.bornontheweb.be/2007/06/20/paper-prototyping/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bornontheweb.be/2007/06/20/paper-prototyping/</link>
	<description>The internet is my playground</description>
	<lastBuildDate>Mon, 08 Mar 2010 10:15:04 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Frits</title>
		<link>http://www.bornontheweb.be/2007/06/20/paper-prototyping/comment-page-1/#comment-38808</link>
		<dc:creator>Frits</dc:creator>
		<pubDate>Thu, 21 Jun 2007 17:09:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.bornontheweb.be/2007/06/20/paper-prototyping/#comment-38808</guid>
		<description>Granted, paper prototyping is very simple indeed and mostly useful in the very fist phase of interface design. I wouldn&#039;t recommend it for very big, data-centered applications. For those types of interfaces you&#039;re better of using more advanced prototyping tools that allow you to create refined models and to create html from them.

For small web interfaces or parts of interfaces however it has proven very valuable to me. Working with pen, paper, scissors and glue is an ideal way to create an interface together very fast. People don&#039;t feel restricted to suggest changes because you can easily erase it, throw parts away and begin again. Just last week I was sitting around the table with a product designer, someone who isn&#039;t very web savvy, building an interface for a google maps mash-up. After only five minutes of going through the interface he was suggesting and creating paper screens and dialogs himself. After about half an hour of cutting, drawing and moving pieces of paper together we had drastically improved the flow and had a tangible interface to refer to. We knew how it would behave and what it generally would look like. I kept the prototype and sent him pictures of every screen and dialog. Now he is of making the design and I started coding. In such a case paper prototyping works marvelous and there&#039;s no need to go through the extra work of creating higher fidelity digital models. Try it out for something small, it&#039;s very fun. You&#039;ll feel like you&#039;re in the 2nd grade again :)  

Your suggestions for other tools are very interesting nonetheless. I&#039;ve been looking for prototype tools to use on the mac besides Omnigraffle and didn&#039;t know about &lt;a href=&quot;http://www.simunication.com/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Simunication&lt;/a&gt;.
 I&#039;m checking it out. Thanks for your response.</description>
		<content:encoded><![CDATA[<p>Granted, paper prototyping is very simple indeed and mostly useful in the very fist phase of interface design. I wouldn&#8217;t recommend it for very big, data-centered applications. For those types of interfaces you&#8217;re better of using more advanced prototyping tools that allow you to create refined models and to create html from them.</p>
<p>For small web interfaces or parts of interfaces however it has proven very valuable to me. Working with pen, paper, scissors and glue is an ideal way to create an interface together very fast. People don&#8217;t feel restricted to suggest changes because you can easily erase it, throw parts away and begin again. Just last week I was sitting around the table with a product designer, someone who isn&#8217;t very web savvy, building an interface for a google maps mash-up. After only five minutes of going through the interface he was suggesting and creating paper screens and dialogs himself. After about half an hour of cutting, drawing and moving pieces of paper together we had drastically improved the flow and had a tangible interface to refer to. We knew how it would behave and what it generally would look like. I kept the prototype and sent him pictures of every screen and dialog. Now he is of making the design and I started coding. In such a case paper prototyping works marvelous and there&#8217;s no need to go through the extra work of creating higher fidelity digital models. Try it out for something small, it&#8217;s very fun. You&#8217;ll feel like you&#8217;re in the 2nd grade again :)  </p>
<p>Your suggestions for other tools are very interesting nonetheless. I&#8217;ve been looking for prototype tools to use on the mac besides Omnigraffle and didn&#8217;t know about <a href="http://www.simunication.com/" onclick="javascript:pageTracker._trackPageview('/outbound/comment/www.simunication.com');" target="_blank" rel="nofollow">Simunication</a>.<br />
 I&#8217;m checking it out. Thanks for your response.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Myles Brookin</title>
		<link>http://www.bornontheweb.be/2007/06/20/paper-prototyping/comment-page-1/#comment-38701</link>
		<dc:creator>Myles Brookin</dc:creator>
		<pubDate>Thu, 21 Jun 2007 01:01:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.bornontheweb.be/2007/06/20/paper-prototyping/#comment-38701</guid>
		<description>I&#039;m sorry but I just don&#039;t get it! How can you &quot;test it with users, get feedback from stakeholders and improve it extremely fast early on&quot; unless it is a ridiculously simplistic site or application? Without seeing how it will really look and behave how can the client give meaningful feedback and approval? And just as important, how can dev know what to really build?

Modelling tools that build wireframes, like iRise and Axure, have drawing and behaviour interfaces that capture enough of the look and feel of the website or application, without getting into any actual coding, that the client signs off and the model gets sent to dev, with some idea of the final product.

More robust prototyping products like Simunication let you build prototypes that function like real web apps by using drawing and behaviour interfaces but including the ability to add real code. The simulations are fully functional so clients know exactly what they&#039;re getting, and they can be incubated into final apps.

Finally we get to actual coding with software like PHP, HTML, Ruby On Rails etc. that lets developers spin out prototypes for feedback while building the actual website or app.

Given this spectrum of approaches paper prototyping seems too simple to be useful in a Web 2.0 world.</description>
		<content:encoded><![CDATA[<p>I&#8217;m sorry but I just don&#8217;t get it! How can you &#8220;test it with users, get feedback from stakeholders and improve it extremely fast early on&#8221; unless it is a ridiculously simplistic site or application? Without seeing how it will really look and behave how can the client give meaningful feedback and approval? And just as important, how can dev know what to really build?</p>
<p>Modelling tools that build wireframes, like iRise and Axure, have drawing and behaviour interfaces that capture enough of the look and feel of the website or application, without getting into any actual coding, that the client signs off and the model gets sent to dev, with some idea of the final product.</p>
<p>More robust prototyping products like Simunication let you build prototypes that function like real web apps by using drawing and behaviour interfaces but including the ability to add real code. The simulations are fully functional so clients know exactly what they&#8217;re getting, and they can be incubated into final apps.</p>
<p>Finally we get to actual coding with software like PHP, HTML, Ruby On Rails etc. that lets developers spin out prototypes for feedback while building the actual website or app.</p>
<p>Given this spectrum of approaches paper prototyping seems too simple to be useful in a Web 2.0 world.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
