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, when the survey is lifted into a
spec. Load it alongside the starter kit's write-research guide; the deliverable still
follows the kit template (advanced/research.md in a Swarm workspace).
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 spec could transcribe.
Default questions
- 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? (One example is an anecdote; "prevails" needs a defensible witness count.)
- Is this an observation (what a product does, what a study found) or a claim (what someone asserts users want)? Have I kept the two apart? ("What users do" and "what users want" are different facts; collapsing them launders a guess into a finding.)
- For each user-expectation claim: which research produced it, and would a reader reach it from that research alone — or is it intuition wearing a citation's clothes? (If no research exists, the honest output is "recommend running it.")
- Where competitors disagree, have I compared the approaches explicitly and stated which to follow and why — rather than silently picking the convenient one? (A survey that hides the disagreement hides the actual decision the reader needs.)
- Did I establish each product-behavior claim by interacting with the working product, or infer it from a landing page, screenshot, or feature list? (Marketing describes the aspiration; the product reveals the behavior, and they diverge.)
- Am I about to recommend a decision and bind it? A survey surfaces options and trade-offs; the commitment happens later, when the survey is lifted into a spec.
- Does my closing recommendation name a behavior concrete enough for an implementer to build to — or is it advice too vague to transcribe?
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 transcription into a spec — 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, in a spec |
| A recommendation too vague for an implementer to build to | Reject; make it a concrete behavior that survives transcription |
| 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 |
Before you finish
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 transcription into a spec.
- Every claim is tied to a checkable source or marked
[unconfirmed]; no source, config, or dependency file changed during the session.
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
write-researchon its own; this stance is breadth across many examples, not depth on one. - The work is non-research writing: a spec (forward-looking intent), an audit (present state), or a bug report (one defect) — each has its own guide.
- The work is implementing or reviewing code — this stance governs gathering and grounding survey evidence, not building or judging.