Clarifying Ambiguity

Why Ambiguity Is Structural, Not Accidental

Design prompts are underspecified on purpose — both in interviews and in real kickoff meetings. The ambiguity is the test: does the designer probe before building? A precise-sounding design built on unexamined assumptions is architecture fiction.

 PROMPT: "Design a ride-sharing app"

 HIDDEN DECISIONS ALREADY BURIED INSIDE:
 - ride-sharing... which country? cities or suburbs? (affects geo tech)
 - app for whom — riders only, or drivers too?
 - scale: 1k users or 100M?
 - real money involved? (payments change everything)
 - new system, or replacing an existing one with data to migrate?

 none of these have a "correct" answer — but each has a WRONG-IF-ASSUMED-SILENTLY answer

The Clarifying Checklist

Six question families cover most hidden decisions:

Family	Questions	Why it matters
Users & scale	Who uses it? DAU now / in 2 years?	Selects entire scaling strategy
Geography	One region or global? Cities dense or sparse?	Geo-indexing, residency, CDN
Read/write character	Which dominates? What spikes?	Cache vs write-path investment
Consistency needs	Where must data be exactly right? Money? Counts?	Store and replication choice
Latency expectations	What’s interactive? What’s batch-tolerant?	Sync vs async split
Constraints	Team size? Budget? Existing stack? Compliance?	Kills/justifies complexity

Asking three to five sharp ones beats interrogating all twenty — target the ones that would change the design.

Assume-and-Declare: The Working Contract

Interviews don’t have time for full SRS elicitation. The professional move is assumption with a signature:

 WEAK:    (silently assumes 10M users, draws boxes)

 STRONG:  "I'll assume consumer riders + drivers, 10M DAU,
          dense urban markets, US-first. That gives me roughly
          20M trips/day to design against — correct me if the
          actual number differs by an order of magnitude."

Declared assumptions become checkable. If wrong, only the numbers shift; if silent, the whole design is silently wrong.

Ambiguity Classes and Their Handling

Ambiguity type	Handling
Missing scale	Assume from product category analogs, state it
Missing geography	Default single-region first, note expansion seam
Vague quality (“fast”)	Propose concrete target (“p95 under 300ms OK?”)
Conflicting requirements	Surface collision explicitly, ask which wins
Scope creep mid-design	Park it visibly (“out of scope v1, noted”)

The pattern across every row: convert fuzzy input into explicit, numbered, falsifiable statements.

Interview Framing

The first five minutes exist for this. High scorers ask questions whose answers they can already use (“Is read-heavy OK to assume? — then I’ll plan caching around it”), demonstrating that each answer lands somewhere in the design. Questions asked purely for show, with no architectural consequence, waste the clock — interviewers notice both directions.