39

We've taken over a legacy web application that has been running without anything changed for the past 4 years.

We are currently re-writing the application because the original source code has severe problems that make it easier to just "throw it out". The rewrite will be based on components from a very similar web property and thus:

The layout will be completely changed. Some deprecated features will be removed and all other existing functionality will re-implemented but may work slightly different that what's there right now. No major changes in workflow. The change will encapsulate some copy changes to reflect that we have taken over the property.

We're of two minds as to whether this transition is too major to do from one day to other with regards to user experience (browsing the website today and seeing what's been seen for the last 4 years and the next day seeing something completely different) and whether it's a good idea to "ease" users into it somehow.

Are there examples of such major successful migrations of large web properties? What can we learn towards this dilemma? Any other suggestions from experience?

Improve this question
5
  • Generally speaking, a gradual change as described in most answers below is preferable. However, a lot depends on your user base. How many users are affected, and what is their technical proficiency? Some types of users love new stuff, others will complain.
    – Wonko the Sane
    Apr 9, 2013 at 17:31
  • Well, everybody will be affected. I don't anticipate that many users will be technically proficient - meaning that they probably know their way around the Internet but are not really "power users". Most of them will be highly-educated however.
    – georgiosd
    Apr 10, 2013 at 9:04
  • That makes sense. I was just trying to get a feel of what "everybody" means - 5 people, 500 people?
    – Wonko the Sane
    Apr 10, 2013 at 13:01
  • Oh, sorry. We get about 500 visits a day but I was told that only about 1/5 are repeat users.
    – georgiosd
    Apr 10, 2013 at 15:46
  • Fair enough - a gradual change is probably best. I just wanted to raise the question for you, and for anybody who finds this discussion in a search.
    – Wonko the Sane
    Apr 10, 2013 at 21:10

5 Answers 5

Reset to default
46

I would advise keeping the designs separate, but providing a staged release. Trying to create an intermediary design will simply double your workload as a designer, and provide minimal benefits as users will incur the costs of re-orienting themselves twice rather than once.

A staged release would comprise three parts:

During the beta stage, users can move from the old version of the application to the new one. These will be motivated users who are interested, and so providing opportunities for them to give feedback will likely work well - you may even get the opportunity to invite user testing participants for free. Unmotivated users will be aware that things are changing.

During the trial stage, users will start at the new version, but move to the old version at will (or when they need to access a page that is not supported by the current interface). Tracking movements from new to old and watching the bounce rates of new pages will give you clues as to issues with your current UI. Consider using a splash page that features links to the new locations of the most common content and actions on your old site.

Finally, at the release stage, the old application is switched off. Users who try to reach the old app via bookmarks are taken to the new version of the page, perhaps with a banner describing the changes (with links to help material).

Improve this answer
9
  • 7
    We recently did what the OP describes. I wish that we had followed the advise here!
    – Ryan
    Apr 9, 2013 at 16:13
  • yes - this empowers the users that are so minded; engages those that are interested; makes users feel special by being invited to trial something and offer feedback; makes the users feel smarter and reduces risk of users feeling stupid (like it's their fault they can't do something)
    – Roger Attrill
    Apr 9, 2013 at 18:20
  • Hm... I guess this is the point where the definition of "design" becomes very important. I'm guessing you're talking about the look and feel too and mostly about the user experience - as in where they will find their "stuff". The problem is that because the system is so old and we'll be using current technologies to re-write it, it will be hard to keep the feel and even look of the existing site. We should be able to keep most of the navigation experience. Thoughts?
    – georgiosd
    Apr 10, 2013 at 9:08
  • @georgiosd "I would advise keeping the designs separate", so in other words, if I interpret it correctly, there's no need to keep the feel and even look of the existing site in the new version.
    – Svish
    Apr 10, 2013 at 11:04
  • So effectively you're suggesting giving it the same look and feel as much as possible while we're upgrading to new technologies and gradually change it to a new design if necessary.
    – georgiosd
    Apr 10, 2013 at 11:09
7

Users hate when you change things beyond their control. To prepare them for change, make it look like something special.

In Designing for Emotion, Aarron Walter shows how the key to preparing users for a site overhaul is to make sure that your beta release is private and that the users invited to it have been (or at least appear to have been) chosen based on their involvement with the site.

This exclusivity has the dual benefit of:

  1. making users who have been invited to upgrade early feel a part of an exclusive group, thus building their brand loyalty.
  2. making users who have not yet been invited excited by what they hear from people who have been upgraded.

A great example of this is the roll-out of the New Twitter, where users who had been upgraded early began bragging about the new features and tagging their tweets with #NewTwitter. According to Walter:

