Component Simplicity & Unobtrusive Design

Statement

Keep components simple, focused, and out of the user's way.

What this means in practice

UI components do one thing well and stay invisible until needed. Complexity is pushed out of the component layer, not hidden inside it.

• Each component has a single, clear responsibility and a minimal public API.

• Visual noise is reduced by defaulting to restraint — fewer borders, shadows, colours, and animations unless they serve a clear purpose.

• Components are composable rather than monolithic; small, predictable pieces combine to form complex interfaces.

• Interactive elements behave consistently and predictably, avoiding unexpected side effects.

• Progressive disclosure is preferred over overwhelming the user with every option upfront.

• Styling follows established design tokens and patterns rather than one-off overrides.

Why this matters

Simple components are easier to build, test, reuse, and maintain.

• Complex components accumulate edge cases that slow delivery and introduce bugs.

• Cluttered interfaces increase cognitive load and reduce task completion rates.

• Monolithic components resist reuse and create duplication across the codebase.

• Inconsistent behaviour erodes user trust and increases support burden.

• Teams move faster when the component library is predictable and well-bounded.

Practices that meet this principle

• Limit each component to a single responsibility; extract sub-components when complexity grows.

• Keep prop surfaces small — prefer sensible defaults over extensive configuration.

• Use design tokens (spacing, colour, typography) consistently rather than ad-hoc values.

• Apply progressive disclosure: show primary actions first and reveal secondary options on demand.

• Avoid decorative elements that do not aid comprehension or navigation.

• Favour native browser behaviour and standard interaction patterns over custom implementations.

• Document component purpose, expected usage, and constraints in the component library.

• Review new components against existing ones to prevent duplication.

Validation

A project meets this principle when:

• Components have a clearly documented single responsibility and a concise API.

• The UI feels clean and uncluttered, with whitespace and hierarchy guiding the user's attention.

• Design tokens are used consistently, with minimal one-off style overrides.

• New components are reviewed for overlap with existing library entries before merging.

• User feedback and usability testing confirm that interfaces are intuitive and not overwhelming.

• Component complexity (prop count, internal state, conditional branches) is actively managed and reviewed.

Potential blockers

• Legacy components with broad responsibilities that are costly to refactor.

• Pressure to ship quickly, leading to "just add another prop" shortcuts.

• Inconsistent or incomplete design system documentation.

• Lack of shared agreement on what constitutes "simple enough".