Not letting users make mistakes vs. giving them flexibility

Question

I'm working on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.

Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?

Answer 1

I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.

The section I'm referring to is Choices:

Every time you provide an option, you're asking the user to make a decision.

This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.

Instead it just does lots of things badly.

Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.

Answer 2

The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).

On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.

It's all about who's going to be getting them.

Answer 3

Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.

Answer 4

Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.

Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.

Answer 5

I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:

If you give them the opportunity, they WILL break it

Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.

Answer 6

I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.

Answer 7

Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.

Lessons I take away are:

Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.

Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).

Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.

Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.

Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.

---

Yup, it's harder to program. Embrace it.

Answer 8

I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.

Answer 9

There are at least two ways to build a good software product:

1. Focus on a narrow set of functionality, and implement that functionality very well.

2. Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.

Unfortunately, there are many more ways to create a bad software product.

Answer 10

Your questions implies that you can either provide a flexible solution OR make it foolproof.

I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be: How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?

For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there. That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.

So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.