I like how Google's Material Design approaches patterns for application settings:

Settings should be well-organized, predictable, and contain a manageable number of options (emphasis added).

The question I have is, what happens when the number of settings your application has does become unmanageable?

In the current application I'm working on, a "Miscellaneous" section was somewhat used as a dumping ground for any one-off configurations that came up as different clients requested new features. As you can imagine, over the years this has built up to a rather large amount of editable fields.

The task I now have is to go through through and reorganize it so it all doesn't fall under a generic miscellaneous category, but the heart of the problem is that the number of ways a user can configure the application is just too unwieldy.

The more we categorize our options, the harder it is for the user to navigate as there are too many sections to discover and go through. The more we limit the number of categories and try to include as much as possible within each group, the more we run into the old problem of grouping settings together that don't really belong.

Really, all our problems stem from the fact that the application is highly customizable, and contains a multitude of configurable settings.

Is there any reading material on trying to manage an inherently large and somewhat unmanageable amount of settings within an application? I know that seems contradictory, but it is the current situation I find myself in.


  • 2
    I asked a very similar question here
    – Cai
    Commented Feb 8, 2016 at 21:54
  • 1
    Thanks @CAI. Your three scenarios are pretty much exactly what I'm running into. The suggested solution is coincidentally (or maybe not coincidentally) what I think we're going with as well.
    – romellem
    Commented Feb 8, 2016 at 22:16

9 Answers 9


There are several complementary approaches...

...to reducing complexity. Effective design often relies on an appropriate mix of multiple approaches tailored to your user base. For example, Eclipse users (in another answer here) tend to be professional/expert users who understand how to navigate complexity and may want a lot of control. Google Chrome users are different...they are not necessarily expert users so Google hides a lot of complexity in the settings.

Here are some common techniques for reducing config complexity:

1. Frequently vs. rarely used settings

  • The pareto principle usually applies to complex settings. 20% of settings get used 80% of the time. So you can shelve the 80% rarely used settings into a More settings or Advanced settings button.

2. Normal vs expert settings

  • This is another way to reduce complexity. Hive off advanced settings into an Advanced settings section where expert users can tweak them but normal users don't have to bother with visually processing an enormous mass of options.

3. Allow users to search

  • This is a tried-and-tested way to reduce complexity. Apple's settings UI provides a search function which highlights relevant areas and also provides autocompletion for terms:

    apple settings search

4. Use taxonomy

  • Group settings into a logical hierarchy or set of categories, then visually lay them out that way (e.g. Display, Time/Date, File handling, Data sources, etc)
  • Tab layouts, tree controls, nav bars, menus/submenus, page sectioning, and layout islands can all be effective ways to present categories once you've figured out your taxonomy. But it starts with proper classification.

5. Guided paths

  • For configurations/settings which require workflow or involve dependencies, it can be effective to provide a mandatory or optional wizard to help users through the configuration process.
    • For example, if changing one control in a factory system affects another set of machines, it can be difficult to help the user configure the system using a static settings page: a wizard UI may help with those specific workflows.

6. Reduce app complexity

  • Consolidate features in your app, remove rarely-used or redundant features, and common-factor similar workflows into more generic/flexible flows.
  • This can be difficult or expensive to undertake in a custom app because of the cost of engineering, but for widely used apps (gmail, excel, etc) it's often worth the time to do some feature consolidation to help reduce overall UX complexity.

Again, effective design here will depend on a good understanding of who your users are and a judicious selection of which one or several of these approaches to employ.

  • Thanks for the in-depth writeup. I like the note about the pareto principle; I think we'll definitely be running into that in various parts of the application. The bit more nuanced question though, is how to determine which options fall into the "rare" group, and which don't.
    – romellem
    Commented Feb 9, 2016 at 19:50
  • @romellem sure thing. There are a few ways to determine rare vs non-rare. you can do it top-down through by deducing which features are less likely to be configured, or bottom-up through empirics by simply measuring what users are doing on the settings page. Often there is a behavioral design component too: designers may want to emphasize certain settings and de-emphasize/hide others for reasons of security, usability, policy, etc.
    – tohster
    Commented Feb 9, 2016 at 19:53
  • Pareto is probably the way to go: The most important settings in an easy structured list and an Advanced button, with all other settings, having verbose names/tooltips and a full-text search-as-you-type to search for anything related. - this way your support can also easily guide people to the right setting!
    – Falco
    Commented Feb 29, 2016 at 15:41

Remove settings. Period.

Ideally, your application has zero settings. Users hate settings, and they take their time away from the core task they are performing. For example, in a drawing app, ideally the user would spend 100% of their time drawing.

