Feature bloat for designers: the hardest no is the one the user thanks you for

Your advantage is the mock. A PM can describe a feature in words. An engineer can write a spec. A designer can show what the product looks like without the feature and with it. That comparison is the most honest representation of the cost of adding something, and it is a tool only the designer can produce.

Mock the product without the feature first. Show the screen as it is today. Then show the screen with the feature added. The comparison often reveals things the words concealed: the feature requires a new tab, which makes the navigation harder. The feature requires a new settings page, which makes onboarding longer. The feature requires a new modal, which interrupts a workflow that was previously frictionless.

The mock without the feature is not a strawman. It is the baseline. Show it first, genuinely, as the thing you are comparing against. Then show the mock with the feature. Ask: is the added complexity worth the value this delivers? Often, when the people who requested the feature see it designed rather than described, the answer is no.

This is the designer's most powerful contribution to the feature-bloat conversation: making the cost visible before the commitment is made. The words 'we can add a toggle for that' cost nothing. The mock that shows what the settings page looks like with 40 toggles costs the conversation.

Progressive disclosure is the design principle of showing only the information and controls needed for a task, revealing more detail when the user requests it or demonstrates readiness. It is a legitimate and powerful technique. It is also the way bloat hides.

The real technique: the information or control that is hidden by progressive disclosure is genuinely secondary. The user who wants it will look for it. The user who does not want it will never notice its absence. The hidden information does not affect the primary task. Examples: advanced settings in a developer tool, secondary sort options in a table, verbose error details in a user-facing error message.

The fig leaf: progressive disclosure is used to make a feature 'less obtrusive' rather than to remove it. The feature is bad for the default experience, but instead of removing it, it is moved behind a disclosure. Users who do not need it do not see it. Problem solved. Except the feature is still in the product, still maintained, still documented, still in the test suite. Progressive disclosure made it invisible to users. It made it invisible to nobody else.

The diagnostic question: if you removed this feature entirely, would the users who currently use it complain? If the answer is 'it is used by fewer than 3% of users and they rarely interact with it,' hiding it behind progressive disclosure is not a solution. The solution is removal.

Don Norman's principle from The Design of Everyday Things: good design makes the right actions obvious. Applied to settings and configuration: the right default is the design decision. The toggle is the design failure.

Every configurable option in a product is a decision the designer did not make. Instead of deciding what the right behaviour is, the designer (or the PM) created a setting and transferred the decision to the user. This transfers cognitive load from the product to the user, which is the opposite of what good design does.

Basecamp's approach, documented in Getting Real (37signals, 2006): make one decision, make it well, make it the default. Give users the ability to override the default only for settings where the override is genuinely meaningful and where a significant portion of users will need it. Not every user who wants a different colour scheme needs a setting. Not every user who wants different notification behaviour needs a setting. Most of the time, the right default satisfies most users, and the configuration option for the rest is not worth the cognitive load it imposes on everyone.

The practical application: audit your settings page. For each setting, ask: what percentage of users have this set to non-default? For settings where fewer than 5% of users deviate from the default, ask whether the setting belongs in the product at all, or whether the right response is to change the default to match what 95% of users actually want.

Jobs-to-be-Done (JTBD) is a framework for understanding why people use products, developed by Clayton Christensen and refined by Tony Ulwick. The core insight: people do not buy products; they hire them to do a job. The job is the unit of analysis, not the product feature.

Applied to feature-bloat conversations: the JTBD reframe moves the conversation from 'should we build feature X?' to 'what job is this user trying to do, and is feature X the best way to help them do it?' This reframe is politically useful because it does not say no to the feature; it says 'help me understand the job first.'

In practice: a stakeholder requests a feature. Instead of discussing the feature, ask 'what is the user trying to accomplish when they would use this feature?' The answer is often a job that the product is already serving imperfectly, where improving the existing flow would accomplish the same thing as adding a new feature. The JTBD reframe expands the solution space and often reveals that addition is not necessary.

Christensen's original formulation: 'People don't want a quarter-inch drill. They want a quarter-inch hole.' The feature is the drill. The job is the hole. Designers who can keep the conversation on the hole are designers who can prevent a lot of drills from being added to the toolbox.

Every six months, a designer should run a UI audit: a systematic review of every screen, every modal, every settings page, every onboarding step. The purpose is to surface bloat visually, before the product team has committed to removing anything.

The audit deliverable is not a recommendations document. It is a visual inventory: screenshots of every screen, annotated with the number of interactive elements per screen, the percentage of screen real estate used by elements that are primary versus secondary versus rarely used. This visual inventory makes bloat visible in a way that usage data alone cannot.

The most useful output: a side-by-side comparison of the same screen from 12 months ago and today. The features that have been added are visible. The navigation changes are visible. The growth of the settings page is visible. This visual diff is a more convincing case for simplification than any spreadsheet of usage data, because it shows what the product now looks like to a first-time user compared to what it looked like before.

Tools: screenshots plus Figma overlays for the diff. The audit takes a day for a medium-sized product. The conversation it enables is worth the day.