the limited access created a velvet rope effect that had a powerful emotional influence. Users who were granted early access felt a sense of exclusivity and elevated status, which was heightened when they tweeted about it and received longing @replies from their followers.

Improve this answer
6
  • 2
    From (among others) whattodonext.com.au/do-people-really-hate-change: "Look at all the things people do. We travel, we start hobbies, we renovate and redecorate. We read self-help books, go to gyms, change our look, our bodies and even our names. We switch careers, we retrain, we start businesses. [...] We change just about everything, all the time. We like change… we just don’t like having it done to us. Give us a genuine opportunity to have some authorship in what’s going on and we’ll lead the way." The lesson is in the last part.
    – Koen Lageveen
    Apr 9, 2013 at 17:07
  • @KoenLageveen True. Users do love changing things, but they hate having their things changed. The OP was asking about how to change their things in a way that the users would not object.
    – Graham Herrli
    Apr 9, 2013 at 19:15
  • I was just responding to your statement that "users hate change". I hear that too often, and it's not constructive and I think we agree it is not true. Like you say, people like changing things. Which means the key to having people accept a change you want to make, is to make them feel like they're active players in the change. So, I absolutely agree with your suggestion, it is a proven strategy, but I just think the initial statement needed some nuance.
    – Koen Lageveen
    Apr 9, 2013 at 19:51
  • @KoenLageveen Interesting point. I've changed the first sentence to take your feedback into account.
    – Graham Herrli
    Apr 9, 2013 at 19:58
  • 1
    Cool. +1 for bringing in a new approach :)
    – Koen Lageveen
    Apr 9, 2013 at 20:00
4

Since you are throwing away the entire (old) code, the usual approach of small changes is not applicable in your case.

What you can do is get the users excited for the change.

  • Use a header display or overlay whenever the user arrives at website saying that we will soon be changing the design. Make it something which resonates with your audience "Get ready for disruption! 4/4/13", or "We are getting a face lift!" or something of the sort

  • Get your users involved in the process. Ask for their expert opinions on what stuff should be changed, etc. You are getting user feedback, prepping them for the change and getting them excited to see the changes.

  • Introduce everyone to the new layout. You can have a temporary video or something which can help people understand/relate to the new layout. Compare the old vs the new and stress on how the new is MUCH better. You can have a "take a tour" button or use a temporary welcome overlay for the same.

Improve this answer
1
  • +1 for understanding that small changes will not be feasible. Good suggestions, thank you.
    – georgiosd
    Apr 10, 2013 at 9:14
4

Other's have given good advice, so just a minor addition here.

If you can't do a gradual change, get your users involved, let them feel like they're taken seriously and that they've contributed to the change. Hopefully you'll get a few enthusiasts to evangelize about how great it all will be.

Also read this: http://www.uie.com/articles/radical_redesign, which discusses what seems to be exactly your problem and a number of options available.

Improve this answer
1
1

The Normally Recommended Approach

If you can figure out how to do this over time and unobtrusively, go with that. The concept comes from evolution - minor mutations, strung out over time, cause the organism to be better suited to the environment. Abrupt and large-scale mutations in one generation can kill the organism or an entire generation.

The split I can see from your description of the problem would be to try and do as much of the "controller" code changes, without dramatically changing the UI. You can start slipping in changes to the UI with forewarning messages to your users of the nature: That thing that used to be "here" is now over "here". Give it a few weeks/months to sink in. And just keep doing it that way.

Depending on the size of your user-base and the types of users you have - probably a good way to go. If you don't actually have a lot of users...may be not as necessary. (Think about when Facebook makes a change - no matter how small - there seem to be all sorts of people freaking out about it but, in the grand scheme, it's only a small percentage of the user-base...and they usually get over it; but the changes are relatively small. "We moved the logout link.")

The Not Usually Recommended Approach

Just change everything and make some videos and communications about how much better the new way will be - we promise. This happened when Microsoft switched to the Ribbon. Before the release I believe they spent about a year preparing people for it (or at least trying). "It's gonna be great..." "We studied users..." And so on. Generally, an abrupt and overarching change will result in possible loss in user-base; however, if you are already losing users, you might win them back (Fridays restaurant, for a current, as of this writing, example).

I've said it before around here, but I hate being that guy who says, "It depends" - but, it depends. If you're already losing users and some of the dramatic changes you are planning address the majority those user's concerns - market the heck out of the changes you're going to be releasing in short order. If your user-base is pretty steady and there aren't a lot of complaints - go slow - if it ain't broke (from a user's perspective), don't fix it (at least not all at once).

Improve this answer
1
  • Thanks for illustrating cases where the unconventional approach has worked. And of course "it depends" :)
    – georgiosd
    Apr 10, 2013 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.