A behavioural observation from research
An observation is the atomic record of what a researcher actually saw or heard, captured before anyone interprets it. A participantParticipantUser ResearchA person participating in researchView reference → clicks the wrong button twice; a customer sighs and says the export "never works." The discipline of an observation is to write down the event and nothing more, holding off the explanation that the mind rushes to supply. Most research goes wrong at exactly this seam, where what happened quietly becomes what we think it means.
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 evidenceEvidenceValidationData supporting or refuting a hypothesisView reference →, so a study stops being a report no one reopens and becomes a queryable store of single experiences.
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.
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 taskTaskProduct 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 stakeholderStakeholderTeam & OrganisationA person with influence over the productView reference → can replay the exact moments rather than take the conclusion on trust.
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 StudycapturesObservationhierarchy, and inbound signal becomes one through research_study_captures_observationCustomer FeedbackcreatesObservationcross-domain, so a stray support ticketSupport TicketCustomer SuccessCustomer support request or issueView reference → lands as evidence rather than opinion. Each observation can be backed by exact words via customer_feedback_creates_observationObservationevidenced byQuotehierarchy, keeping the proof one click away. Forward links carry the interpretation as separate steps: observation_evidenced_by_quoteObservationrevealsNeedcross-domain connects an event to the requirement it exposes, and observation_reveals_needObservationcharacterisesPersonacross-domain ties recurring behaviour to the user it describes. The reading always traces back to something genuinely seen or heard.observation_characterises_persona
Type-specific fields on BaseNode
contentstringNote or highlight text.
source_typestringProducing research method.
session_refstringCapturing session reference. Convenience field; the canonical relationship to study/session is an edge per P14. Retained as a lightweight context anchor for AI inference.
is_highlightedbooleanFlagged as a highlight. Absorbed from the deprecated Highlight entity.
highlight_tagstringFree-form highlight type tag. @example "pain", "delight", "behaviour", "moment of clarity"
sentimentstringStructured sentiment. Tools like Dovetail and EnjoyHQ converge on these four values. More precise than `highlight_tag` for aggregation.
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
10 edge types connected to this entity.
research_study_captures_observationobservation_evidenced_by_quotecustomer_feedback_creates_observationobservation_reveals_needobservation_characterises_personaobservation_yields_insightobservation_reveals_jobuser_flow_validated_by_observationobservation_informs_decisionjourney_step_yields_observation1 framework use this entity type.