Customising without complicating: UX for modular products

Customisation has become a common promise in many digital products. Being able to choose how to organise information, which modules to use, which features to activate or how to adapt the interface may seem, in principle, like an obvious improvement to the experience.

The problem arises when that flexibility forces users to make too many decisions before they have even understood how the product works.

Being able to adapt a tool is one thing; having to configure it from scratch before getting any value from it is quite another. When every initial step requires choosing between multiple options, defining preferences, setting permissions or deciding between different ways of using it, customisation stops feeling like an advantage and begins to feel like work.

This creates a paradox: users value having control, but they do not necessarily want to exercise it all the time. They want to know they can change things when they need to, rather than being forced to decide everything from the outset.

What is more, more options do not always create a greater sense of freedom. They often create uncertainty, slow down decision-making and increase the fear of making the wrong choice. The less familiar users are with the product, the less prepared they are to understand the consequences of each configuration.

That is why designing a customisable experience is not simply about adding controls. It is about deciding what should already be resolved, what can be changed later and which options should only appear when there is a genuine need.

Flexibility is useful when it supports the user. When it is presented too early or without context, it only exposes the complexity of the system.

When internal modularity takes over the interface

Many digital products are built from modules, permissions, rules, integrations and layers of configuration. That architecture may be necessary to make the system scalable, flexible and capable of responding to different use cases.

The problem arises when all that internal complexity is transferred directly to the interface.

Instead of encountering understandable tasks, goals or outcomes, users encounter module names, technical parameters, hierarchical structures or dependencies that only make sense to the people who designed the product. The experience ends up reproducing the logic of the system, rather than the logic of the person trying to use it.

This happens, for example, when completing a simple action requires several features to be activated beforehand, permissions to be defined, ambiguous categories to be chosen or the relationship between different sections to be understood. Users not only have to learn how to use the product: they also have to decipher how it is built.

In these cases, modularity stops being an invisible advantage and becomes a visible burden.

A good interface should not require people to understand the technical architecture in order to carry out an everyday task. It can rely on a modular structure internally, but it should translate it into clear decisions, understandable journeys and actions linked to specific goals.

This is not about hiding important information, but about presenting it with the appropriate level of detail. Technical concepts can still exist, but they should not take centre stage in the experience if they are not needed to move forward.

Modularity belongs to the product architecture. Simplicity, on the other hand, belongs to the user experience. Confusing the two often produces tools that are very powerful, but unnecessarily difficult to use.

Starting with an experience that already works

One of the best ways to reduce complexity in modular products is to avoid making users build their experience from scratch.

When someone first enters a tool, they do not yet know its possibilities well, do not know which configuration will suit them and can hardly anticipate how each decision will affect their way of working. Asking them to define all the modules, permissions, views and preferences from the start means placing a responsibility on them for which they do not yet have enough context.

That is why the starting point should be an experience that is useful from the very beginning.

Default values, recommended configurations and initial journeys are not minor decisions. They work as an initial proposal for use: they show how the product can be organised, reduce the number of choices required and allow users to learn as they move forward.

A good initial state does not have to be perfect for everyone, but it should be sufficiently clear and functional for most people. It may include a basic structure, a sensible selection of modules, a ready-made view or examples that help users understand the potential of the tool without having to configure every detail.

This does not eliminate customisation. It moves it to the point when it genuinely makes sense.

As users become more familiar with the product, they can adapt the experience, replace options, reorganise elements or activate more advanced features. The difference is that they are no longer deciding blindly, but based on a specific need.

Designing good default values also means taking responsibility. The product team must make decisions, prioritise scenarios and propose an initial way of using the product, rather than leaving every possibility open for fear of being limiting.

A modular experience works better when it first demonstrates its value and then offers depth. Users should be able to start by using the product, not by designing it.

Presets and modes

When a product offers many configuration possibilities, an effective way to reduce decision-making burden is to group them into understandable presets or modes.

Rather than asking users to adjust a long list of parameters, the system can offer them a choice that is closer to their goal: working quickly, collaborating with a team, prioritising control, simplifying the view or activating advanced features.

The difference is important. Parameters describe how the system works. Presets explain what it can be used for.

A good preset translates technical decisions into a recognisable proposal for use. It may automatically configure views, permissions, modules or automations, but users do not need to understand every setting from the outset. What they need is to know which option best fits their situation.

Modes serve a similar purpose when there are clearly differentiated ways of working. A guided mode, for example, can support those who are just starting out, while an advanced one offers greater control to more experienced users. There may also be modes oriented towards specific tasks, such as editing, presenting, analysis or collaboration.

