Ask Slashdot: When Is the User Experience Too Good?
gadzook33 writes "I had an interesting experience at work recently. A colleague suggested during a meeting that we were building something that would make it far too easy for the customer to perform a certain task; a task that my colleague felt was deleterious. Without going into specifics, I believe an apt analogy would be giving everyone in the country a flying car. While this would no doubt be enjoyable, without proper training and regulation it would also be tremendously dangerous (also assume training and regulating is not practical in this case). I retorted that ours is not to reason why, and that we had the responsibility to develop the best possible solution, end of story. However, in the following days I have begun to doubt my position and wonder if we don't have some responsibility to artificially 'cripple' the solution and in doing so protect the user from themselves (build a car that stays on the ground). I do not for a second imagine that I am playing the part of Oppenheimer; this is a much more practical issue and less of an ethical one. But is there something to this?"
If your interface would allow a user to shoot themselves in the foot without proper precautions, then your user experience is, by definition, *not good*.
The goal of any application is to let the user perform a function FASTER than manipulating the data themselves, manually. If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
I suppose this is the rationalization that Apple uses internally to justify their walled garden. Gotta protect users from themselves whether they want it or not.
Rather than being assholes like Apple, perhaps you could make this configurable in some fashion? Whatever the hell "this" is?
Put a button that toggles your program's "dangerous flying car" interface, with a nice warning about they can now wipe their system with a single click, and you aren't responsible if they misuse the software.
Learn to think in the wiki way.
Rather than make it hard for users to do what they want to do, on the (very valid) assumption that some of them will do bad things, or things they don't really want to do, it is better to make it easy for users to recover from those mistakes, and for others to recover easily from any side effects of those mistakes.
This is not always possible. But it usually is.
Jimmy Wales - Wikipedia.org
Wikia
"If your UI enables the user to destroy a significant portion of that effort easily, then you have failed to achieve your goal."
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal.
It is acceptable to try to dissuade them. It is acceptable to warn them. But document it when you do. And if they still want it despite all your warnings and attempts to convince, then give it to them. That's what you're getting paid for. If they complain later, show them your documentation and where they insisted even though you advised against it.
I once worked for a company that demanded the ability to do X in the software, despite my warnings that it was a bad idea. So I put in confirmations. When they first clicked the button to do X, it first popped up a message saying "This will result in _____. Are you sure you want to do this?". If they clicked Yes, then another confirmation popped up: "Are you really sure?" And if they clicked yes again, a third confirmation popped up: "Are you really, really, REALLY sure?"
An administrator mentioned to me later that he thought the warnings were funny, but he liked the fact they were there.
It should be noted that your whole post has the caveat "unless someone could get hurt". Working in heavy industry, we quite frequently tell our clients "No, you do not want X. X does not make sense, and you will hurt yourselves. You want Z instead." If the client insists, we stop doing business with them. If the crane you built collapses because the customer wanted a "press here to collapse crane" button, nobody is going to give a damn that you have documentation proving the client really really wanted the button.
When it comes to health and safety, the customer is not always right.
Everything is better with chainsaws.