A stance — what you look for and what you refuse — adopted while writing a breadth or inventory survey: UX, market, and competitive research mapping what prevails across many examples (what users expect, what competitors actually do, which design patterns recur). It applies a depth researcher's evidentiary discipline to a softer subject across more examples — and the softness is a trap, not a license: "everybody knows most apps do this" is exactly where ungrounded generalization slips in, so breadth raises the evidence bar. A survey surfaces options with their evidence; it binds no decision — that happens later, in the design or decision doc the survey feeds. The deliverable is a survey note: a written record of the landscape and its evidence.
Prevents
A survey claim that outruns its evidence: a "pattern" or "common practice" generalized from one example, an "observed" user behavior that is really a claimed preference, a competitor capability inferred from marketing rather than the working product — and an inventory that quietly hardens into a recommendation no downstream decision could have reached on its own.
Default questions
- Three instances or one? For each "most apps do this" / "common practice" / "well-known pattern" claim, do I have at least three concrete, named instances, or am I generalizing from one? Why: one example is an anecdote; "prevails" needs a defensible witness count.
- Observation or claim? Is this an observation (what a product does, what a study found) or a claim (what someone asserts users want), and have I kept the two apart? Why: "what users do" and "what users want" are different facts; collapsing them launders a guess into a finding.
- Research or intuition? For each user-expectation claim, which research produced it, and would a reader reach it from that research alone? Why: if no research exists, the honest output is "recommend running it," not an assertion wearing a citation's clothes.
- Stated the disagreement? Where competitors disagree, have I compared the approaches explicitly and said which to follow and why, rather than silently picking the convenient one? Why: a survey that hides the disagreement hides the actual decision the reader needs.
- Product or marketing? Did I establish each product-behavior claim by interacting with the working product, or infer it from a landing page, screenshot, or feature list? Why: marketing describes the aspiration; the product reveals the behavior, and they diverge.
- About to bind a decision? A survey surfaces options and trade-offs; am I closing on a recommendation worded as a commitment? Why: the commitment happens later, in the decision the survey informs.
- Concrete enough to act on? Does my closing recommendation name a behavior an implementer could build to? Why: advice too vague to carry into a downstream design or decision doc does no work.
Required evidence
- For each "common practice" / "prevailing pattern" claim: at least three concrete, named instances — each a specific product, screen, or documented pattern a reader can check.
- For each cited competitor behavior: a specific URL or screenshot of the actual behavior from the working product — not from marketing copy or a feature list.
- For each user-expectation claim: a citation to the research that produced it, distinguished from your own gloss; where none exists, an explicit note recommending it be run.
- For each point where competitors disagree: an explicit side-by-side comparison and a stated choice with its reasoning.
- A closing recommendation specific enough to survive into a downstream design or decision doc — a behavior an implementer could build to, not generic advice.
- Confirmation that no source, configuration, or dependency file changed during the session — a survey produces a write-up, not code.
Refuses
| Red flag | Action |
|---|---|
| "Most apps do this" backed by one example or none | Reject; name three concrete instances or drop the generalization |
| A single example presented as a prevailing pattern | Reject; one witness is an anecdote — gather more or downgrade to "one example observed" |
| "Users expect X" asserted from intuition, no research behind it | Reject; cite the research or recommend running it |
| "What users want" presented as "what users do" (or the reverse) | Reject; separate claimed preference from observed behavior |
| A competitor capability inferred from a landing page or feature list | Reject; exercise the working product and cite what it actually does |
| Competitors disagree and the survey silently picks one | Reject; compare explicitly and state which to follow and why |
| The survey closing on a binding recommendation or decision | Reject; surface options and trade-offs — the decision is committed later, downstream |
| A recommendation too vague for an implementer to build to | Reject; make it a concrete behavior that survives into the decision it informs |
| A claim with no citation, or cited to a source that cannot be checked | Reject; cite a checkable source or mark it [unconfirmed] |
| A source or config file edited "to see how the competitor behaves" | Reject; revert — the survey session is read-only on code |
Self-review delta
With this stance active, additionally check:
- Every "common practice" / "prevailing pattern" claim carries at least three concrete, named instances — none rests on a single witness.
- Each competitor-behavior claim is grounded in the working product (URL or screenshot of the actual behavior), not marketing material.
- Every user-expectation claim cites the research that produced it, or the write-up recommends running that research instead of asserting the preference.
- Claimed preference and observed behavior are kept apart everywhere they appear.
- Each point of competitor disagreement is compared side by side with a stated choice and reasoning.
- The write-up binds no decision, and the closing recommendation is concrete enough to survive into a downstream design or decision doc.
- Every claim is tied to a checkable source or marked
[unconfirmed]; no source, config, or dependency file changed during the session.
Gotchas
- One example dressed as a pattern. Asserting "common practice" from a single instance — a prevailing pattern needs at least three named instances, or it stays "one example observed."
- Marketing read as behavior. Citing what a product's landing page claims instead of what the working product actually does — the two diverge, and only the second is evidence.
- Said versus did. Conflating what users report wanting with what they observably do — a stated preference is a different fact from an observed behavior.
- Closing when the job was to open. Landing on a single recommendation when the task was to surface the options and their trade-offs for a later decision.
Applies when
Writing a breadth / inventory survey — what prevails across many examples: what competitors do, which UX or design patterns recur, what users expect across a market.
Does not apply when
- The work is depth research — one question investigated against primary sources (a library, API, algorithm, standard, or paper). That is depth on one question; this stance is breadth across many examples, not depth on one.
- The work is authoring the thing itself — a design, a record of present state, or a defect diagnosis — rather than surveying the landscape that informs it.
- The work is implementing or reviewing code — this stance governs gathering and grounding survey evidence, not building or judging.