<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	>
<channel>
	<title>Comments on: Two More Reasons Why Redesigns Suck</title>
	<atom:link href="http://www.scottporad.com/2009/11/11/two-more-reasons-why-redesigns-suck/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.scottporad.com/2009/11/11/two-more-reasons-why-redesigns-suck/</link>
	<description></description>
	<lastBuildDate>Wed, 01 Feb 2012 22:00:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: scottporad</title>
		<link>http://www.scottporad.com/2009/11/11/two-more-reasons-why-redesigns-suck/comment-page-1/#comment-1600</link>
		<dc:creator>scottporad</dc:creator>
		<pubDate>Wed, 26 May 2010 06:32:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottporad.com/?p=1391#comment-1600</guid>
		<description>Kirsten--

In my experience, I&#039;ve rarely seen a &quot;revolutionary&quot; change work.

That being said, I guess the way I would blend big leaps with incrementalism is through a roadmap.

For example, we have some big changes in mind for some parts of Cheezburger, but we&#039;re making them one step at a time and validating them along the way.  We still know the end product we want, and how it&#039;s going to be completely different what we have now, but we&#039;re not leaping there directly.

That being said, I&#039;m reminded of something from high school physics: nature abhors a vacuum.  In other words, there may be times that your product is so bad that you have to throw out what you have (i.e. create a vacuum) in order to allow space for something new and better to flow in.

Of course, most of the time this isn&#039;t what happens.  In my experience, what&#039;s most often needed is incremental improvement, but a redesign is the tool that&#039;s used to get it.  It&#039;s like using a chainsaw to cut an apple.</description>
		<content:encoded><![CDATA[<p>Kirsten&#8211;</p>
<p>In my experience, I&#8217;ve rarely seen a &#8220;revolutionary&#8221; change work.</p>
<p>That being said, I guess the way I would blend big leaps with incrementalism is through a roadmap.</p>
<p>For example, we have some big changes in mind for some parts of Cheezburger, but we&#8217;re making them one step at a time and validating them along the way.  We still know the end product we want, and how it&#8217;s going to be completely different what we have now, but we&#8217;re not leaping there directly.</p>
<p>That being said, I&#8217;m reminded of something from high school physics: nature abhors a vacuum.  In other words, there may be times that your product is so bad that you have to throw out what you have (i.e. create a vacuum) in order to allow space for something new and better to flow in.</p>
<p>Of course, most of the time this isn&#8217;t what happens.  In my experience, what&#8217;s most often needed is incremental improvement, but a redesign is the tool that&#8217;s used to get it.  It&#8217;s like using a chainsaw to cut an apple.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kristen</title>
		<link>http://www.scottporad.com/2009/11/11/two-more-reasons-why-redesigns-suck/comment-page-1/#comment-1482</link>
		<dc:creator>Kristen</dc:creator>
		<pubDate>Sat, 01 May 2010 18:21:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottporad.com/?p=1391#comment-1482</guid>
		<description>Love this - agree it is better for the user - learn quicker, release faster, validate changes. The argument here would be you are always working off of a current state - so changes are truly incremental and not revolutionary. (ie hard to do big swings, do enough to satisfy and kill the pain but not delight) Any thoughts on how to make those big leaps which a re-design implies...while using the mentality of incrementalism?
-Kristen (current Sobcon-er, enjoyed your talk a lot)</description>
		<content:encoded><![CDATA[<p>Love this &#8211; agree it is better for the user &#8211; learn quicker, release faster, validate changes. The argument here would be you are always working off of a current state &#8211; so changes are truly incremental and not revolutionary. (ie hard to do big swings, do enough to satisfy and kill the pain but not delight) Any thoughts on how to make those big leaps which a re-design implies&#8230;while using the mentality of incrementalism?<br />
-Kristen (current Sobcon-er, enjoyed your talk a lot)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: realidealist.net &#124; Good Enough Works Most of the Time</title>
		<link>http://www.scottporad.com/2009/11/11/two-more-reasons-why-redesigns-suck/comment-page-1/#comment-635</link>
		<dc:creator>realidealist.net &#124; Good Enough Works Most of the Time</dc:creator>
		<pubDate>Wed, 11 Nov 2009 18:39:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.scottporad.com/?p=1391#comment-635</guid>
		<description>[...] thank you to Scott Porad&#8217;s recent posts on killing the word &#8220;redesign&#8221; and the follow up. Here are the take home points from each: There is no such thing as redesign; there is only adding [...]</description>
		<content:encoded><![CDATA[<p>[...] thank you to Scott Porad&#8217;s recent posts on killing the word &#8220;redesign&#8221; and the follow up. Here are the take home points from each: There is no such thing as redesign; there is only adding [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

