I work for a product where the interface is the same way for more than ten years.

I studied some UX techniques like card sorting and I found it would be a good idea to apply it in this product. The problem is that it's a really complicated product, but the clients are using it this way for years so I was wondering when would be the best moment to apply some UX/UI changes. Let's suppose we apply a card sorting and we decide we should regroup some links, moving to another sessions, etc.. Even if this is going to improve usability of the system, it can confuse users that are already familiar with the system (that kind of user that won't read the links, but try to find it where it has always been located). What would you recommend?

3 Answers 3


First and foremost I don't see this as an issue of time, rather than an issue of how to get users to transition from one paradigm of your product to another.

If you plan on revamping the system completely to the point where you feel like users who rely on muscle memory might get lost, you might consider doing a short 30 second - 1 minute tutorial showing them around.

Lots of websites do this when they launch a completely new feature, Facebook being one of the more popular ones. They did this when they launched the Timeline feature and removed people's walls.

You can also consider having helpful tooltips or arrows when the users first come to your new site, pointing to where things are - I've attached a quick sketch of what that might look like. The purple boxes would contain 1-3 sentences about new features and users should be able to close them quickly. enter image description here

  • I also like this approach
    – periback2
    Commented May 29, 2014 at 11:35

The problem is that people hate change. No matter how much nicer you make a UI, there will always be some initial resistance. Many of the big web companies introduce change gradually, switching on new features for a small number of targeted users at a time, starting with the ones they think will benefit the most from the new feature based on their existing usage pattern. In this way they avoid a large immediate backlash.

If this is business software, you could pick a few users in each office / department / company to get the new software first. You can give them extra support in learning the new system, and eventually they can become "champions" of the new way of working (people who don't have it will be curious, and the ones that do have it will love to talk about it).

You should also factor in the possibility that there are some parts of the legacy system that users are using in unanticipated ways. These are essentially "features" that you don't know about, and didn't intend to provide. An example might be a "feature" to get the import format for an excel file by doing an export action when there is no data to export. If you make a new version where you (logically) disable export when there is no data, a lot of users will get upset. The key to countering this type of issue is lots and lots of usability testing to find out how users are actually using the old system. Obtain a list of tasks that users carry out while using the system, and then test you new system with the same list of tasks.

  • Interesting point of view! I hadn't think about it this way, but it's a really good point too
    – periback2
    Commented May 29, 2014 at 11:36
  • @Chris Whether they really hate the changes because they are bad is kind of dificult to seperate out from the circumstances. Will the team / company that created the original UI do a better job with the new one? It's pretty reasonable of the user to assume they won't, and that's the real reason why the 2 year old functional problems are still there. In general though I think users get upset with any change that forces them to go through a learning curve. The larger that learning curve was to begin with (crappy UI), the more negatively they will approach the changes.
    – Franchesca
    Commented Jun 2, 2014 at 11:41
  • "You should also factor in the possibility that there are some parts of the legacy system that users are using in unanticipated ways. These are essentially "features" that you don't know about, and didn't intend to provide" is an excellent point Franchesca. Do you think its the UX designers responsibility to add these features into future iterations of the product? or is it okay for them to leave them as "features" that weren't intended to be provided? Commented Jun 2, 2014 at 17:07
  • 1
    @AnindyaBasu That's a good question! I'm afraid it depends who is paying. If you are making software for your own company (in-house) then you should definitely give the user what they want as a proper feature. If you are a company with a business model based on getting payment for implementing each custom feature? Then it gets tricky, as the users haven't "paid" for the feature from your point of view (implementing it properly will cost you), but from their point of view this "feature" was already delivered in a previous version that they paid for.
    – Franchesca
    Commented Jun 2, 2014 at 20:45

Now is the right time. It is rarely too soon or too late to make life easier for the people who rely on you and your products.

People do adapt to complicated systems, processes, and interfaces. Most people are more comfortable, in the immediate term, when things feel familiar. And as you say, people will often be confused, or even frustrated, if you change something they’re already familiar with. But this doesn’t mean they find those things intuitive and enjoyable to use or follow. If you’re looking to improve the experience for new users and retain users for longer, I strongly recommend taking informed action.

I recommend you conduct a tree test of your existing IA (tree) to find out which labels and hierarchy people find confusing (evil attractors) in a task based context.

After you’ve completed this benchmark tree test, conduct a card sort to find out how users want your content to be organised. You might find it useful to conduct card sorts with both your experienced and inexperienced users, and to investigate any differences.

And then before you restructure the navigation or rewrite the content, I recommend conducting another tree test using a new tree and the same tasks. You can now compare the results of this second tree test to the benchmark test you've already done. Go ahead and iterate your tree until you're happy with the results. This will give you the quantitative data you need to convince those around you that the changes will work.

You need to invest time into discussing the changes with your users. Besides ensuring a worthwhile outcome, involving your customers in this journey will help them understand why you're making the changes and reduce the impact of change resistance for the sake of it. In my experience people usually welcome change when they feel valued.

Conduct in-person user tests after you’ve implemented the changes. What you're looking for here is confirmation that your new IA works in the context of the wider application aesthetic, and with real content. I expect you'll also pick up some useful and subtle ways to help you communicate the changes most effectively.

All the best for your research and design!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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