However, these solutions only simplify things when they are well defined.

If the names are ambiguous, if there are too many variants or if changing mode completely transforms the interface without explanation, the problem reappears in another form. Users stop choosing between parameters, but still do not understand the consequences of their decision.

That is why presets and modes should respond to real needs, clearly show what changes and allow later adjustments. It is also worth avoiding their becoming closed configurations. Their value lies in offering a starting point, not in imposing a single way of using the product.

Grouping options does not mean hiding complexity without judgement. It means organising it around goals that users can recognise and understand.

Progressive simplicity

Simplifying an interface does not mean removing features or hiding them arbitrarily. It means deciding when users need to see them and in what context they can understand them best.

In a modular product, not all options have the same importance or are used with the same frequency. Some are essential for completing an everyday task; others are only useful in specific situations; and others are intended for advanced users who need a greater level of control.

Showing all these possibilities at the same time places every decision on the same level, even though in practice they are not. The result is usually a dense interface, difficult to navigate and full of controls that most users barely use.

Progressive simplicity makes it possible to organise that complexity in layers.

Essential controls should be visible and easy to recognise. They are the actions that allow users to progress and form part of the product’s usual use. Contextual options, on the other hand, can appear when users are working on a particular element or carrying out a task for which they are genuinely relevant. Advanced features can remain accessible without permanently occupying the centre of the experience.

For example, there is no need to show all the configuration options for a table before the user has created one. It makes more sense to present controls for sorting columns, applying filters or changing the display within the table itself, when those decisions have an immediate and understandable effect.

This approach also makes learning easier. Rather than having to understand the whole product from the beginning, users discover new possibilities as they need them. Each feature appears associated with a specific action, problem or goal, making its usefulness easier to understand.

However, progressive simplicity should not become a constant search for hidden features. Options need to be discoverable, follow consistent patterns and appear in predictable places. Hiding things without judgement may reduce visual noise, but it can also create frustration and make the product seem more limited than it really is.

The aim is not to show less as a principle, but to show things better. A modular interface works when it presents each level of control at the right moment, without overwhelming those who are starting out or limiting those who need to go further.

Customisation with limits, context and reversibility

Allowing users to adapt a product does not mean turning every element into an open decision. In fact, an experience that is too configurable can be just as difficult to use as a rigid interface.

Not everything needs to be customisable. Some decisions should remain stable to protect accessibility, security, performance, visual consistency or data integrity. Leaving these aspects entirely in users’ hands can create inconsistent experiences, errors that are difficult to identify or configurations that hinder the use of the product.

That is why designing customisation also means setting limits.

These limits should not be perceived as arbitrary restrictions, but as a way of guiding the experience. Users can choose between relevant options, but within a framework that keeps the product understandable and reliable. Flexibility works best when there is a solid foundation that does not change constantly.

Context matters too. Many decisions are better understood in the place where they have their effect. Changing the display of a chart from the chart itself, reorganising a table from its columns or adjusting a notification from the message received feels more natural than searching for each option on a long settings page.

In addition, users should be able to anticipate what will happen before confirming a change. Previews, examples and summaries help them understand the consequences of a configuration without having to try it blindly.

This sense of security increases when decisions are reversible. Being able to undo a change, restore default values or recover a previous configuration encourages exploration and reduces the fear of making mistakes.

The sense of control does not depend solely on being able to change something. It also depends on knowing that the change is not final and that the system will allow users to go back if the outcome is not what they expected.

Well-designed customisation offers freedom, but does not leave users alone in the face of every possibility. It defines reasonable limits, places decisions in context and allows people to experiment without fear of breaking the experience.

Conclusion

Modularity can make a product more flexible, scalable and useful for very different types of user. But that internal richness should not become a constant obligation to configure, choose and understand how the system is built.

The best customisation is not about exposing every available possibility. It is about offering a clear initial experience, allowing users to move forward without friction and opening up new levels of control when there is a genuine need.

That requires decisions to be made in design and product. Defining good default values, grouping options into understandable presets, introducing features progressively and setting limits that protect consistency, accessibility and security.

It also means accepting that customising does not always mean adding more controls. Sometimes it means resolving the essentials more effectively, reducing unnecessary decisions and placing each option at the right time and in the right context.

A modular product should not ask users to understand its entire architecture in order to use it. It should translate that complexity into simple journeys, clear decisions and a genuine sense of control.

Ultimately, adapting an experience well means allowing each person to find their own way of working without requiring them to first design the product they need.

How many decisions does a user have to make today before they begin to get value from your product?