Feature Budget¶
Procedure — instantiates Complexity Budgeting
Sets a standing cap on how many user-facing features, options, or screens a product may carry, pegged to what its intended users can actually comprehend and use.
A Feature Budget is a standing numeric cap on the user-facing surface of a product — how many features, options, toggles, screens, or workflow branches it may carry or add in a cycle — set at the level its intended users can actually comprehend. The one idea that makes it this mechanism is that its ceiling is a product-usability ceiling: complexity is charged in units of user-facing surface, and the binding constraint is human cognitive load, not engineering effort or maintenance burden. It is not a per-change gate and not a whole-project scope cap; it is a persistent limit on how much a user must hold in their head, enforced by making every candidate feature compete for a slot against what is already there.
Example¶
A consumer note-taking app is beloved for being fast to learn. The product team sets a Feature Budget to keep it that way: the settings screen may hold at most twenty toggles, and the main editor toolbar at most seven actions. A proposal arrives for a "custom theme engine" — user-configurable fonts, colors, and spacing. It is genuinely wanted by a vocal slice of power users, but it would push the settings screen to twenty-six toggles, and the team's own usability sessions show new users already hesitating at the current count. Under the budget, the theme engine cannot simply be added to the primary surface. It must ship behind an "Advanced" drawer that sits outside the counted surface, or wait for a future cycle. The team chooses the advanced drawer, and each candidate feature is also run through a quick impact check: does it change what users actually decide or do, or is it a preference that a handful of people would toggle once and forget? The outcome is a product that keeps its first-run simplicity while still serving power users — instead of drifting into the settings-screen-with-two-hundred-toggles fate that kills so many maturing apps.
How it works¶
- Pick the counted surface. Choose what is capped — toolbar slots, settings toggles, top-level screens, workflow branches — so the budget attaches to something users actually feel.
- Peg the cap to comprehension. Set the ceiling at the level usability evidence says intended users can navigate, not at what engineering can build.
- Enforce the cap by deferral. A feature that would breach the ceiling waits for a future cycle or moves off the counted surface into a secondary "advanced" area; the primary surface stays within the comprehension limit rather than growing.
- Impact-test each candidate. Before a feature spends budget, check whether it materially changes user value or behavior, so inert "nice to haves" do not consume scarce surface.
Tuning parameters¶
- Counted surface — which elements the budget tallies. A narrow count (toolbar buttons only) is easy to enforce but easy to evade by hiding complexity elsewhere; a broad count catches more but is harder to measure.
- Cap tightness — how low the ceiling sits. Tighter preserves simplicity but can starve legitimate needs; looser tolerates richness but invites slow bloat.
- Comprehension source — whether the ceiling comes from real usability testing or a designer's heuristic. Evidence-based caps are more defensible and costlier to maintain.
- Advanced-surface exemption — whether power-user features can move off the counted surface rather than being cut. Generous exemptions protect depth but risk becoming a dumping ground.
When it helps, and when it misleads¶
Its strength is that it fights creeping featurism directly and keeps a product legible to newcomers, defending the invariant that the system must remain usable by the people it is for.[n1] Its failure mode is metric gaming turned inward: a team keeps the counted feature list flat while complexity migrates into configuration, conditional behavior, and edge cases the count does not see, so the product feels simple on paper and baroque in use. The classic misuse is overcorrection — cutting features users genuinely rely on because the number looked high, mistaking a low count for a good product. The guarding discipline is to count the burden users actually experience rather than a convenient proxy, and to reserve budget deliberately for the few high-impact features that justify their surface.
How it implements the components¶
complexity_budget— the numeric cap on user-facing features is the budget, expressed in a countable surface.user_comprehension_limit— the cap is pegged to what intended users can comprehend and navigate, making cognitive load the binding constraint.decision_impact_test— each candidate feature is checked for whether it materially changes user value or behavior before it is allowed to spend budget.
It caps a product's standing feature surface at a comprehension limit and does not rank items by value to force lower-value ones out of a whole planning cycle (value_justification, pruning_rule) — that zero-sum, value-ranked displacement is its sibling Scope Budget — nor does it attach a back-out to each shipped change (rollback_path), which is Change Control Gate.
Related¶
- Instantiates: Complexity Budgeting — Feature Budget applies the pattern to user-facing product surface.
- Sibling mechanisms: Scope Budget · Change Control Gate · Design Complexity Review · Complexity Ledger · Assumption Budget · Maintainability Threshold
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Feature Budget operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it sets a standing cap on how many user-facing features, options, or screens a product may carry, pegged to what its intended users can actually comprehend and use.
Independent corroboration: The frozen evidence defines Feature Budget as 'Sets a standing cap on how many user-facing features, options, or screens a product may carry, pegged to what its intended users can actually comprehend and use', so its operative form is Rule, Policy & Commitment.
Nearest alternative: Protocol, Workflow & Routine — A declared feature ceiling is a standing constraint on future product growth; deferral and advanced-tier placement implement it.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Constraining visible options to user comprehension grows from usability and interaction-design practice.
Related originating lineages:
- Organizational & Management Science — Product portfolio and complexity-budget governance materially shape the standing cap.
- Psychology — Cognitive-load research materially grounds the notion of a bounded comprehensible surface.
Review resolution: Both reviewers agree that human_computer_interaction is primary. I retain organizational_management, psychology only as formative origin lineage(s), without treating every later application as an origin. cross_disciplinary_synthesis is appropriate because the exact artifact combines contributions from multiple professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
Feature Budget and Scope Budget both cap additions, but they answer to different masters. Feature Budget defends the user: its ceiling is set by what a person can comprehend, and it persists across cycles as a standing property of the product. Scope Budget defends the plan: its ceiling is a fixed effort envelope for one release or project, and it forces value-ranked displacement to fit. A feature can be within the plan's scope and still blow the comprehension cap — which is exactly when a product ships on time and still confuses everyone.
[n1] Feature creep (also "creeping featurism") is the well-documented tendency of products to accumulate features until the added surface degrades usability faster than it adds value. A feature budget is the standard structural defense: make the surface a scarce, capped resource rather than an open one. ↩