Observation

Origin & evolution

The split between recording and interpreting is old, anchored in the ethnographic tradition of dense, neutral field notes written in the moment. Its modern product form comes from Tomer Sharon's atomic research, developed while he was head of UX at WeWork, where the team built a research repository called Polaris around a single reusable unit. Sharon set out the model in Foundations of atomic research (2018): break findings into nuggets, each a tagged observation supported by evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →, so a study stops being a report no one reopens and becomes a queryable store of single experiences.

Holtzblatt and Beyer's Contextual Design formalised that discipline as a structured research method: the researcher observes and interviews a user inside their actual work environment, and only afterward does the team convene in a separate interpretation session to build shared models from the raw field notes. The method makes the boundary between the two steps explicit and procedural, so no observation gets silently promoted into a conclusion during data collection.

A useful subtlety runs through Sharon's writing. In his early framing an observation carries both a what and a why, and it is the why that lifts a bare fact into something a team can use. Later atomic-research practice tends to keep the raw observation and the interpretation as separate, linked records, so the same observed event can support more than one reading and a shaky inference never gets mistaken for the data underneath it. Both camps agree on the order of operations: capture first, interpret second, and keep the join visible.

The opposing trap has a name in critical thinking, the ladder of inference: a person climbs from a thing observed to a meaning assumed in a single unnoticed step, then defends the meaning as if it were the fact. Recording observations as their own layer is the brake on that climb.

How it works in practice

During eight moderated sessions for an expense app, the researcher logs flat statements: "Participant 4 opened the camera, photographed the receipt, then reopened it twice before submitting." "Participant 6 said, 'I don't trust it caught the total.'" No conclusions yet, just twelve such notes, each tagged with the participant, the task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, and a timestamp into the recording. Only in synthesis does the pattern surface: six of eight users re-checked the captured total, and the inference, that the scan gives no confirmation users believe, is now written as its own node pointing back at the six observations that support it. Because the raw records survive, a sceptical stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → can replay the exact moments rather than take the conclusion on trust.

Observation vs. its neighbours

• Inference is the explanation laid over an observation, the leap from "re-checked the total twice" to "users distrust the scan." The observation is what occurred; the inference is a reading of it that could be wrong. Keeping them separate lets a weak inference be revised without losing the underlying fact.
• Insight🔦InsightUser ResearchA synthesised finding from researchView reference → is a synthesised, recurring understanding drawn from many observations across studies, durable enough to steer decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. A single observation is one data point; an insight is the pattern that several of them justify.
• Quote is the verbatim words a participant used, often the evidence attached to an observation. The observation can record a behaviour with no speech at all, while a quote is specifically the recorded language.

In the graph

In the Unified Product Graph, an observation is the atomic datum of the User Research region, and the structure enforces the capture-before-interpret discipline. A study collects observations through research_study_captures_observationResearch StudycapturesObservationhierarchy, and inbound signal becomes one through customer_feedback_creates_observationCustomer FeedbackcreatesObservationcross-domain, so a stray support ticket🆘Support TicketCustomer SuccessCustomer support request or issueView reference → lands as evidence rather than opinion. Each observation can be backed by exact words via observation_evidenced_by_quoteObservationevidenced byQuotehierarchy, keeping the proof one click away. Forward links carry the interpretation as separate steps: observation_reveals_needObservationrevealsNeedcross-domain connects an event to the requirement it exposes, and observation_characterises_personaObservationcharacterisesPersonacross-domain ties recurring behaviour to the user it describes. The reading always traces back to something genuinely seen or heard.