The way you remove settings is to make design decisions. If your app has an unmanageable amount of settings, that means you are likely offloading design decisions to the user. Notice how easy or hard it is to determine a sensible default for each setting. If it is easy to determine a default, then likely that setting can be removed. If it is hard to determine a default — say, because 50% of users will want it on and 50% of users will want it off — then that setting might need to be left in.

  • 2
    +1 for "make design decisions." I'd +1 again for "sensible defaults" if I could. Commented Feb 9, 2016 at 16:17
  • 1
    I think in general this is true but saying ideally zero settings and users hate settings is a rather bold statement and depends on the app. First one that comes to mind is Tinder (dating app) you can open the settings and change your location, range to look in, age to look for, whether to be shown at this time. All things I change, and rather frequently, that by no means could have a default. If you are referring to just UI settings though, then I completely agree.
    – DasBeasto
    Commented Feb 9, 2016 at 16:21
  • In an ideal world, this could be sensible. However, I'm not at the level to make those business decisions. I like what one @Daniel.Beck wrote below, in moving true one-offs to an external configuration that isn't accessible to the user, but again, I don't think I'd be the one to make that decision. Thanks for the response.
    – romellem
    Commented Feb 9, 2016 at 21:33
  • For a casual consumer application this is mostly true. In the world of enterprise apps, this strategy is rarely successful. Commented Feb 9, 2016 at 21:35
  • FTR I personally hate when there are no settings when I don't like the default
    – Aprillion
    Commented Feb 10, 2016 at 7:14

There are applications where it's appropriate or even expected to have a large number of user preferences / settings; and there are audiences who enjoy having those settings to twiddle.

The history of this particular case strongly suggests that yours is not one of those:

one-off configurations that came up as different clients requested new features.

This sounds like a bad case of accidental design; you've been deferring design decisions by dumping them in as user settings. Idiosyncratic customer requests or one-offs should never find their way into the UI -- if something's only useful to one person, no reason to put it in everyone else's way. You could rearrange these all day long but that isn't going to fix the underlying problem that most of them probably shouldn't be there in the first place.

Your first step has to be to go through the existing customer data for each of those settings and divide them into the following categories (where "uses this setting" means "have set it to something other than its default value"):

  • No current customer uses this setting -- You'll find lots of these. Delete them.
  • It's a one-off used by a single (important) customer -- remove it from the UI, move it to a customer-specific config file.
  • A handful of customers use this setting -- Judgement call whether it's worth moving this to a config file, keeping it for the next steps, or simply eliminating it. If the setting is primarily cosmetic or workflow-oriented -- i.e. if there is a way for the user to get the same results without the setting, err on the side of eliminating it.
  • The majority of customers use this setting the same way -- Make that the new default value, and consider eliminating the option from the UI. ("Everyone picked the same non-default setting" is is a much stronger signal than "everyone left this as the default".)
  • It's used frequently, with a wide range of set values -- Finally we're getting to the good stuff, but these, too, will fall into subcategories:

    • Purely cosmetic, with no functional effect on use of the product: Unless cosmetic customization is a key feature of the product, eliminate these, ideally as part of an overall cosmetic redesign of the product so users don't perceive it as "you took away my special snowflake setting!"
    • Bike-shedding Settings that boil down to "do the same thing the product normally does, but in a slightly different way, because of reasons that seemed important at the time": eliminate it, as above
    • Set-and-forget Settings that are meaningful and useful, but which a given customer will never or rarely change once set: Consider moving these to a config file or (especially if there are a lot of these) making them part of your onboarding process, a new user "wizard" or the like, rather than the day-to-day UI; or at the least keep these separate from settings that would be changed frequently.
    • Real, meaningful application settings These are the keepers. Once you've boiled it down to these, it'll probably be clear how to best organize what's left.

