User interface changes are very difficult to do correctly. Or perhaps it might be better to say arduous. The principle you should follow, is no-regressions. Everything that users currently do, should be possible on the new system.
The reason this is hard is because you have to find out how the system is used. The mistake comes from believing the previous system does what it was designed to do, no-more, no-less. To users, the implementation is the design.
If a feature was provided that was not in spec by a developer exercising common sense. reproducing the spec might lose the feature. If the implementation architecture facilitated modes of operation that were not explicit goals, users will use those abilities.
Believing your description of the currently used system accurately represents how it is used causes this. You didn't get what you paid for, you got what was delivered.
I'm not even certain it is possible to fully discover every used aspect of a user interface, but the worst failures come from not even trying to find out, assuming that they know already. I suspect properly finding out what your current system actually does should consume the vast majority of your budget.
If you have an imaginary model of what the system does you will never be able to make a replacement, but people will still assume that their on-paper description is accurate. On paper the new system is clearly better.
The reason this is hard is because you have to find out how the system is used. The mistake comes from believing the previous system does what it was designed to do, no-more, no-less. To users, the implementation is the design.
If a feature was provided that was not in spec by a developer exercising common sense. reproducing the spec might lose the feature. If the implementation architecture facilitated modes of operation that were not explicit goals, users will use those abilities.
Believing your description of the currently used system accurately represents how it is used causes this. You didn't get what you paid for, you got what was delivered.
I'm not even certain it is possible to fully discover every used aspect of a user interface, but the worst failures come from not even trying to find out, assuming that they know already. I suspect properly finding out what your current system actually does should consume the vast majority of your budget.
If you have an imaginary model of what the system does you will never be able to make a replacement, but people will still assume that their on-paper description is accurate. On paper the new system is clearly better.