No matter how good you do something, the user will screw up and ask for a way to correct things, especially important for corporate systems.
Users gonna be users
They will screw up and then ask you to fix whatever they did wrong.
Some places might tell them โOh well, good luck next timeโ or โFollow this thousand-step guide without missing any step, and then you’ll be able to fix that. Maybe.โ.
This sucks, people will complain. Some will understand, and some will stop using it.
In some places this is not a โlossโ (for the company), but in othersโฆ
Sometimes thatโs not an alternative
If youโre working with corporate systemsโฆ When you don’t account for the user screwing up, then if your software doesn’t have a way of fixing errorsโฆ someone will have to fix it somewhere somehow.
The problem with that approach is the lack of control and possible side effects of those manual changes. Not to mention, it’s easy to end up changing the wrong things either because it’s distributed in multiple tables or too similarly (or poorly) named.
The user will teach you!
I like the following quote that I believe to be appropriate to the matter (edits are, obviously, mine):
There is no teacher but the
enemyuser. No one but theenemyuser will tell you what theenemyuser is going to do. No one but theenemyuser will ever teach you how todestroy and conquerawe them with your software. Only theenemyuser show you where your softwareare weakhas bugs. Only theenemyuser shows you where he isstrongenjoying your software. And the rules of the game are what you can dotofor him and what you can stop him from doing toyouthemselves and to your software.
โ Orson Scott Card, Enderโs Game
Two approaches
You can either screw the user, or the user will end up screwing you.
And I think most people will, unfortunately, think like thisโฆ
The third, and better, approach
Instead of thinking about the user as an โenemyโ, you can think of them as a teacher and as a colleague (and in the case of corporate systems it literally is!) who will help you and your software succeed.
Some people will โoutsourceโ much of this to designers and other people to such an extent that they will never see a user that will use their software. On the other hand, the users will never meet a developer.
And you will end up with people making software for someone they never saw and users using software made by someone who knows nothing about them.
Communication and learning, together
While you canโt talk to every user you will have, you can and should have a quick way to get input and feedback from a few selected ones.
Afterward, keep getting their and other usersโ input.
You will be surprised, but the user is usually a wild entity that doesnโt work by the rules you think they should. So, you need to talk to them, find out what they actually mean and not just what they say and from there iterate.
There will be people doing this to you, maybe, but that doesnโt exempt you from first hand experience with the user.