One possible solution is to try and provide those setting or options within the context of where it is relevant to the user, especially if it is likely to be adjusted or changed while the user is using the application (that way they don't have to keep going back to the settings page). Alternatively this can also be a link that is presented as a hint or tool-tip if you don't want the settings to be shown on the same page.

The other thing you can do is to think about the naming conventions so that you can have a consistent, if not entirely meaningful way of labelling the settings so that it is easier for you to group or order them. That way you can at least make it a little bit less annoying for the user to learn and find them.

  • I do like the idea of providing the options within a certain context, which I believe we are taking into consideration. A good point you bring up, and one that I think we aren't taking into as good of consideration as we should be, is likelihood of use. That is, a lot of our settings are mostly display in alphabetical order, but what the user is searching for might not be at the top of the list. Thanks for the comments!
    – romellem
    Commented Feb 8, 2016 at 22:17

Group the settings with tabs

Taking the image from my recent question, shows some options on how to group the settings using tabs.

Option 1 isn't a good solution and is essentially the problem you (and me) began with. Options 2 and 3 are what you should aim for. I believe option 3 is visually the ideal solution but the logical grouping of the settings should take precedence and the grouping you use will depend on the exact settings and uses you have.

The most important thing to take in to consideration is that the settings need to be grouped logically with sufficiently descriptive labels. This enables easy navigation of the settings.

From icc97's answer on my previous question:

From Jacob Neilsen's Tabs, Used Right:

It logically chunks the content behind the tabs so users can easily predict what they'll find when they select a given tab.

enter image description here

  • 1
    ^ This. To expand on the tabbed solution, you may still have more than feels reasonable within a tab -- a situation I'm faced with in an enterprise suite right now. In those cases, determine the "normal" settings that will be accessed and the "advanced" settings. You can then mask the advanced stuff behind a button to be exposed on demand, by those who are ready to face the challenge. Commented Feb 9, 2016 at 21:43

You should implement some type of description for the settings, and have a search function that searches the name of the function, its description, and some common words used to describe the settings. On Stack Exchanges, those common words are called tags.

Whether you use a list, a hierarchical structure, or a tab based structure, the search ability will significantly assist users find what they are looking for.

The key to this is to have a good search engine and produce usable results. That should not be too hard if you can seed the appropriate tags in the background.

  • I agree, good search is key, but as you alluded to, producing usable results is the tricky part. I'll bring this up again, but based on how we have the application structured, search is going to be harder to implement than you might think. I appreciate the reinforcement though.
    – romellem
    Commented Feb 9, 2016 at 15:01

Flippant answer:
Have less options.

Less flippant answer: See if you can reduce the number of options and settings by looking for common patterns of use.

Why do you have all of those options, and what do they pertain to? Usually the inclusion of each option is because the answer to a question wasn't known, and so the work of answering it is dumped back on the end user in the form of an option.

Dumping design problems onto the user instead of addressing them is rarely the best solution.

So, to deal with this kind of question, it's important to understand who you're building for and what you're trying to solve or deliver for them. Who is the setting for, and what does the setting afford?

One approach which is quite helpful is to map out the settings beforehand.

To do this, you could try the following:

  1. List of all of the settings & possible values in one column (eg: "SETTING A - value 1", "SETTING A - Value 2", "SETTING B - Value 1")
  2. In the next column, specify if the user MUST provide a value, or if there's a sensible default (hint: always have a sensible default if it can be done without harm)
  3. In the next column, summarize what benefit the setting+value gives - what does it offer
  4. In the next column, specify which persona that offer is for.

If any of those need to have multiple values in a column, duplicate the row and put one value on each row.

Once you've done this, try to simplify or normalize the columns created in step 3 a bit - so that you can see things like "Better X", "Easier Y" or "More Detail but more noise".

Then try sorting the rows by columns 3 or 4 and see what groupings emerge.

Example 1 - If you have 30 or 40 settings that relate to "More detail, but more noise" or "less detail, but less noise", you may be able to condense all of those settings down to a single slider.

Example 2 - If you have a bunch of values that Persona A always wants, and a different bunch that Persona B always wants... rather than presenting them all, present a switch that offers "(Persona A) Mode" or "(Persona B) Mode". If you really must allow for fine tuning for that one-user-in-a-thousand, punt them to an "advanced settings" page that makes it clear to the user that they're going outside the normal scope of use if they mess with them (like chrome's "chrome://flags" page).

Summing up: Don't try to present all of the settings individually. Instead, try to consolidate those settings into a smaller set of controls that afford access to sensible combinations of those settings.

Edited to Add: If no persona will ever benefit from a setting, don't offer it. Seems obvious, but still folks offer "never do this" options.

  • +1 for a well thought over answer and for adding a good method to eliminate unneeded options. Commented Feb 9, 2016 at 16:24

I really like what Eclipse does with the massive number of settings they support. Provide a tree view where settings are grouped logically, not just in groups but in an entire tree hierarchy, and (critically) provide a "quick search" way to filter down to the setting you care about. Eclipse settings

IntelliJ takes it a step further and actually highlights the matching settings. IntelliJ settings


Awesome answers so far. Reduce the number of settings, observe users to see what they need. Provide options in context.

If you need to split them into categories, you should really do a card-sort test. That will show you how users think of and cluster the settings in their own minds. From there you can create categories that make sense to your users.

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.