# Product Experience Blueprint — [Product name]

Template by Chris Durgin · Version 1.0
Method: https://www.chrisdurgin.com/publications/product-experience-blueprint

License: Creative Commons Attribution 4.0 International (CC BY 4.0).
https://creativecommons.org/licenses/by/4.0/
You may share and adapt this original template, including commercially, with
credit to Chris Durgin, a link to the license, and an indication of changes.
Third-party sources retain their own rights.

## Quick start: six fields

For a focused change, complete this short chain first:

| Field | Your starting record |
| --- | --- |
| Person and decision | [Who needs to decide or do what?] |
| Evidence | [Source observation; distinguish assumptions] |
| Capability | [Proposed behavior, missing-data and recovery paths] |
| Scope and dependencies | [Included, excluded, blocked] |
| Validation | [Task or observation that supports or challenges the proposal] |
| Owner and revision | [Next question, owner, and how learning changes the plan] |

Expand into the full template below when multiple roles, data sources,
permissions, risks, or teams require explicit coordination.

Use this as a starting point. Scale the detail to the decisions and risks involved.
Replace bracketed prompts; mark unknowns explicitly. This template is not evidence
that a product, data source, or outcome has been validated.

Owner: [name / role]
Version: [version]
Updated: [date]
Status: [proposed / under review / approved for a defined scope]
Reviewers: [roles and review dates]

## 1. Product vision and intended value

[Who should be able to do what, in which context, and why does it matter?]
User outcome: [intended change]
Operational or business outcome: [intended change]
Success measure: [definition, baseline if known, target rationale, measurement plan]

## 2. Human problem and supporting evidence

[Describe the work problem before naming a screen or feature.]

| Evidence ID | Observation or source | Context / date | Interpretation | Limitations |
| --- | --- | --- | --- | --- |
| E1 | [actual source link or “not yet collected”] | [context] | [interpretation] | [limits] |

Do not turn an illustrative example, stakeholder request, or generated summary
into a research finding. Distinguish intended benefits from observed outcomes.

## 3. Users, roles, and context

[Goals, responsibilities, decision authority, permissions, environment, devices,
operating rhythm, accessibility needs, and affected non-users.]

## 4. Primary job and end-to-end workflow

When [situation], I need to [task / decision], so I can [outcome].

Trigger → orientation → evidence review → decision → action → handoff → feedback.
Describe the current workflow, proposed changes, exceptions, recovery, and who
owns the next step. Link to authoritative workflow records rather than copying them.

## 5. Decisions and signals

| ID | User decision | Signal / information | Operational definition | Required action / handoff | Evidence link |
| --- | --- | --- | --- | --- | --- |
| D1 | [decision] | [signal] | [meaning, units, population] | [human owner] | [E1 or gap] |

For each signal, connect its source and confidence to Section 9.

## 6. Experience principles and behavior

[State principles that lead to concrete choices.]
- Explain why an item deserves attention.
- Distinguish performance from evidence quality.
- Preserve context during investigation.
- Show missing, stale, estimated, and unvalidated information explicitly.
- Define accessible interaction, loading, empty, error, and recovery states.

## 7. Capabilities and requirements

| ID | Capability / behavior | User / decision served | Supporting evidence | Acceptance / validation check |
| --- | --- | --- | --- | --- |
| C1 | [behavior] | [role / D1] | [source or assumption] | [observable check] |

Reference dedicated design-system guidance for components and detailed styling.
Specify responsive behavior where it changes the workflow or action hierarchy.

## 8. Scope and boundaries

Must-have: [minimum complete workflow]
Should-have: [valuable additions if feasible]
Later: [justified future opportunities]
Aspirational: [unsupported concepts needing evidence or capability]
Explicit non-goals: [excluded workflows / actions]
Systems of record: [authority and ownership]

## 9. Data feasibility and confidence

| Signal ID | Source / evidence | Site / population / coverage | Freshness / cadence | Availability | Derivation or proxy | Validation owner / status | Decision impact if missing | Prototype representation |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| D1 | [source link or unknown] | [actual coverage] | [timestamp / cadence] | [state below] | [formula / assumption] | [owner / status] | [blocked task] | [label / unavailable state] |

Availability states: source verified, derivable (not yet verified), proxy,
unavailable, unknown. Record validation separately: unreviewed, checked for a
specified purpose, or rejected. “Real data” does not imply correct definitions,
correct population, current data, or fitness for a particular decision.

Label embedded snapshots with their capture date. Do not call them live.
Do not present elapsed time as an operational status duration without validation.
Rank gaps by the user decisions they block, rather than a coverage percentage alone.
Reference a dedicated data-availability matrix when present.

## 10. Human factors, risks, and recovery

[Workload, error consequences, ambiguity, trust, accessibility, permissions,
destructive actions, and recovery.]

| Risk | Affected person / decision | Consequence | Mitigation | Verification |
| --- | --- | --- | --- | --- |
| [risk] | [role / task] | [impact] | [behavior] | [test / owner] |

## 11. AI and implementation guidance (when applicable)

[Distinguish AI used to build the product from AI features within it.]
Define permitted inputs, human review, source requirements, uncertainty,
overrides, escalation, and action authority. Link to executable agent instructions.
Describe prototype simulations and what they cannot demonstrate.

## 12. Assumptions and open questions

| ID | Question / assumption | Evidence needed | Owner | Status | Scope consequence |
| --- | --- | --- | --- | --- | --- |
| A1 | [unknown] | [needed evidence] | [role] | [open] | [decision affected] |

## 13. Validation plan

Separate implementation QA, user/workflow validation, and data validation.

| Question | Participant / reviewer | Task / method | Observable success and failure | Data conditions / limits | Next decision |
| --- | --- | --- | --- | --- | --- |
| [question] | [role] | [task] | [criteria agreed before testing] | [real / simulated / proxy] | [decision] |

Include error and recovery paths and relevant device sizes. Record actual findings
separately from this plan; do not imply a planned session has occurred.

## 14. Delivery and iteration record

| Date / version | Gap or feedback | Hypothesis / change | Supporting evidence | Blueprint section / backlog link | Validation result / remaining uncertainty |
| --- | --- | --- | --- | --- | --- |
| [date] | [observation] | [change] | [source] | [traceability] | [result or not yet tested] |

Keep the blueprint and build aligned. Record conflicting decisions explicitly.
Do not reconstruct a proposed revision as though it were a historical version.

## 15. Next steps and release decision

[Highest-impact unknown, next test or build change, owner, and review date.]
[What must be established before expanding scope or deploying?]

## References and companion artifacts

[Research, workflow records, data matrix, design system, agent skills, backlog,
prototype, validation results. Record authorship and source dates.]