Where is the best place for settings in a product with a lot of them?

Question

Suppose you have a software product with five modules. Each module has its own settings to configure. There are also settings around admin functions like User Account Setup.

The settings won't necessarily need to be configured by someone in an admin role, though an Admin will be able to see and configure all settings. (Example: A finance manager can edit settings in a Finance module, but not an Auditing module.)

Some of the module settings might need to be adjusted frequently based on pattern observation (example: auditors setting thresholds for fraud detection), while other settings will be "set it and forget it".

Where is the best place for settings to managed?

1. Place them as close as possible to user tasks? For example, settings for Module A are configured in Module A, settings for Module B are configured in Module B, and maybe there's a small Application Settings section for everything that's not specific to a module? This could create a logical, convenient place for configuration tasks. It could also be a nightmare for an Admin who would have to memorize where various settings are stored.

2. Use one settings section for everything? The advantage is that the user always knows where to go when they need to configure something. The disadvantage is that it might be less-than-ideal for a user who is frequently tweaking module settings.

3. Place most "set it and forget it" settings in a Settings section, regardless of their module, but allow smaller sub-sets of settings for the frequently adjusted ones? This seems like the most user-flow-based approach, but I get nervous about providing ambiguous places where users might look to do things.

Or, is there a better approach for this?

Answer 1

The solution definitely depends on how close modules are related to each other from interface and architectural points of view.

If integrated module is just one item in application's main menu and is perceived by user as a part of whole application it's better to have its setting under one application's Settings section.

If module acts like a kind of plugin to main application it will have common settings which it delivers to application's settings as well as its private settings. Look at modern browsers with their extensions for example, or VS Code and its plugins.

Another settings 'dimension' to take into account is having different individual settings for a kind of 'project' inside your application for one user or group of users.

So, first you need to build your application's settings hierarchy. Then think on users, roles and access rights to manage settings. Both things will help you to make final decision based on your application's structure, framework, interface and business model.

Answer 2

I would certainly place settings close to he user tasks. This exposes the settings in small quantities at the exact time the user might be interested to change it. Going to the big settings section and doing mental gymnastics trying to link the settings to their features is extra effort that will make many users not use the settings.

Sysadmins do not have to use the same user interface if they have a different use case. Expose a configuration file for them and they will be even more happy than just having settings in one location. As an example, see how VS Code or Sublime editors allow to tweak settings in a settings.json file in addition to the GUI.

Answer 3

In order to display overall settings as a top-level page/section, it's quiet useful to let users reach the sub-module settings within closest point to where user tasks exist.

By presenting a top-level settings page with a discrete section for each mentioned tabs above (like sub-modules, admin, configuration, etc.) it's obvious for users to think about where to look at as a fallback when they feel like lost.

It's also possible to keep users engaged while they're dealing with the product, via displaying frequently used settings at a closest point to the user task (suppose module here).

Bonus: Letting users configure which setting params to be showed next to the user task is far more best approach in terms of providing user-centered approach. By letting users change if whichever setting param they're used to be on their own within a seperate top-level settings section, it's possible to gain more KYC (know your customer) data.