8

I keep coming across this situation and was hoping someone would have more information on this:

We have an existing product and I have been requested to "make something work better", so I start by considering what the flow/screen should do and looking at existing design patterns for the functionality. I Come up with a wireframe of how the user flow/screen can be represented and show to the stakeholders. Most people agree that the changes are improving the experience but then someone raises the issue:

"what about existing users of the product they will now be presented with a new screen and it wont make sense to them."

Now ideally I would suggest testing it with some users, but when this isn't possible I have provided evidence that the approach I have taken uses existing patterns that are common in web applications, so therefore users should be able to understand how to use them.

So I was wondering can you think of anything else I can do? Or do people think we shouldn't change things as it will effect existing users too much?

Improve this question

4 Answers 4

Reset to default
9

When it comes to existing products and users, I tend to be in the 'Tweak, don't redesign' camp.

By that I mean that instead of redesigning in such a way as to possibly alienate existing users, instead break down the planned improvements into a series of standalone changes. Then look at what you might consider to be tweaks - the simplest changes that might solve a problem or improve the experience of most people. Determine benefit over cost (+risk).

Tweaks have the benefit that goes with smaller scale work (approval, cost, time, trials, feedback, confidence) and when you do get feedback you can attribute it to the corresponding tweak rather than clumsily point it at the complete redesign.

By major redesign you run the risk of breaking things; annoying users; introducing more hidden problems and the confidence of having done the right thing is harder to determine.

Likely as not you'll implement a redesign and than have to implement tweaks afterwards anyway.

Look at your planned redesign - find out what particular problems are solved. Are they the fundamental problems that caused the request for redesign, or is it much much more on top? Then compare with what teaks you could make to the system in order to improve the experience. Get to know why the current system is a problem for users and what was the real reason why you were asked to "make something work better", and take a step back and rethink before redesign.

Improve this answer
1
  • Thanks, makes total sense. I would consider this more of a tweak than a major re-design.
    – Sheff
    Jun 22, 2011 at 14:45
3

To Roger Attrill's excellent answer (tweak, don't completely redo) I add: if you do make more major changes, also provide clues for existing users, such as double-encoding things. For a non-software example consider what happens when they rename/renumber exits on major highways: for a while you get signage like "New Name (Old Name)" and "Exit 79 (old exit 5)". You can do the same thing in software when you change concepts on people -- "control panel (preferences)", "my profile (account settings)", etc.

Improve this answer
1
  • Not sure in this particular instance how I can provide the double encoding but its something I will think of next time this happens
    – Sheff
    Jun 22, 2011 at 14:46
2

We run into this issue all the time where I work. We come up with improvements on how to do things better and are often met with resistance from upper management.

Check out this question which should give you some guidance on how to go about this.

Improve this answer
2

Your question speaks to change management more than UX design - the issue you confront affects many different parts of a project.

It may well be that existing users need orientation to a new design - so provide it. Anything from help documentation with FAQs on the new interface to a 30 minute webinar (live or recorded) can all help existing users. Be aware that not all users will balk in the same way - some users will be happy with a change log (plain text list), some will require more hand holding.

Note that this is a serious issue and must be allowed for, but it's hardly a reason to not evolve a product.

Improve this answer
1
  • Thanks, I suggested that we update our documentation that goes along with the product, but made point that it should be simple for most users to grasp, as this was the whole point in the change.
    – Sheff
    Jun 22, 2011 at 14:50

Your Answer

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

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