Should software reduce choices or allow as many choices as possible?

Balancing choice fatigue and user agency

You’re designing a piece of software. You have a choice. Should you reduce options to guide the user through a narrow path? Or should you embrace flexibility and allow as many user choices as possible?

It’s a classic tension in interface design. A balance with no universal answer. But it helps to think through both sides.

## The case for fewer choices

Reducing decisions means reducing friction. Every additional decision the user has to make adds a bit of weight. That weight adds up. Decision fatigue is real, especially in contexts where people interact with the software repeatedly.

Fewer choices also make things faster. Hick’s Law says: the more options, the slower the decision. If speed and ease are goals, pruning choices help.

There’s also elegance. Simplicity is a value (“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away” and all that). Interfaces bloated with options often feel cheap or unintentional. Featuritis creeps in. More inputs, more branches, more state. You now have to support every combination of user-defined settings. This isn’t just inelegant—it’s expensive. And error-prone.

When you limit choices, mapping (action → effect) stays simple. When you increase choices, mapping gets fuzzy. What should the software do when the user changes step order, color themes, tool behaviors, and everything else? Mapping breaks. Or becomes a full-time design job.

So: fewer choices. Fewer bugs. Less code. Fewer decisions for users. Clean. Efficient.

## The case for more choices

But… customization is power. Power users expect it. For serious workflows, the tool must adapt to the user—not the other way around. Look at productivity software: all the big players allow massive amounts of customization. I'm convinced that you couldn't penetrate that market with any other approach.

Customization is a kind of accessibility. It helps people shape the software to their needs. That’s partly about efficiency. But it’s also about control. Intrinsic motivation is higher when people feel like they’re steering. The IKEA effect applies: people value things they’ve helped shape.

This is especially true over time. A novice user doesn’t need choices. But as they gain experience, they do. They want to go faster. They want to bend the tool. And they can—if the tool allows it. This is the “novice to expert” progression in UI design. A good interface supports both.

That’s why End-User Programming is celebrated: it allows real ownership. And part of the current dissatisfaction with software is that it’s becoming less customizable. Simpler, yes—but also more locked down.

## Somewhere in between

A common suggestion here is progressive disclosure. Hide complexity until the user needs it. Show the simple path. But keep the back doors open.

Another lens: don’t ask whether to reduce or multiply choices. Ask: who is the user? What do they need to do? How often? What is their relationship with the tool?

Some tools should feel like a toaster. Some should feel like Emacs.

Design accordingly.