PMs and designers

Goal: Create a decision record that tells the next teammate what changed, why, and what still needs testing.

Before you start: Complete your first workspace and select a workspace where you are an editor or owner. This exercise uses the theme Product practice; creating another workspace is optional. You can complete all core steps without an AI connection.

Practice data

The content below is an invented exercise, not real research findings, customer interviews, approved business policies, or student records. Check rights and sharing scope when you replace it with real material.

Start from a decision with missing background

A designer asks why a first-step link was chosen. The interview note is in one file, the test idea is in a meeting note, and the requirements document says only “improve onboarding.” A new teammate cannot tell whether the change is a customer request, a hypothesis, or an approved decision.

This guide creates a small evidence chain for a clearer first-step entry point. It connects customer observations, a proposed experiment, and the decision rationale. Use the same pattern for a product requirements document (PRD), design review, or later iteration.

Separate evidence, proposals, and decisions

Material	Put it in	Record and check
Permitted interview notes, research exports, mockup files	Library	Date, study or design version, source; remove personal details before uploading
Observation and interpretation	Interview notes in Context	What a participant did or said; a separate hypothesis and sample limitations
Validation plan and actual result	Experiment log in Context	Test method, measures, status, and observations once a human runs it
Requirement and decision rationale	Launch decision in Context	User problem, alternatives, scope, owner, status, and links to evidence

“Proposed,” “not run yet,” and “approved” in these examples are text labels your team maintains. They are not automatic product delivery states.

Page links in this example

Launch decision links to Interview notes and Experiment log using wikilinks. The arrows show page relationships to create, not an automatic workflow or a product screen.

Create the three practice pages

1. Open Context → New Context page. Use the first two copyable templates below, entering each page title in the title field and its Markdown in the body.
2. For each page, choose Save draft, wait for saving, then Publish. This publishes for workspace readers; Publish to web is separate.
3. Create Launch decision last, using the third template. Its [[Page title]] links must match existing page titles in this workspace.
4. Open both links. If one does not resolve, check its title and workspace and select the existing target with the editor’s Wikilink command.

Markdown is ordinary text with headings and lists; these templates are notes, not software code. See Context pages and images and links for editing controls.

From an interview to a design handoff

After an interview: record what actually happened

Prepare an anonymized source in your normal research tool before Library → Upload. Use participant labels such as P01 and remove names, contact details, or sensitive customer data. Check Status and the extracted view; a screenshot has no built-in OCR promise. Preserve a checked text note for a relevant observation.

Open Interview notes → Edit. Write the observation first: “P01 looked in the top navigation before finding the guide.” Write “a clearer entry point may help” under interpretation, not as a quoted customer requirement. Include the interview date and source location. Save draft, check the evidence, then Publish the version colleagues should read.

During planning: make a requirement testable

In Launch decision, add a small table such as this:

Item	Practice entry
User problem	A first-time user cannot quickly find the first-step guide
Proposed requirement	Provide a visible route to the existing guide
Acceptance observation	A tester opens the intended guide without moderator help
Out of scope	Rebuilding the whole onboarding flow
Uncertainty	The wording and placement have not been tested

Connect the requirement to Interview notes and Experiment log with their existing wikilinks. In the experiment page, describe the proposed method before recording a result. Keep Not run yet until someone performs the test in the actual product or research environment.

At design review: preserve the reason for the choice

Add permitted mockup images to the Context page using the image controls, or keep the permitted source document in Library. Identify the design version and explain which part the picture illustrates. Ask a reviewer to compare the design with the requirement and open both evidence links.

Record an alternative and why you set it aside: “Keep the current navigation” might avoid visual change but leave the discoverability question unanswered. The decision owner checks the rationale, publishes the relevant Context revision, and shares its workspace link with the implementer. Publishing a note does not deploy the product or start the experiment.

Copy the page content

Create the pages in this order. Put each heading’s page title in the title field and paste the block below it into the body.

Interview notes

# Interview notes

## Practice interview A
A fictional tester could not find the first-step guide.

## Observation
The tester looked for an obvious start button.

## Interpretation
A clearer entry point might help.

## Limits
One fictional example; not real customer evidence.

Experiment log

# Experiment log

## Proposed test
Show a Start here link to a small group of testers.

## Measure
- Can each tester open the guide without help?
- Which words cause confusion?

## Result
Not run yet.

## Decision rule
Review observations before changing the live page.

Launch decision

# Launch decision

## Decision
Prepare a clearer first-step entry point.

## Why
[[Interview notes]] suggests a discoverability question.

## Validation
[[Experiment log]]

## Scope
Write and review the proposed wording first.

## Owner
Product team

## Status
Proposed; no live change approved.

Review the proposal and keep changes explainable

Agree on who owns the requirement and who checks the design. An Owner manages membership; an Editor can edit and publish, while a Viewer reads published versions. Browser Save draft does not itself submit a review. For an explicit item already in Review queue, an authorized human can use View changes, Request changes with a reason, or Approve an eligible Context publication proposal. Check the resulting publication state.

When the test runs, edit Experiment log with its date, method, actual observations, and limits. Update Launch decision only after someone compares the result with the earlier acceptance observation. If the requirement changes, add a dated reason and reconsider the linked rationale rather than silently replacing it.

Use Upload new version for a corrected source file, and History on Context pages to compare the earlier and current wording. A later teammate should see whether the decision changed because of new evidence, a changed constraint, or a corrected mistake.

Check the result

The decision links to both the interview note and the not-yet-run experiment. A later reader can tell a proposal from an approved release change.

Use Search to find Launch decision again. Check the published content and open both links; a successful draft save alone does not confirm that readers have the new version.

Ask an implementer who was absent from the interview to check:

• They can find the user problem, requirement, owner, and current decision status from Launch decision.
• They can distinguish the single fictional observation from the untested hypothesis and from a future test result.
• They can open the supporting pages, explain the rejected alternative, and identify what would justify changing the decision.

Common mistakes to avoid

Mistake	Better approach
Turning one interview into “all customers want this”	Record participant count and limits beside the observation
Pasting personal customer information into shared notes	Anonymize before uploading and choose workspace access carefully
Showing a mockup without a requirement or version	Add the problem, intended behavior, design version, and evidence links
Treating a published proposal as a shipped change	Keep decision status explicit and verify delivery in your normal product tools

At the next planning meeting, search for Launch decision and start from its evidence and unresolved questions. Reuse the reasoning; do not copy an old conclusion into a new context without checking the constraints.

Related guides: Library, review and history, and sharing.

Optional: ask a connected AI tool

Complete MCP connections and grant only the required workspace and reading access. Credential grants and workspace permissions enforce access. Material returned to an external AI app may be processed by its provider; use approved, non-sensitive practice data.

Read Launch decision, Interview notes, and Experiment log in my selected workspace. Produce a design-review brief with: observed evidence, hypotheses, proposed requirement, acceptance observation, rejected alternative, and unanswered questions. Cite the relevant page or passage. Mark the experiment as not run if there is no recorded result. Do not invent customer quotes or approve a launch. Reply here only without editing pages, deploying changes, or contacting customers.

Check each observation against the anonymized source, each requirement against the current decision, and each result against the actual test log. Have the decision owner resolve disagreements. Copy only checked suggestions into a draft; an AI review does not approve a design or replace a real user test.

Chats lets you inspect recorded dtxWiki tool activity. It is not a complete transcript of the AI conversation or a record of every action in the external service.

Version evidence: Library controls, page editing and publication, review decisions.