I work on an application that's designed to be usable by new users, but has a lot of complicated configuration for advanced users. Our approach to keeping users away from delicate settings is to make them 'scary'. They are tucked away in an 'Expert' menu, and configuration parameters are given 'scary' (as opposed to nice, readable) names such as UseBxfrMethod, and no indication of what they do (outside of our online documentation/man page).

For applications which will be used by both 'novices' and 'experts' is the 'scaring' approach good UX? Or would some other approach be better?

Note: A similar 'scaring' approach is employed by Mozilla, albeit with a bit more humour:

enter image description here

  • 7
    I'd certainly say it's appropriate some times to communicate risk, I particularly like Mozilla's silly intro + descriptive takeaway.
    – Ben Brocka
    Commented Apr 10, 2012 at 16:50
  • 24
    Communicating risk is different from confusing users. I'm not a big fan of using obfuscation (like your UseBxfrMethod name) to make it so beginners don't make the change. Keep the name understandable so the experts know what it does. Nobody reads the manual, so don't expect your expert users to look it up. Find an alternate way to clearly point out the dangers of modifying that field and other "dangerous" fields.
    – rbwhitaker
    Commented Apr 10, 2012 at 19:21
  • 2
    A sufficiently complicated and a detailed message is scary enough for many of the users, including advanced users.
    – bhagyas
    Commented Apr 11, 2012 at 6:35
  • 7
    As a user, if I'm tweaking the advanced settings then I'm doing that because I need to tweak the advanced settings. If the settings have unclear, cryptic and/or meaningless names then chances are I'm going to do more harm than good before I finally find the right settings to tweak. At that point the application will probably be left with some horrible configuration because I can't remember half of all the changes I made. Two days later I discover that the settings were actually documented somewhere.
    – Supr
    Commented Apr 11, 2012 at 8:52
  • 1
    I would be one of the novice users that would click an obfuscated command under an "Expert" menu just to see what would happen. Commented Apr 12, 2012 at 12:05

7 Answers 7


Progressive disclosure

Deferring advanced features to a secondary screen is one of the best ways to satisfy the conflicting requirements of power and simplicity. This is called progressive disclosure. You seem to be aware of this.

Intimidating users

An example of progressive disclosure is a search box. The search box typically contains a link to an advanced search page since including advanced options on the same page will most likely confuse novice users. Jakob Nielsen recommends using an intimidating name:

It is important to use an intimidating name like "advanced search" to scare off novice users from getting into the page and hurting themselves. Search is one of the few cases where I do recommend shaping the user's behavior by intimidation.

Communicating risk

Consider this, a user with many years of experience using other applications is still a novice with respect to your application. I understand your concern that fearless novice users might ignore an intimidating name like "advanced settings". However, names such as UseBxfrMethod and requiring expert users to read manuals will likely be a "turn off" especially if they are not loyal users.

A better approach would be to have multiple secondary displays. For example, you could group harmless settings in one display and dangerous settings in another and clearly indicate the risk involved in progressing to the dangerous set of options while offering an easy way to access relevant parts of the documentation.


download bmml source – Wireframes created with Balsamiq Mockups

Conclusion Scaring away novice users during the progress from the initial "novice" screen to the secondary "expert" screen is fine for your purposes, but beyond that it is not recommended.

Update on Jan 13 I just noticed that GitHub applied this concept in the repository settings page.

enter image description here

  • 6
    I'm inclined to upvote for the "Nuclear apocalypse" toggle image alone.
    – zzzzBov
    Commented Apr 11, 2012 at 15:07
  • +1 for good coverage and github example. When I went to delete a repository they made the implications of doing so very clear.
    – Chris Bier
    Commented Jan 4, 2013 at 20:05

Yes, but I am not sure that execution works for me. You put up a signpost, easily ignored, at the front. Then they get in and will make a change and forget the sign.

I like the use of humor, but generally I use it closer to action that was dangerous.

Additionally, it shouldn't just be text. Find a way to make the user THINK. Too many errors happen because people don't read. Don't make it possible to do the action without comprehending the choice. I blogged about this particular modal.

enter image description here

  • 3
    This model isn't really appropriate here, as there are a huge number of config options (>50), a lot of which are harmless. Also, a lot of them would want to be tweaked a lot, so this approach would be rather heavy and frustrating for a lot of our users.
    – fredley
    Commented Apr 10, 2012 at 16:21
  • 2
    It's a question of risk vs. ease of use. How easy do you want to make it possible to shoot yourself in the foot? A single sign post will get ignored.
    – Glen Lipka
    Commented Apr 10, 2012 at 21:39
  • 1
    I think this technique could be applied in Fredley's case so long as it had an option requiring some knowledge or thought to disable it. Perhaps, a "Don't show this again" button which requires you to find and input the exact version number, or tells you which secondary menu in advanced settings to go to to find the "Disable warnings" option. Or both! A casual user following a one-time walk-through wouldn't go to the trouble, but an advanced system tinkerer would. Commented Apr 11, 2012 at 10:25
  • While this does address the question, I'm not a big fan of this example. A better solution for this scenario would be to implement undo. (Of course, you can't really undo a delete, so you simply mark things for deletion at a later date, and the undo unmarks them. Basically, the trash can metaphor.)
    – Chris Calo
    Commented Apr 13, 2012 at 1:43
  • 1
    Undo is always the first option. Unfortunately, the realities of engineering often make it impossible (or just the decision was made to cut the corner). This was one of those cases.
    – Glen Lipka
    Commented Apr 16, 2012 at 15:35

