I'm in the process of rewriting an old desktop application that's used for warehouse management and retail. The warehouse window is meant for importing, returning and modifying imported items. So it's always an invoice window which is composed of two parts:

  1. The header - import date, supplier and the invoice number
  2. The body - which is a list of imported items, just like excel.

A similar thing is true for the retail invoice. The customers of this application have been using it for more than 10 years. And they're used to creating an invoice and adding items to it without using the mouse. The list of items is a grid, with 7 columns, like item name, amount, discount, etc. When they're on the first column, by hitting enter they bring up a dialog where they can pick an item and by hitting enter again have the selected value put in that column. And they can navigate to the next/previous column with the left or right arrow or tab keys. By pressing up/down arrow keys they can save the changes to the currently inserted or edited record. Some actions like deleting the invoice or inserting a new one are bound to certain F keys. So as long as the speed is concerned it's all good. But is this really a good practice? Do you think I should repeat the same in the web version too? To me, it just doesn't feel right. I can't say why though. Maybe you have a better idea. I tried to find a different approach that would adhere to modern UX paradigms to no avail.

2 Answers 2


Changes involve frustration because users would have to repeat the learning process.

  1. Designing a more modern solution (without so much dialogue screen)
  2. Including interface operation via the keyboard

If the company has the option, then maybe quantitative research might be useful?

Is interaction required in each of the 7 columns? (e.g. Discount is not automatically assigned?)

I think that a useful option would be to enter all values into 7 columns using one dialog (then you would not have to do 7x a given interaction, only 1 with entering the value)


Changing how apps function is usually a UX nightmare. The older the app, the worse it gets. Age is the defining factor of this issue and your sounds very old. This change could be a truly deep negative experience for a major portion of your users. If you have users that don't use computers elsewhere, this could be a life changer for them because it's their work.

You should recreate the current app in your new app. Make the old interface and make it totally functional so users can jump on and go. You could give users the ability to use the current app and show them how to use the new app while they do.

Think of how nice it would be for the app to flip from old to new and show users how to do things. Users would have the comfort of knowing that they can always go back to the old system. The entire orientation and training could be showing the one button to switch back and forth between the old and new system.

I'm a developer and this isn't two apps. it's just a special sub interface on the new app. The old interface doesn't have to be exact in appearance and all its functions should already be covered by the new app.

  • Yeah, just like Gmail app. It almost never forces you to use the new version. Dec 26, 2019 at 19:41

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.