Slashdot Mirror
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?"
I assume you work for Zynga?
Are you sure you want to delete that file?
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!
Who is the target market for your product?
If it's for Joe Sixpack, and he might metaphorically poke out an eye with it, then maybe.
If it's for system admins and the like who neither need nor want training wheels, not so much.
You certainly can expose too much functionality to people who shouldn't have it. But you can also make something useless to the people who actually do need to do it.
Lost at C:>. Found at C.
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?
Since 1984.
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
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.
Yes, there is. Part of the UI is to protect the users from inadvertent operations. That's part of why various destructive operations in programs have the "are you sure?" dialog box. The good ones also have a checkbox that says "Don't ask this again". There's a difference between making it hard to do a task, vs preventing the task altogether. There may be legitimate reasons why one may need to do the said task. Also, provide a way for the user to consciously remove the speed bumps you're putting in. I don't mind software that wants to hold your hand by default, but I want a way to tell it to get the heck out of my way and let me do my task.
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
I've heard this before and every time it was about letting the software bypass some business rule important to an external process.
Well yeah of course I could let you add a negative Debit for an Asset but your accounting department will come at you with sharpened coffee mug or something.
Well, I guess the other time I hear "this software is too good" usually comes from sales and it makes my skin crawl every time.
crazy dynamite monkey
And why it's so easy for shitware like the ask.com toolbar to end up on systems.
People got used to thinking "oh, crap, I just need to keep clicking next until it finally installs". Now you need to check every page of the install to be sure that installing someone's toolbar or whatever isn't checked by default (which it always is).
People either start ignoring the warnings, or stop caring what they say and click next anyway.
Lost at C:>. Found at C.
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*.
What if the user interface lets them shoot everyone else in the foot at no cost to themselves, while accomplishing their task quickly and with ease.
It's a great user interface from the user's point of view, but a really terrible system to have.
SJW n. One who posts facts.
"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.
Agreed. At the end of the day, those who write the checks get what they want.. I was speaking more of the theory rather than the practical.
In those situations where I've recommended and warned against the functionality, and the user still demands it, I have considered it more my failure to communicate the risk than the user's failure. But, as you say, I wanted to get paid so I delivered what the user requested.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Ultimately, your goal is to get paid. If you don't do what the customer wants, you have failed to achieve your goal. What if the ability to do X harmed others?
Many companies exhibit sociopathic behaviors in pursuit of maximizing shareholder value.
If you want news from today, you have to come back tomorrow.
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.
Writing software has to be about more than getting paid.
For instance: Remote start cars are awesome. Putting a remote start in a manual can have unintended consequences. For instance, the car might jump forward crushing a person between two parallel parked cars.
True story, and actually, the designers of that software were sued.
At some point liability for your code will fall back on you, and it's your responsibility to say no and not take the money if you are actually creating a dangerous situation.
Ever delivered something which met the formal requirements and had them say "well, that's not what we wanted"?
There is often an unbelievable disconnect between what users tell you they want versus what they actually really really wanted but had no idea until it was too late.
End users will often help you design unusable software which is exactly what they asked for.
Lost at C:>. Found at C.
Since you felt it would be tedious to explain specifics, you create a huge hole in our ability to give you a serious answer that is relevant to your situation. So to speak on a purely generic level, there's no such thing as too good a user experience.. The notion that you might make the user of your product TOO happy, or make their lives TOO easy, is the sort of sadistic logic that I would normally attribute to someone whose just shitty at developing user interfaces and wants some kind of perverse rationalization to justify their shortcomings.
However... this whole "flying car" analogy leads me to believe that you're not really talking about "user experience" in terms of user interfaces, ergonomics, and the like. It seems to me that you're talking about feature sets and what you are empowering the user to accomplish with your software. For example, some advanced text editors may enable global search and replace. That same text editor may support using regular expressions in a variety of ways. With this hypothetical text editor, it might be possible to combine the application of these features and modify dozens of critical files in unexpected ways, really wrecking the local PC.I'm wondering if this is the scenario that's really behind this question? If so, referring to this as "user experience" is misleading.
I'm fully in agreement that you want to be careful about what sort of capacities you grant the users of your application. If that particular feature has a crappy risk/benefit ratio, then drop it altogether. On the other hand, if you have powerful but risky features that you believe the software needs, then you should be working hard to improve the user experience in such a way that inexperienced users don't stumble across those features accidentally. Although I have personally railed against Microsoft's history of nesting options under multiple layers of dialog boxes, part of the intent there is to segregate "power user" options where they will not distract casual users from the features they actually care about.
I think the real problem with warning messages is that they're so overused that people ignore them. If UI designers had saved warning messages for things that were actually important ("You're about to delete a file") rather than stupid things ("You are loading a web page with unsecured elements") then people might actually pay attention to them.
Hell, back when Vista first came out I had to go through FOUR, yes four UAC dialogs to create a folder in program files and rename it.
What if the ability to do X harmed others?
That responsibility/consequence fall to the user, not the tool used.
It must have been something you assimilated. . . .