In general, negative reinforcement like scaring users should be considered a bad idea. Theories on Advertisement and Product Design (outside of Halloween) have found using such tactics to usually backfire and is even cited from campaigns around WWI by advertising experts of the era like Claude Hopkins (cite: My Life in Advertising).

In my own experience, I have seen nothing but negative reactions from trying to scare users with complex, unfriendly names and even a splash of humor. In tests, I've seen users reiterate that they feel like the developer/designer is talking down to them and would rather be nurtured so they can become better at the product. An expert in a product tends to have more loyalty than a person not familiar with the product and thus, maintains to be a customer.

So, if you have expert features, I'd try to make those expert features as usable as possible. The names that you cite and how they have no meaning to a user unless they consult separate documentation is more of a restriction and barrier to nurturing your audience than helping them in any way. If you are truly concerned, hide the "expert" section in some configuration section that has a toggle of "turn on expert features" and provide a user friendly way of learning and using those expert features that maybe only 10-20% of your users actually care about. It's better to focus on the 80% than to try and scare them from NOT using a part of your product you're putting a lot of time into.

  • 1
    I'm ok with being rated down; however, would appreciate the courtesy of knowing why the disagreement. Commented Apr 10, 2012 at 16:51
  • 3
    I don't think it's a matter of scaring them but more making sure they take caution when messing around with certain settings. The Mozilla one works great because it even slows down someone like myself who might typically be very comfortable with "advanced settings". Commented Apr 10, 2012 at 17:06
  • @JamesEggers Perhaps a more direct reference would help? I'm just guessing at why you got a downvote.
    – Taj Moore
    Commented Apr 10, 2012 at 22:34

Serious warnings are OK but you should be careful to refrain from making them appear childish. If you're going to treat your users like toddlers, that will make them feel like they don't want to use your program at all.

At school we received a course on UI design recently with a couple of principles that should be maintained for a good user experience. One of these is that if you make the user feel dumb (for example by throwing a stack trace at them when you don't handle a fatal error, or blindly use something like messagebox(exception.message) everywhere), that is one of the main reasons for them to be scared off by your program. Throwing warnings at them in se is not, but if you make them appear like "you will not understand this, go away", it is. If you need to put a warning in your program, just tell the user that in case he doesn't understand what a setting does, that it is recommended to keep them at default.

Giving users choices is a good principle, but it's not if they don't understand the choice. Have a look at one stupid dialog


If you look at evidence from the Microsoft Windows vs Linux PC operating systems - A lot of "expert" settings in the Linux operating system are hidden away in shell commands (granted, recent builds have come a long way to incorporate friendly GUIs for common tasks).

In 2011, it was estimated that Linux had a total of less than 2% of the market share, compared to Microsoft's 92% (Market Share - Wikipedia).

Essentially, the operating systems are trying to do the same thing. You could attribute the disparity in use to the accessibility of advanced settings. Yes, there are many advanced settings in MS Windows that can only be changed via the registry, but many fewer when compared to Linux.

Of course, you could also attribute the disparity to a number of other factors. But I put it to you that the average Joe Public finds Linux scary and Windows not so. Hence in answer to your question - Scary UX is bad UX.

  • I find registry generally scarier to edit than plain text files; registry appears to me to be more fragile and is definitely much harder to backup and restore. With plain text files, if I mess anything up, I'd just copy the backup file, restart, and things will be all well again, with registry... not so much, that is assuming the OS is well enough to run the regedit. With plain text files, even if the OS won't boot, I'd just pop in any kind of Live CD, restore the backup file, and make another go.
    – Lie Ryan
    Commented Apr 11, 2012 at 14:02
  • that's pretty much reason why I had a heavily customized .vimrc file, but generally left firefox's about:config alone unless I really need to. IMO, plain text is much easier to deal for advanced settings than registries. Of course a well-designed GUI trumps both, but it's simply not possible to create a well-designed GUI for every settings on a program that have thousands of knobs and tweaks that interact with each other in strange ways.
    – Lie Ryan
    Commented Apr 11, 2012 at 14:12

If anything, asking the user whether they want to perform dangerous action XXX, whether they are sure, whether they are sure about their being sure, ad absurdum is quite pointless. Glen Lipka's answer is a good idea, but some users won't really understand what the dialog wants, and will think that data is irreversibly geld in place, and begin harassing the developer to create confirmation boxes for ADDING data. Although if the user can't understand it, do we even trust them with the application?

  • 2
    I think if we added @GlenLipka's dialogs, we'd end up with users asking for a config option to turn them off...
    – fredley
    Commented Apr 10, 2012 at 16:23
  • 1
    "if the user can't understand it, do we even trust them with the application?" In many cases more than one type of user has access to an application and in the outside of business software restricting access to advanced features to a subset of users is much more difficult. ex my Mom probably never should go into Firefox's about:config page; I've probably changed at least a dozen settings there over the years. Commented Apr 10, 2012 at 20:24

It's not really scaring them. Its just a serious warning and we use them as part of interfaces in all sorts of household products. If you open the circuit breaker box, there had better be a serious warning that you may be close to touching enough electricity to kill you instantly. I think there are software situations that are analagous.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.