Two More Reasons Why Redesigns Suck
I was so amped after yesterday’s post about redesigns, that I decided to write another. So, here’s two more reasons why I want web site redesigns to die:
1. The HiPPO
Big redesigns inevitably require reviews and approvals up the chain of command. What does that mean? It means that people who do not have detailed knowledge of the problem, and who are probably not domain experts, are inevitably giving their input on the redesign.
This happens, typically, by reviewing Photoshopped mockups, and 99% of this input is pure garbage…it’s opinion and conjecture. It’s all about The HiPPO—The Highest Paid Person’s Opinion—and usually that’s the opinion that holds the greatest influence, even if the person doesn’t know anything.
2. Collateral Damage
A big redesign typically means making all sorts of big moves and changes. The result is that all sorts of unnecessary little changes that happen to accommodate the big ones. Each of these changes is a door that leads to a little opportunity for someone to make a completely unnecessary change that is not even remotely based on user need.
You know what? All of these little changes cost time to develop, rarely are beneficial, and often harmful. To me, it’s like that that old adage, “throwing the baby out with the bath water”.
In other words, redesigns have collateral damage. When you drop the redesign bomb, some civilians inevitably get hurt.
What’s the solution to this problem?
Stop with big redesigns, it’s just that easy. Simply eliminate the concept from your project vocabulary. Replace the notion with incremental changes that directly benefit your users, and that can be measured for effectiveness.
This approach won’t be as sexy as a “site redesign”, but I’m confident that the results will be better.
[...] thank you to Scott Porad’s recent posts on killing the word “redesign” and the follow up. Here are the take home points from each: There is no such thing as redesign; there is only adding [...]
realidealist.net | Good Enough Works Most of the Time
11 Nov 09 at 10:39 am
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)
Kristen
1 May 10 at 11:21 am
Kirsten–
In my experience, I’ve rarely seen a “revolutionary” 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’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’s going to be completely different what we have now, but we’re not leaping there directly.
That being said, I’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’t what happens. In my experience, what’s most often needed is incremental improvement, but a redesign is the tool that’s used to get it. It’s like using a chainsaw to cut an apple.
scottporad
25 May 10 at 11:32 pm