Loading…
Loading…
The simplest solution is usually the best.
stellae.design
Given competing design solutions, the simplest one that solves the problem is usually the best. Unnecessary complexity creates unnecessary failure points.
Among competing hypotheses or designs, the one with the fewest assumptions — the simplest adequate solution — should be preferred. Every element that does not serve a clear purpose introduces potential confusion, maintenance burden, and cognitive load.
Focused checkout with essential fields only
Only asks for what's needed, with optional fields clearly marked
Checkout requiring 20 fields including fax number
Unnecessary fields adding friction and complexity to a simple task
Complexity compounds over time. Every extra feature, animation, or interaction path must be learned by users, maintained by developers, and tested by QA. Simpler designs are faster to build, easier to use, cheaper to maintain, and more resilient to edge cases. Occam's Razor is a forcing function for design discipline.
Google's search page is one of the most visited pages in the world and consists almost entirely of a single input field and two buttons. By stripping away everything that does not serve the core task — searching — Google removes all friction from the primary user journey. The simplicity is the product's greatest feature.
Apple's original single-button mouse simplified pointing input to its absolute minimum. While initially praised for learnability, the lack of a right-click eventually forced users into awkward modifier-key workarounds for common tasks. This illustrates the line between elegant simplicity and harmful oversimplification.
Basecamp deliberately limits its feature set compared to competitors like Jira or Asana. By offering to-dos, messages, and schedules without complex workflows, they serve teams who find traditional project management tools overwhelming. The constraint is intentional and serves a specific audience's needs.
Stripe's payment API requires just a few lines of code for a basic integration, hiding enormous complexity behind a clean interface. Developers can go live quickly with the simple path, then progressively access more advanced features as needed. This layered simplicity is Occam's Razor applied to developer experience.
• Occam's Razor is sometimes used to justify removing features users genuinely need, confusing simplicity with minimalism. Others invoke it to avoid necessary complexity — not every problem has a simple solution, and oversimplification can create more confusion than it resolves. The razor is a tiebreaker between equally effective options, not a mandate to strip functionality.
| Check | Good Pattern | How to Test |
|---|---|---|
| Element justification audit | Every UI element on the page can be tied to a specific, documented user need or business goal. | Walk through each element on a screen and articulate its purpose. If you cannot justify it with user research or analytics data, flag it for removal or testing. |
| Feature cost-benefit analysis | New features are evaluated against the cost of added complexity, not just the benefit of new capability. | For each proposed feature, estimate ongoing maintenance cost, impact on learning curve, and testing burden. Compare against the projected user value. |
| Competing solution comparison | When multiple solutions exist, the team evaluates complexity as a primary selection criterion alongside effectiveness. | In design reviews, require at least two alternative approaches per feature and score them on simplicity. Choose the simplest that meets acceptance criteria. |
When the simpler solution fails to adequately solve the problem — for instance, a simple search box that cannot handle the complexity of a domain-specific query language that expert users need. Necessary complexity should be embraced, not avoided.
Was this article helpful?