Desilets, Alain wrote:
> I'm really interested in hearing what other Ux practitionners have to say bout UI refactoring. In particular:
> * How do you decide how big your baby steps can be (i.e. just how much UI changes users can deal with in a new release).
> * How do you decide if you should still support the old way of doing things?
> * How do you go about supporting both the new and old way of doing things without the system turning into an incoherent mish mash (both at the level of the UI and the code).
> * Do you keep supporting the old way of doing things forever and if not, how do you decide when is the right time to drop the old way?
> * Is the allowable speed of change different for different levels of the system. I would imagine that kite level things are harder to refactor than clam level ones right? What is the factor between those speeds. Can one be changed twice as fast as the other, or 10 tiems faster, or 100?
> * Typically, what percentage of the original UI gets refactored and over what period of time?
Sometimes it is good to 'refactor' a part of the UI.
Let's take the opening metaphor as in Jared Spool's article on
"Designing Embraceable Change"
and change it around a little bit.
Let's say every day you wake up, go downstairs to the kitchen to have
breakfast and think "If only I could get the guy who designed this
#@!**@ kitchen alone for 10 minutes" as you jiggle the fridge out a
little to be able to plug the coffee maker in. (The frig then blocks the
door so you have to jiggle it back to be able to leave.) Then you stand
(because there isn't any room for a table) and drink your coffee and
look around and think about how much you loath your kitchen and whether
you should buy a new house that has a better kitchen.
If, upon waking the next morning and going downstairs, you found a
renovated kitchen that was bigger, had all the functionality it had
before and then some, and was properly organized for best usage - my
guess is that you would't complain too much that you had to search for
the coffee spoons.
This is how we have had success refactoring pieces of the UI in legacy
products. I stress 'pieces'. It's not changing everything at once - it
is spot fixing a problem area.
The key points are:
- the users have to have identified it as a problem area (i.e. If it
ain't broke, don't fix it.)
- it has to be a descrete chunk (e.g. The kitchen, not the floor)
- the functionality that was there must be maintained (what you can do,
but not how you do it)
- the new design must be significantly better to the user (they can do
more, have less frustration, make fewer errors, are more efficient, etc)
In cases like this we do not support the old method because the new
model is better. Of course we do extensive usability tests and design
iterations to make sure that not only do existing users think it is
better, but that they can also transition from the existing method