Re-design a fascinating opinion

Lou Rosenfeld presented a fascinating talk at the London UX 2011 conference titled Redesign Must Die.  Obviously this is quite a contentious heading for a talk presented to people who make their living from redesign.  He primarily presented the University of Michigan's website and its extremely regular redesign strategy.  Essentially asserting that the redesigns seemed limitless and a waste of money...

Now one element that has always generally irked me when design projects for customers is that I have always felt they do not understand the potential for the software.  Actually more precisely it is not the customer's narrow vision, but more the sales/management idea that this should be so rigidly adhered to.  Essentially the customer will ask for exactly what they have already only incrementally improved, the famous quote attributed to Ford sums it up "If I had asked the consumers they would have told me they wanted faster horse...".  So when Lou talks of avoiding redesign it certainly reminds me of this incremental improvement approach.

This is not to say that an incremental approach does not have some great benefits.


look it's version 2.0, runs 30% faster and is a bit shiner...


The good thing about incremental enhancement as opposed to more radical redesign strategies is that it is almost impossible to anger your existing customers.  Simply improving performance, tweaking readability and minor graphic refreshes are unlikely to get anyone worked up and make the customer feel they are getting a better product. Also minor changes are unlikely to lead to bugs, unexpected usabilty issues, deadlines are easier to keep, the list is long enough to make it appealing.

The problem with this is if you work in such a fashion a new competitor can seemingly overnight produce a dramatically superior product.  If your current design cannot cope with this new paradigm then the catch up phase can be significant, especially if your technological base has stagnated.  This new paradigm might require features your older platform simply cannot cope with, attempting to re-work your current designs could be very costly and a redesign to anticipate this type of problem could have saved the product.

I believe the relatively well known recent history of Nokia and Apple demonstrates this issue, I perhaps could also point to Facebook and Friendster, but lets focus on Nokia and Apple initially.  While Nokia were incrementally improving their phones adding a few megapixels here and there Apple came a long with a relatively new concept which was so superior that the switch to iPhones has been massive.  Nokia's UI had so many significant problems that the new Apple UX was impossible to compete with.

Collectively I suspect that these systemic problems could have been dealt with inside Nokia in a collaborative fashion, but reports of lack of coordination between the hardware and software teams, and the range of markets they were aiming at and a lack of willingness to abandon their current software and either move to an alternative or redevelop their own lead to their endeavor collectively failing.

Nokia's sales and marketing teams drove the incremental changes, because that is what they thought the customers wanted, that's what the surveys said, but sales showed what they really wanted was an iPhone.

Now if you are following this argument then you may be thinking, but hang on the iPhone exhibits the same behavior, iPhone 3G, 3GS, 4, they are all incremental improvements.  This is where the "Redesign Must Die!" aspect kicks in, if your interface is fundamentally correct then you should not redesign it.  Imagine Google moving its search box top right, bottom left, top left every month, fundamentally placing the search box front and center is what people want and expect.  If each version of a product you have to relearn the layout and functionality then it is frustrating and you will not continue to use it when a replacement is available.

But the same argument is apparent in that if the UX is fundamentally flawed then you really need to redesign as early as possible to assist users in "un-learning" the incorrect behaviors.

If you are a real master like Apple you can even use your advertising to teach users about the new features and how to use them, so that when changes do come a long users are not only are they anticipated the learning curve is removed allowing the user to appreciate the benefits of the redesign rather than complain asking for the old design just faster and shiner.  As far as I am concerned these training adverts are a marketing master stroke, and while they may not be the first to do these, they do manage it much more elegantly than most.

Perhaps for clarity I should add that there have been some significant changes in iOS which shows Apple's willingness to redesign.  Although the OS looks relatively unchanged over the years, the modifications to allow elements of multi-tasking were vital to the company realistically competing with Android.

Additionally I feel the the Redesign must die talk was about aiming to correct systemic problems and avoiding change for the sake of change.  Having worked in software for a few years now I know that this is very tempting.  Customers will not easily notice under-the-hood changes, they may not be certain to spot efficiency improvements, but alter the icons and the application will definitely feel new.  Fiddling with the layout sometimes is necessary to convince a customer there are genuine improvements, to allow the customer to reinspect the application with new eyes and not assume all the same issues are in this new software.

Redesign is at its best when it is addressing problems with the current design, no application is perfect, there is always scope for improvement, whether incremental improvement or complete redesign is warranted should be something the designer can access, but it is unlikely that a sales department or "average" customer will be able to initiate such a process.

Comments

Popular posts from this blog

IE9 Intranet compatibility mode in Intranet websites

User Interface Usability Checklist Part 2

Procedural VS Object Oriented