One thing I'm struggling with, and have yet to see an example I'm happy with, is an options dialog (in a desktop app, if that makes any difference.) I'm having difficulties with my own, but they all seem to have the same problems. To take a more generic example:

Microsoft Word options dialog

There's a few common problems that I see:

  • Discoverability is poor; even when grouping into categories. The most common method of finding something in an options dialog seems to be Googling what to click on!
  • Grouping is poor - the "Advanced" tab seems to be a huge culmination of "I don't know where this goes".
  • Explanation of individual functionality is poor in many cases, as it would require a lengthy explanation that doesn't fit on the label.
  • Not to do with the above screenshot, but they're not even named or launched consistently. Years ago, it always seemed to be Tools -> Options. These days it seems it's either under the "Tools", "File" or "Edit" menus for those apps that still use traditional menus, and could be called "Options", "Preferences", "Settings", or anything else vaguely relevant.

Some of the better "options" screens I've seen are those in browsers; Chrome for example allows you to search, which arguably improves the discoverability:

Chrome options

However, even in this case you have to search for the exact phrase or word that you're after. Searching for "Do not track" for example will get you the option to send a "Do not track" request. Searching for "disable tracking" will leave you empty-handed.

The solutions that I can think of aren't really feasible:

  • Slim down the options dialog and put only the most common options there (it always starts small, but many of the options present are there at user request!)
  • Do without the options dialog and find other places to put customisation, such as a toolbar or ribbon (anecdotal, but I've found this just makes it even more annoying to find what you need);
  • Use help icons for longer explanations of option functionality (surely no-one would actually use them?)
  • Create more categories to get rid of an "Advanced" or "General" category (then you just end up with a whole heap of categories you can't really navigate, some of which only have one option in them.)

Are there any good examples that I'm missing, any known solutions to these problems, or any relevant literature in the field for creating an options dialog that doesn't completely suck?

  • 1
    Here's a related question (with answer): ux.stackexchange.com/questions/115208/… Commented Jan 31, 2018 at 8:20
  • 1
    In Firefox, the options dialog is already a slimmed down version compared to about:preferences :) Commented Feb 1, 2018 at 9:08
  • 18
    Tangentially related: Please allow to export and reimport your settings. A lot of apps don't allow that, and it is really a pain when you have to spend hours searching again for that one option.
    – DrakaSAN
    Commented Feb 1, 2018 at 10:12
  • 2
    Whatever you do, use a plain text format config file. Then you can just document your "advanced options" and have people edit them using a text editor.
    – lilpu
    Commented Feb 1, 2018 at 12:52
  • 2
    @lilpu That's exactly what we do at the moment for some options, but it seems like there should be a better way of solving this in the actual interface.
    – berry120
    Commented Feb 1, 2018 at 14:25

7 Answers 7


Software development IDEs have some of the most complicated settings pages I've ever seen, and IntelliJ IDEA does a great job with discoverability. Not only do they offer a search to narrow down the left "tree" to matching pages, they also have a special highlighting effect for matching options. This is similar to your Chrome example, but even better since it doesn't lose the original layout and hierarchy of the unfiltered options.

IntelliJ IDEA settings dialog filtered to Scala

To your solutions:

(All quotes are from the OP)

  • Slim down the options dialog and put only the most common options there (it always starts small, but many of the options present are there at user request!)

Please don't slim down too much! certainly you could make a "common" settings page but we power users hate it when there's no way at all to change something

  • Do without the options dialog and find other places to put customisation, such as a toolbar or ribbon (anecdotal, but I've found this just makes it even more annoying to find what you need);

This is always good practice, but in addition to the options/settings dialog. It should be a one stop shop for all customization of the software.

  • Use help icons for longer explanations of option functionality (surely no-one would actually use them?)

I think people would use them, and more importantly, it would be additional text that could be matched by the filter at the top of the dialog. If the option was "Export to CSV" and the help text was "Export files to comma-delimited files that can be opened in Microsoft Excel", then that allows for queries "csv" and "excel" to match that option.

  • Create more categories to get rid of an "Advanced" or "General" category (then you just end up with a whole heap of categories you can't really navigate, some of which only have one option in them.)

Yes, to an extent- no categories with one option, but removing "General" and "Advance" and organize in a tree (if there are too many for a simple list like Firefox or your Word example).

  • 47
    I love that the accepted answer references IntelliJ. First thing I thought of when reading this question. +1 Commented Jan 31, 2018 at 14:59
  • 13
    I'm actually a bit miffed with myself that I missed this as an option when first asking the question - I use IntelliJ near daily! The IntelliJ style option search, coupled with additional text that could be matched with a search filter, could well be the best answer I've seen to this issue.
    – berry120
    Commented Jan 31, 2018 at 16:13
  • 4
    I'd also like to draw attention to FrankerFaceZ for an example of including extra explanatory text with settings: i.sstatic.net/VvMd8.png Of course, this makes for extra translation work. (They also have a stacked / conditional config system.)
    – Riking
    Commented Jan 31, 2018 at 22:10
  • 1
    What's ironic about this answer is that I much prefer Eclipse over IntelliJ, but IntelliJ wins the Options Dialog battle, hands down!
    – J. Dimeo
    Commented Feb 1, 2018 at 14:57
  • 6
    As a user, I've become a big fan of help tooltips containing (a) brief explanatory text, or examples, etc, and (b) a clickable link into the appropriate online reference. Whether those tooltips are activated by mousing over the option checkbox itself, or a dedicated "?"-type icon to the side, whatever. I'm not a fan of the "one 'help' icon for the entire window" style such as the MS-Outlook example in the OP, because God only knows what's going to happen when I click it.
    – Ti Strga
    Commented Feb 1, 2018 at 16:15

Root Cause: Implementation Driving UI

The whole idea of a single consolidated Options dialog seems to be a consequence of programs having configuration files. The Options function would read the configuration file, present it to the user in a dialog for editing, then save the changes back the configuration file. Perhaps some other programs do the same thing, only reading and writing to the Registry. The implementation, rather than the user’s tasks, is driving the UI design, which often a bad thing. It makes it convenient for the programmer, but not the user.

With the possible exception of when a user first installs a program, a user generally doesn’t think, “Today I’ll change my options.” What happens is the program is doing something specific that isn’t what the user wants (e.g., by default pasting to match source format). So users (if they’re savvy enough) think, “Maybe there’s an option for it,” and embark on a major safari to hunt it down in a jungle of options, assuming it exists. No wonder it doesn’t work.

Addressing Discoverability: Options Proximal to Affected Features

The solution is to put the options with the feature it affects. Don’t have all options in one massive dialog. Distribute them around your menus and dialogs. For example, for changing the default pasting, the Edit menu has a Paste Options menu item below the Paste menu item. Paste Options opens a simple dialog to select the default pasting behavior. Or there’s a Paste Special dialog that includes “Make this Default” so when users select special pasting behavior for a particular instance, they can also make it permanent. This improves discoverability. Or maybe there is simply "Editing Options" if there are also options for Copy, Undo, and Delete (otherwise, your menu has nearly as many "options" menu items as all the other more important ones). When the user executes the command in its menu or ribbon tab, they see there are options for it. It reduces workload, because the users don’t have to search through a zillion irrelevant and questionably organized groups of options to find the one they need. Options are organized exactly like (with) the associated features, which the user already knows or else couldn’t be using the features.

Options by definition are preserved between sessions, so they are most appropriate for things that are very rarely changed. For this reason, it’s important not to clutter your UI with Options menu items and command buttons since they’ll get in the way of what users are usually looking for. You probably should have no more than one Options button per dialog and one Options menu item per menu or ribbon tab. That may not be as strict as it sounds. Going through MS Word’s options in your example (which is among the more extensive), I see there would be:

  • A Cut/Copy/Paste Options menu item on the Home tab.

  • A Format Marks Options menu item on the View tab.

  • A Proofing Options menu item on the Review tab.

That’s about it.

The rest of the options are either put under an Options button in a dialog/page (like Save and Print options), or they are options that aren’t associated with a menu or dialog, so they have to be handled differently (see next paragraph).

Addressing Inconsistent Locations: Have a Preferences Menu

There will be some options that don’t have an associated menu or dialog box, such as “select entire word” in your example. So you still need some kind of centralized place for setting them. However, they are fewer than the total number of options, so it makes them more findable, assuming it isn't best to have the same options both proximal to their associated feature and in a centralized location to maximize their discoverability.

You are correct that there is now no standardize place for them. Microsoft had “Tools” as a standard for a while, but “Tools” is like “Advanced” –a junk drawer of things that don’t fit anywhere else. Apple’s standard of putting Options in the application menu (the menu with the name of the program) sort of makes sense given the paragraph above because these are options of the entire program, not just a specific feature.

However, my advice is to have a Preferences menu at the top level (a pulldown menu or ribbon tab). The place for options is their own place, not under any other menu or tab. This maximizes discoverability: the users see “Preferences” (or “Options,” or maybe “Customize,” depending on your users) every time they open the app. It doesn’t matter if the user is expecting Options to be under Tools or Edit or the application menu. They immediately see it at the top, and don’t bother to look anywhere else.

Space or clutter is generally not an issue especially for menu bars. After File, Edit, View, and Help, most apps don’t have a whole lot else. If there are only a few options (eight or less), the Preferences menu has toggling menu items to set them directly –there is no dialog box. If there are a lot of options, split them up into separate dialogs and access each with a separate menu item (rather than have separate tabs within a dialog). For in-between numbers of options, have a mix of toggling menu items and a dialog or two.

Addressing Poor Explanations: Active Help

As addition to, or perhaps as a better alternative for, a Preference menu, give Help the ability to change preferences. Take “smart paragraph selection” in your example (whatever the hell that is). A user is not going to think, “This dang smart paragraph selection! I wish I could turn it off!” They’re thinking, “This selection is doing something weird; why is that?” So they naturally go to Help to learn more. If the index and search are decent, and the content clearly written, they find out about this smart paragraph selection, and how it works. Maybe once they understand it, they want to keep it. However, if they don’t, then Help should provide the means to turn it off right there in Help. It doesn’t direct the user through multiple steps in an Options dialog to effect this. It’s not like users need to learn that –they’re only going to turn it off once then forget about it. Let them do it right there.

Putting options in Help means searches don’t have to match the options name exactly –it can match any part of the explanation. They can also match any synonyms, assuming your search provided for that. Users get the whole explanation, so they can better determine if it’s the option they want or not.

And Installation?

Consider on installation presenting the user with a list of commonly change options, showing what is default, and allowing the user to alter them right there (e.g., default folders, devices, and such). However, often users need to use a program before they discover what does or doesn't work for them. Thus, it's important to make options reasonably discoverable after installation too.

  • 46
    I have found programs that put options all over the place to be less user-friendly then programs who have dedicated settings pages. Settings aren't changed often. You usually do not need to be able to change the settings ad-hoc, and for the few, rare cases you want to change them, its easier to find them if they are all in one place, instead of hunting down where in the program the ability to change them is buried. Similarly, while working with the program, menu entries that allow changing of settings are just visual clutter, need to be ignored and scrolled over while not being needed.
    – Polygnome
    Commented Jan 31, 2018 at 21:13
  • 9
    Take for example the "Edit" menu. The entry "Change Paste Options" ist just clutter and sits there 99.9% of the time unused, while it has to be ignored while visually scanning for the entries that are actually needed to work. You change these once, and then you are done. Especially when menus grow larger and larger in an application, cutting down clutter is important.
    – Polygnome
    Commented Jan 31, 2018 at 21:15
  • 29
    As a user, I appreciate having one place to go to see what options are actually available, especially in an application that allows extensive customizability. I wouldn't mind have direct access to certain common options in the context of what they affect, but I'd still want a central place that lets me browse all of the available options. Commented Feb 1, 2018 at 0:50
  • 11
    I rather doubt your theory that such design would be implementation-driven. Even with monolithic config files, is very easy to reuse the same "write a config with these options" code from multiple dialog windows. And when the config storage is abstracted out e.g. to Registry or GSettings, there is no such thing as a monolithic config file anymore – the program always reads and writes individual settings in the first place. So your argument doesn't make sense.
    – user1686
    Commented Feb 1, 2018 at 14:10
  • 8
    Polygnome has a point that use-once controls should not over-clutter use-regularly controls (thanks). On the other hand, it good to encourage users to look at options now and then so they can discover ways to improve their UX. Many features requested for Office already existed, but were buried in Options (blogs.msdn.microsoft.com/jensenh/2006/02/07/…). Fortunately, proximal options may balance the two competing goals. Done right, they make options more visible but do not add a lot of clutter, not even for MS Word. I’ve added text above on this. Commented Feb 1, 2018 at 17:02

I posted a related question recently as I have been struggling with a similar problem. From what I have mustered there is no clear and clean cut solution, as these kinds of "options" are often very contextual. This article briefly covers and provides some well known examples.

However, I still feel that there is much to be done in terms of design solutions for these types of menus.

One other article, which I found to be useful, covers the redesign process of the Firefox Options menu. I believe the underlining message is that we need to get our design thoughts and iterations in the face of the users and see what comes up. That is what I will be doing and I'm hoping for an unexpected "Eureka" moment.

  • 4
    The firefox options redesign article is great, and one I hadn't come across before - thanks for that, a good read!
    – berry120
    Commented Jan 31, 2018 at 16:25
  • 1
    You're welcome! I also found it useful. Commented Feb 27, 2018 at 9:00

Grouping can be improved by drawing a line between "Configuration" and "Preferences". Everything that the user has to configure to get your app running should go to "Configuration". Everything optional, which can actually be a matter of preference, should go to "Preferences". For example, I hardly have a "preference" for the default printer (it has to be the one in the same physical office as me) or the path to my autosave folder (it has to be somewhere I always have write access).

The next step is to take a good look at your preferences. Do they actually need to be there? For example, I can't think of a single good reason for "Use Ctrl+Click to follow hyperlinks" to be a preference. If the user doesn't want to follow hyperlinks, all he has to do is not to click. Or "Use smart cursors". If they're really smart, why on Earth would I want to disable them? And if they're not that smart after all, why are they implemented at all? Bottom line, try to make your app as intuitive and easy to use as possible, and remove the option to make it less intuitive.

Finally, learn to refuse user requests. This may cost you some customers, but believe me - a cluttered Preferences dialog costs you just as many, only those users are not vocal about it. Next time a user asks you if you could make a smart cursor which magically jumps to the other screen when the user claps their hands, just say "No".

  • 23
    "I can't think of a single good reason for "Use Ctrl+Click to follow hyperlinks" to be a preference." This is handy when you want to edit the display text of a hyperlink without accidentally following it. Otherwise, you have to select outside of the link and maneuver with the arrow keys, or navigate the context menu to edit the hyperlink. Removing preferences because you personally don't see the use case is not good ux. Commented Jan 31, 2018 at 15:41
  • 2
    Thanks for the answer! To a point, I've tried to do this already - we refuse a lot more user requests than we put in. Even with this however, the number of sensible options can easily reach a huge number, and saying "no" to a good, useful customisation just because you feel you've run out of space in your options dialog seems like a bad idea.
    – berry120
    Commented Jan 31, 2018 at 16:27
  • 8
    Accidentally following hyperlinks can even be a horrible security risk in some cases. Commented Feb 1, 2018 at 9:09
  • 7
    People use software for different things. Microsoft Word in particular caters to an extremely broad user base. "Smart" functionality is, in general, likely to be tuned to writing straightforward English prose and might be unhelpful for typing poetry, or lab reports. Consider smart quotes, for example: they're not very smart at all if I want to write about a programming language. So Word's defaults can cater to what 95% of people want 95% of the time, and preferences try to make everyone else happy.
    – GKFX
    Commented Feb 1, 2018 at 10:49
  • 5
    "If they're really smart, why on Earth would I want to disable them?" because they usually only work for the use case they were invented for. But user bases can be quite broad. Take the "smart" Auto-Format of MS Word for example. its good when you write your general 0815 letter. Its awful if you write poetry, certain technical documents, or want to get creative when building insane birthday cards. So you definitely want to be able to disable it when needed.
    – Polygnome
    Commented Feb 1, 2018 at 16:54

A modern solution could leverage a neural network, trained with various commands and the associated menu items. Think about how Cortana, Siri, Alexa, Omega, and Google function. You type in a command or speak something, and your device does it for you (or at least pulls up the place where you can do it). You can offer an "Advanced" menu for people who want to just find their items in the normal manner (category/sub-category/items). Given your example, a user could say "I want to disable tracking", and the neural network would divine that they are looking for the Do Not Track flag.

Even if you're using an omnibox sort of solution, like Google Chrome, simply implementing a neural network can give the users a better experience, especially if they allow uploading anonymous usage statistics. For example, a few users type in "disable tracking" and then clicked on Do Not Click, so this would be trained in to the neural network. Over time, as more anonymous statistics were collected, the options dialog would actually get smarter the more the users interacted with the options dialog.

Even without crowd-sourcing your data, you could still pre-train the neural network with multiple phrases/keywords for each menu item, and as each user starts using the menu system, the options dialog would eventually be tailored for their specific use patterns. The entire point is that the menu could learn from how its used, rather than forcing users to learn how to use the software. There would still be something of a learning curve, but I think the eventual end goal would be worth the effort.

  • Neural networks for an options dialog isn't something I'd heard / considered before, and probably something that's a bit too involved for me to get into specifically - but I like the out of the box thinking!
    – berry120
    Commented Feb 2, 2018 at 15:22
  • Are you reinventing Clippy?
    – meriton
    Commented Feb 4, 2018 at 15:19
  • 1
    @meriton Clippy was a terrible implementation of a good idea. Neural networks and AI have reached the point where Clippy 2018 (if it were a thing) could actually increase productivity. Unfortunately, Microsoft instead went with their retarded "ribbon menu". But I am looking forward to a menu that configures itself based on your habits, rather than forcing you to figure out how it's supposed to work. I can dream, can't I?
    – phyrfox
    Commented Feb 4, 2018 at 16:51
  • @phyrfox - it would be nice to dream of a world where we don't use "retarded" to refer to something we don't like, either. On a board like this, that is, at the least unprofessional, and also insulting.
    – jukesyukes
    Commented Sep 3, 2019 at 17:10

Without reinventing the wheel or blowing up the idea of Preferences dialog box, I think the single most user-friendly improvement is to have an area within the options dialog box where a paragraph-long explanation of each option appears when you select it or hover on it. One of the things that makes Preferences difficult is trying to cram the explanation for a program-wide change into a few words. "Enable Smart Quotes" is easy to understand, but even it could benefit from a longer explanation. I've admired the way Adobe in some programs implemented in-depth Preference explanations.

  • The issue I have with this is that it requires hovering over each option to find out what it actually does - this is fine if you want to find out what one particular option does, but if you're trying to discover what option does something, hovering over each one in turn is a pain.
    – berry120
    Commented Feb 5, 2018 at 15:43
  • Does not have to be a hover. If it's possible to move the selection bar in the topic tree with keyboard arrow keys, and to tab to set the focus on each option on each page, you can press one key to change pages, and press Tab to read each option's long description. Of course the most user friendly would be to have all that information also be searchable in online help.
    – user8356
    Commented Feb 6, 2018 at 15:33

As I see it, there are really only three major goals in an Options menu:

  1. Find what you want quickly and with as little exploration as possible.
  2. Understand what a given option does as easily as possible, preferably without resorting to dedicated Help windows or web-searches.
  3. Make changing the option as clear and direct as possible. (usually a given, you can't go too far wrong with a tickbox)

The first task, finding what you're looking for is one of the most variable I've seen, some systems present you with a wall of options with some organisation by category or even alphabetically. Some provide only a questionaire-style FAQ system. Search boxes are popular because it allows for natural-language queries.

Personally I'm most comfortable drilling down by category until I find the one place that has exactly what I need. I believe that a system should support someone searching, but it also needs to be quick for someone who knows exactly what they're doing. No need for a quiz or natural-language search when you already know how to get where you're going.

A good Options menu will have natural-language search, but also lay out all the options in a navigable fashion, clearly organised by function. The human mind is built to visualise locations, not key-phrases. So a mappable menu is very intuitive. If I make a search, it should show me the results, I select one, it navigates there and I can see where I am in the menus on a side-bar.

If I then want to find that place again, I can navigate quickly through the side-bar until I get there, or I can use a History system to find my previous searches.

The second major task of comprehension is rather simpler. Provide a plain-text explanation of functionality with a link to a more in-depth explanation if they need it. I suggest using the common convention of a ? symbol in a circular button, this can reveal a floating textbox which has the full explanation, either when clicked or when rolled over.

Beyond that, clear partitioning and use of iconography will be of great help.

Associating the specific options with buttons the user is already familiar with (eg: the ones in the main UI of the application) will help them find what they want too.

For an example, if I'm looking for an option to affect Fonts in a word-processor, I will be greatly assisted by seeing the Font button's icon in the Options menu and being able to follow that.

One could also add a context-sensitive options system into the UI itself. So if I right-click a button in the main UI, it should include a link to the appropriate section of the Options window in a context-menu. Instantly doing away with the need to navigate from any sort of landing page.

Further to that, adding buttons for toggling the most common changes (either by that user, or from anonymous usage data) to that same context menu would also be of great help.

  • My favorite example of an incomprehensible option is in Excel's Advanced options. There's one: "Cursor Movement" with two radio buttons: "Logical" and "Visual". What behavior do these change? When are visual and logical movement different? And why do searches in the help for "cursor movement" or "logical visual" or "cursor movement logical visual" all give results that do not appear to apply? (Note: one of the results does apply, but you'll only recognize it if you already know what the option does.) Commented Feb 3, 2018 at 21:32
  • Exactly, a system conforming to the guidelines I laid out would explain in plain words exactly what Logical or Visual will achieve, and searches for that functionality would turn it up because the description includes the appropriate keywords. Commented Feb 5, 2018 at 16:32

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.