When to use this workflow
Use this resource to connect research, product decisions, design, implementation, and review around one real task. The main artifact is a traceable flow with named ownership, not a diagram that describes an ideal process nobody follows.
A worked example
For an invitation feature, identify the source of the problem, the person approving scope, the design reference, the implementation change, and the QA evidence. Follow one requirement through each stage. If a decision exists only in chat, move the approved conclusion into the shared feature record and link its history.
Decisions and common mistakes
Keep technical checks and functional review distinct. A passing build does not show whether an error message is understandable or whether the intended permission rule was exercised. Record the scenario, expected behavior, observed result, and remaining limitations for each review.
What to hand off
After release, record what shipped and any deferred scope so the next task starts from current behavior. Use the related product-workflow guide for a worked brief, review record, and explanation of how overlapping design and engineering work can fit a regular planning rhythm.
Put the resource to work
1. Start with one concrete task
Bring: A real product task, current team responsibilities, and review checkpoints.
First task: Map the task through research, design, implementation, and review with an owner for each handoff.
Choose one component, screen, or team workflow to improve. Gather the existing decisions and write down the question you want this resource to help answer.
2. Open the source material
Open the original guide or presentation ↗
Use the original walkthrough alongside your project. Its existing access flow remains available on the original page.
3. Apply it with your project context
Follow the material in sequence and replace examples with your own product context. Record decisions as you go so another teammate can understand why the result changed.
4. Review the result
Confirm every handoff contains the decision, evidence, and expected next output; keep human review at consequential decisions.
Compare the output with the task’s acceptance criteria. Check factual claims, unsupported assumptions, and any changes to the interface. For code or design changes, review real states and behavior before treating the result as finished.
5. Keep what works
Save approved outputs with their source and ownership. Note which instructions helped, where the result needed correction, and what must be checked next time. Use the workflow below to connect this task to its next step.
Follow the related step-by-step field guide ↗
Completion checklist
- The inputs and intended result are explicit.
- Required files and tools are available in the chosen host.
- The result has been reviewed against the actual task.
- Limitations and follow-up checks are recorded.