Eh. Yes, in theory. In practice, I have a bunch of procedures written for people, for whom I have to explain basic filtering functionality in Excel. So even relatively minor change in UI or even underlying concept is a big deal. Just talking about it gives me a Vietnam flashback to the time we had to update all procedures at once and the ridiculous granularity with which I had to describe each step.
I hate to say it, but not everyone is ready to re-learn every single things from scratch. I can, but I avoid whenever I can. If the previous approach works, don't change it unless there is a good reason to.
I took GP's meaning as "these people need to have basic Excel filtering explained to them, so how can they be expected to deal with various UI/UX changes?"
I don't know the answer: at some point a person needs to take responsibility for knowing the tools of their trade. Or a person hiring them needs to take responsibility for hiring people who know the tools of their trade.
Either these tools are mission critical and therefore employees should understand how/why they work, or the tools are not mission critical and therefore it's not a big deal when their interfaces change.
There's a middle ground there where tools shouldn't change so fast and when they do it should be well documented.
Sorry. I did not make it clear. I used Excel as a way to indicate avg. user ability. The system in this case was provided by a different vendor and, in that particular case, drastically changed UI and how the system behaved.
My point was, you don't spring changes like that with, seemingly, no forethought.
I hate to say it, but not everyone is ready to re-learn every single things from scratch. I can, but I avoid whenever I can. If the previous approach works, don't change it unless there is a good reason to.
Will someone please think of the users.