Implicit requirements

Implicit requirements are the expectations users have that they never explicitly state-often because they consider them so obvious that stating them feels unnecessary. These include basic functionality that "just should work," quality attributes like reasonable performance, and adherence to platform conventions. Users don't request that buttons be clickable or that pages load in under ten seconds; they assume it.

Why implicit requirements matter

Missing implicit requirements causes disproportionate user frustration. When explicit requirements are unmet, users may be disappointed but understanding-at least the limitation was visible. When implicit requirements are violated, users feel the product is fundamentally broken.

Consider a note-taking app that meets all documented requirements but takes 30 seconds to save. No requirement document said "saves quickly"-that was implicit. Users will abandon the app despite it technically meeting all specifications.

Types of implicit requirements

Basic functionality. Core behaviors so fundamental they're never specified: forms submit when you click the button, data you entered persists, back buttons go back.

Platform conventions. Following established patterns for the platform: iOS apps should feel like iOS apps, web apps should respond to browser conventions.

Performance expectations. Reasonable response times, reliability, and availability. Users expect things to work, quickly, every time.

Security and privacy. Data should be protected, passwords shouldn't be visible, sensitive information shouldn't leak.

Accessibility. Products should be usable by people with disabilities, even if never explicitly specified.

Error handling. When things go wrong, users should understand what happened and how to recover.

Data integrity. Information entered shouldn't be lost, corrupted, or unexpectedly modified.

Surfacing implicit requirements

Since implicit requirements are unstated, they require active effort to identify:

User research. Observing users reveals expectations they'd never articulate. When they express confusion or frustration, implicit requirements are often involved.

Competitive analysis. What do competing products provide that users might expect? Implicit requirements often derive from market standards.

Platform guidelines. Apple, Google, and other platforms publish human interface guidelines that document many implicit expectations.

Testing with real users. Usability testing surfaces implicit requirements when users attempt tasks and encounter unexpected friction.

Support analysis. Support tickets about things that "should work" often identify implicit requirements that were missed.

Assumption audits. Explicitly ask: "What are we assuming users will expect that we haven't specified?"

Making implicit requirements explicit

For critical implicit requirements, making them explicit reduces risk:

Document assumed behaviors. Write down the behaviors you're taking for granted. This creates clarity and enables testing.

Define quality attributes. Specify performance targets, reliability expectations, and other non-functional requirements.

Create checklists. Standardized checklists for common implicit requirements (accessibility, security, error handling) catch gaps.

Include in acceptance criteria. For user stories, acceptance criteria can capture implicit requirements: "User sees confirmation within 2 seconds."

Reference standards. Point to established guidelines (WCAG for accessibility, platform guidelines for conventions) rather than reinventing definitions.

The kano model connection

The Kano Model categorizes features by customer response:

Basic needs - Expected. Users don't request these because they're assumed. Presence doesn't delight; absence frustrates.

Performance needs - Articulated. Users explicitly request these. More is better.

Delighters - Unexpected. Users don't know to ask for these. Presence delights; absence isn't noticed.

Implicit requirements map primarily to basic needs-the things users expect without asking.

Common implicit requirement failures

Slow performance. "It works" but too slowly. Users expected reasonable speed.

Missing undo. Users expect to recover from mistakes. Destructive actions without undo violate implicit expectations.

Inconsistent behavior. The same action produces different results in different contexts, violating expectations of consistency.

Poor error messages. When errors occur, users expect to understand what happened and what to do.

Broken fundamentals. Basic features-search, navigation, saving-that don't work reliably.

Platform friction. Web apps that fight browser behavior, mobile apps that ignore platform conventions.

Managing implicit requirements

Don't assume the obvious is obvious to everyone. What's implicit to users may not be implicit to the development team, especially for unfamiliar domains.

Test with representative users. Real user testing reveals violations of implicit expectations that internal review misses.

Create organizational knowledge. Document the implicit requirements for your domain and user base so new team members understand expectations.

Allocate time. Meeting implicit requirements takes effort even though they don't appear on requirement lists. Account for this in planning.

Tools like Klero surface implicit requirements through user feedback patterns. When users complain about things they never explicitly requested, they're revealing implicit requirements. Analyzing what users expect versus what was specified helps product teams anticipate and meet these unspoken needs.