User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Sparked by this discussion.
Is there ever an argument to be made that products should be deliberately made difficult to use as a barrier to entry for the use of that product?
If so, in what sorts of situations are these barriers to entry appropriate?
EDIT: To clarify the sorts of answers I'm looking for - I'm not necessarily looking for a catalogue of examples, but rather a method or set of general principles for determining whether it's appropriate for a given use case.
There's a few key reasons I'll go over. For reference I'm referring to "training" here as any sort of help text no matter how involved, not just formal training requiring tests, human teachers etc.
This is a big one; if safety is a factor, people need to learn how to use it. You don't get in a car and figure stuff out for your first time. It's not Angry Birds. Anything that comes with significant risk that isn't intimately familiar for your users should require some "training" of some form, even if it's just a warning. Not all dangerous things need this however; knives are dangerous, but anyone who can purchase one is almost certainly quite aware of what it is, how to use it and the risks involved with sharp things (little kids generally don't buy knives).
Similar to safety, but for the device/service/etc, not the user. If it's very easy to screw up and hard to recover, you need training. Ideally heuristics help, allowing error recovery, undo, redo etc, but sometimes that's not possible. This is why complex software generally has guidance or even certification. You might not set yourself on fire, but you might cost yourself/others thousands of dollars with a mistake.
Sometimes stuff isn't dangerous in any way. It's just really freaking hard to understand. A quick tutorial and a dedicated help section can go a long way in this situation and may help you avoid requiring extensive training. A way to mitigate this can be giving limited options at the start; Stack Exchange does this pretty well. SE is actually really complicated once you get into the tricky bits, but the "post question/answer, maybe get points" part is dead simple, and starting out, that's all you need to worry about.
If it's not possible/desirable to present a limited view or have a quick refresher course and the first-time experience of your app/device is that bad, a tutorial of varying length may well be necessary. Video games are a classic example of this; except for some dead-simple games like Super Mario it's likely that you'll at least need to show the player some buttons, indicate what things are deadly, show hints, etc.
Similar to complexity, sometimes it's just plain hard to get into something until you understand what you're doing. Video games are a good example of this. Many games start with either a tutorial, or watered-down early levels which get you familiar with your controls and abilities.
Building in training for enjoyment can be very different from training for other purposes, but it can also be the most effective when done well. Making training an engaging, enjoyable process can really help people understand, remember and not hate your training. Lots of video games do this well (see Metroid and gradually gaining abilities) and lots of video games do this terribly (see almost any Role Playing Game with a 30 minute tutorial).
If you can build your training into normal use of a device or service, that's ideal. This allows you to focus on enjoyment while making it engaging and memorable. Instead of hitting users with the wall of text and an "I read this" checkbox, guide them through a couple simple steps. Gamify the process and make it feel like an accomplishment when you're done instead of making it feel like a burden. This isn't always possible of course, especially with physical devices, but it can be done well in digital products.
Also remember it may well be necessary to include an option to opt out of tutorials/training/whatever depending on the application. There are many video games I stopped playing simply because I wasn't going through that tutorial ever again, and a few services that have scared me off just because I didn't want to deal with all the learning crap. As I'm sure you're aware, these can be very off-putting. Nothing is worse than treating your user like an idiot (regardless of whether they are) so "skip tutorial" options can be important unless safety/fragility is a severe factor and you have no way of verifying the user has previously completed the training.
It’s impossible to cover “all situations” but collaboratively we might get a good list. For starters I’d like to add child-resistant packages when it comes to medication or possibly harmful cleaning liquid. They require “training” in a way that you need to read the instruction first in order to be able to open the package. However, there are records of child-resistant packages being opened by kids where adults fail, but that’s another story (which might refer to CogSci.SE?).
In the UK, parts for gas boilers and gas installations purposefully don't come with instructions - the rationale being that you should only be using them if you know how to.
Difficulty-of-use has deficiencies in acting as a barrier. For one reason it's not explicit, another reason is the knowledge to overcome the barrier can be informally provided (e.g. on the internet, just enough knowledge to be dangerous). Explicit things like keys (both common keys like car keys as wells as special controlled tools that enable access), combination locks, passwords, and credentials are surrounded with a formality that helps psychologically maintain the barrier.
Difficulty-of-use is sometimes useful as a secondary barrier, e.g. child proof caps.
If you want your product to be used by a reduced but more skilled group, then yes, you should design it as complex as it requires to function and fulfill what is has to do, but not more complex than required.
Usually making things easier to use imply a more complex design, more parts, more interactions, more maintenance and more errors, so if you can avoid the extra problems, then you should, for your benefit and for the benefit of the final user.
For instance, I would appreciate a browser that is compliant with the standards, whichever they choose, even when I know that many web pages wont work. Obviously that will be a failure with the general public.
I also have to say that while I was trying to think of examples, the ones that came to my mind involve the exact opposite of what I mentioned before. For instance, I can make a watch with many extras, like barometer, calendar, altimeter, etc, and those features will make the watch more expensive and targeted to a more reduced group that will have use for those extras, but it will make it more complex, and hard to maintain, but it will be the way to go for a product like that.
I have to come up with more examples ...
Depending on your interpretation of "Barrier To Entry" sometimes in games there is an intentional barrier that serves a purpose.
e.g. Most electronic game players want to dive right in and play so no matter how inviting you make the "instructions" or "tutorial" page many players will never go near it mainly cause we are just way too cool!
Embedding the tutorial into the game:
However if you introduce only the bits the user needs to know, as they go in the first few levels they don't realize they are "learning" how to play but actually feel good about progressing quickly into the game.
This is actually very helpful as users that just dive in might miss a subtle detail about how your game works... give up and leave nasty reviews / spread the word that your game sucks.
The developer of "Plants vs. Zombies" gave a very good talk about this explaining how tiny messages as concepts were introduced ensured players learned the game, felt a sense of accomplishment as they progressed and never even realized their was an "instructions" part.
Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.Whether or not it's an appropriate requirement is hard to say though.