# Product Experience Blueprint — Maintenance planning workspace

Illustrative example · Fictional maintenance-planning scenario

By Christopher Durgin · Version 1.0 · Updated 2026-10-22

License: [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Credit Christopher Durgin, link the license, and indicate changes when sharing or adapting this original example.

## At a glance

**Vision:** Help maintenance planners prepare a feasible shift plan by making blockers, supporting evidence, and the next responsible role visible in one investigation flow.

**Problem:** Planners compare work-order and parts records to prepare the next shift. A missing parts update can be mistaken for a confirmed blocker, while the person responsible for clarification is not always clear.

**Primary job:** When preparing the next shift, I need to identify which proposed jobs are blocked and who owns the next action, so I can coordinate a feasible plan.

**Hypothesis:** If planners can review a job’s blocker, evidence, and responsible role together, they will be better able to explain its status and choose the next coordination action. Unknown evidence must remain visibly unconfirmed.

## Quick start: six fields

| Field | Starting record |
| --- | --- |
| Person and decision | Maintenance planner: which jobs need clarification before inclusion in the next shift plan? |
| Evidence | S1–S2: separate records and ambiguous parts updates; S3 identifies coordination and approval boundaries. |
| Capability | Review each job, blocker, responsible role, and supporting record; distinguish blocked from unconfirmed. |
| Scope and dependencies | Read-only list, evidence detail, and handoff; sample work-order export available, parts feed and live integration unresolved (S4). |
| Validation | Ask planners to explain a blocked job, recognize unknown readiness, and identify the next action. |
| Owner and revision | Proposed product/research lead coordinates review with planning and data specialists; assignments must be agreed. |

## 1. Product vision and intended value

The vision describes the intended future. The hypothesis connects a proposed change to outcomes the team can test; the source inputs below explain why that change is worth investigating.

- **User outcome:** planners can explain a job’s readiness, identify missing evidence, and name the next coordination action.
- **Operational value:** a clearer handoff between planning, maintenance supervision, and parts coordination.
- **Measures:** correct status interpretation, identification of the next responsible role, unresolved questions, task errors, and time needed to reach a justified decision. Establish a baseline before claiming improvement; agree acceptable error and time criteria with the team before testing.
- **Tradeoff:** make uncertainty visible even when a simpler “ready/not ready” display would appear more decisive.

## 2. Human problem and supporting evidence

**Scenario source notes:** S1–S4 are authored inputs for this teaching example, representing the kinds of workshop, observation, authority, and data-review records a practitioner would supply. They are not records of actual participants or systems. Subsequent references use these IDs; assumptions and planned tests remain separate.

| ID | Input supplied to the blueprint | Interpretation | Product implication |
| --- | --- | --- | --- |
| S1 · Planning-workshop note | Planners consult a candidate-job list and a separate parts record before agreeing the next shift’s proposed work. | The decision spans sources and roles. A combined view may help; its benefit is still a hypothesis. | Keep the job, parts evidence, and next coordination role connected during investigation. |
| S2 · Task-observation note | In an example task, a planner treats a missing parts update as proof that parts are unavailable. | Missing evidence and a confirmed constraint are being conflated in that task. Check how often this occurs in subsequent research. | Separate “Readiness unconfirmed” from “Blocked” and test whether the explanation supports the correct next action. |
| S3 · Workflow-owner note | The planner coordinates clarification; the parts coordinator resolves stock questions; the supervisor retains work-authorization authority. | Coordination support must preserve these role boundaries. | Show the responsible role and source handoff; exclude approval actions from this view. |
| S4 · Data-review note | A sample candidate-job export contains job ID, work-order status, equipment ID, and last-updated time. No parts feed or write API is supplied. | A sample-backed interaction prototype is feasible; live readiness and operational writes are not established. | Use labeled sample records, represent missing parts evidence explicitly, and investigate integration in parallel. |

**Decision trace:** S2 → distinguish unknown readiness (D2) → show the missing source (C2) → test status interpretation (Section 13) → revise the label and acceptance criterion if confusion persists (Section 14).

## 3. Users, roles, and context

- **Planner:** prepares candidate work, investigates blockers, and coordinates the next action. Does not approve execution through this prototype.
- **Maintenance supervisor:** reviews the proposed plan and retains work-authorization responsibility under the established process.
- **Parts coordinator:** clarifies availability and constraints; does not have their responsibilities inferred from a status label.
- **Data specialist / system owner:** confirms definitions, access, freshness, and integration feasibility.

Working context from S1: shift preparation across planning and parts records. Desktop preparation with tablet access during review is a design assumption (A1), not a finding. Investigate shared-device use, connectivity, interruptions, access needs, and handoff timing. Technicians are affected by the plan even if they do not use this view; include their constraints in discovery.

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

Use the primary job on the opening page as the reference for scope.

**Starting workflow from S1 and S3:** review candidate jobs → consult parts records → coordinate clarification → submit the proposed plan through the supervisor’s approval process. Observe additional real tasks before treating this outline as comprehensive.

**Proposed flow:** choose shift → review candidate jobs → inspect status and supporting evidence → identify blocker or missing information → confirm the next responsible role → open the source record or prepare a clarification → communicate the reviewed plan through the existing process.

Preserve the selected shift, filters, and job when returning from detail. If a source cannot load, retain context, show the unavailable evidence, and offer retry. A prepared clarification is not a delivered message or accepted handoff; the prototype records neither automatically.

## 5. Decisions and signals

| ID | Decision | Information and meaning | Action / handoff | Basis |
| --- | --- | --- | --- | --- |
| D1 | Does this job have a confirmed blocker? | Work-order status and parts constraint, interpreted through definitions approved by source owners. | Planner inspects the blocker and supporting record. | S1, S4; readiness definitions pending (A2). |
| D2 | Is readiness still unknown? | Missing source, stale timestamp, conflicting values, or unverified definition. | Planner seeks clarification; do not mark ready. | S2, S4. |
| D3 | Who needs to resolve the next question? | Agreed responsibility for the specific blocker or information gap. | Planner coordinates with the confirmed role through the established channel. | S3; exception mapping pending (A3). |

**State definitions:** “Blocked” requires confirmed evidence of a blocking condition. “Readiness unconfirmed” means evidence is insufficient to decide. Display “Ready for planning review” only when the agreed prerequisites are supported; this is not authorization to execute work. For the first interaction prototype, use authored sample records with the fields supplied in S4.

## 6. Experience principles and behavior

- **Explain attention:** show the reason a job needs review, not an unexplained risk score.
- **Separate condition from confidence:** a blocked job and an unconfirmed job require different explanations and next actions.
- **Preserve investigation context:** shift, filters, and selection survive navigation and recoverable errors.
- **Support inclusion:** use text labels with color, meaningful headings, keyboard operation, visible focus, and readable layouts at compact widths.
- **Respect authority:** provide evidence and coordination support; keep approval in the established operational process.

## 7. Capabilities and requirements

| ID | Proposed capability | Traceability | Acceptance / validation check |
| --- | --- | --- | --- |
| C1 | Candidate-job list with status, reason, responsible role, and evidence timestamp. | D1–D3; S1–S3. | Every status has a visible explanation; missing ownership is labeled unassigned, not invented. |
| C2 | Evidence detail showing source, freshness, and unresolved gaps. | D1–D2; S2, S4. | Missing or conflicting evidence shows readiness unconfirmed and identifies the gap. |
| C3 | Source-record handoff with preserved planning context. | D3; S1, S3. | A failed handoff retains the selected job and provides a recoverable error; no success is implied. |
| C4 | Responsive and accessible investigation flow. | A1; access needs to establish in Section 3. | Complete the core tasks with keyboard navigation; at 390 px, stack detail content and keep actions reachable without page-level horizontal scrolling. |

Use an approved design system for components and tokens. On desktop, keep list and investigation context visible where space permits; on compact screens, use a list-to-detail flow with a clear return path.

## 8. Scope and boundaries

- **Must-have:** candidate list, reason for attention, evidence detail, missing-data states, responsible role, source handoff, and recovery.
- **Should-have:** user-controlled filtering by confirmed status and responsible role.
- **Later:** saved views or broader job coverage if research demonstrates a need.
- **Aspirational:** predictive readiness or scheduling assistance, subject to evidence, feasible data, and governance.
- **Non-goals:** automated scheduling, operational writes, work authorization, inventory changes, and safety certification.
- **Systems of record:** source work-management and parts systems retain authority; this view explains their information for planning review.

## 9. Data feasibility and confidence

| Signal | Source / coverage | Freshness | Availability / validation | Missing-data consequence | Prototype representation |
| --- | --- | --- | --- | --- | --- |
| Work-order status (D1) | S4 sample export; site and full candidate-job coverage still to verify. | Required cadence to agree. | Sample fields supplied; decision fitness unreviewed. | Cannot establish readiness from status alone. | Authored records labeled “Sample data — not connected.” |
| Parts availability (D1–D2) | No feed supplied (S4); allocation and delivery meanings need review. | Timestamp required; tolerance to agree. | Unknown; unreviewed. | Readiness remains unconfirmed. | Explicit unknown and blocked examples. |
| Responsibility mapping (D3) | Role boundaries supplied in S3; exception routing still open. | Review when responsibilities change. | Scenario role definitions supplied; exceptions unreviewed. | Show unassigned and the agreed clarification route. | Proposed role labels for interaction review only. |

No derived score or proxy is used. Data specialists verify definitions and population; planning specialists verify fitness for the decision. Actual delivery assignments and review dates remain open. Interaction testing with sample records cannot establish live integration or operational accuracy.

## 10. Human factors, risks, and recovery

| Risk | Consequence | Mitigation | Check |
| --- | --- | --- | --- |
| Unknown interpreted as ready | Unsupported planning decision. | Separate readiness from confidence; expose missing evidence. | Ask users to explain both states in matched scenarios. |
| Stale or wrong-population data | Apparently plausible but irrelevant status. | Display source, timestamp, and coverage; withhold readiness when insufficient. | Data review plus stale/wrong-context test cases. |
| Navigation loses context | Rework or acting on the wrong job. | Preserve shift, filter, and selection; show job identity in detail. | Return and recovery tasks. |
| Color-only status or inaccessible controls | Exclusion or misinterpretation. | Text labels, keyboard access, visible focus, and responsive reflow. | Assistive-technology and keyboard review with relevant users. |
| Clarification mistaken for approval | Work proceeds without authority. | Explicit coordination language and source-system boundary. | Workflow-owner review and comprehension tasks. |

## 11. AI and implementation guidance

AI may assist with building the prototype from this blueprint. It must preserve source IDs, assumption labels, scope boundaries, and missing-data behavior. Product decisions and source interpretations remain subject to practitioner and specialist review.

No AI product feature is required. Implement authored sample records, not invented integrations. Keep approval, scheduling, and outbound operational actions outside the prototype. Review generated behavior against C1–C4 before any user session.

## 12. Assumptions and open questions

| ID | Question | Proposed reviewer, not assigned owner | Evidence / next decision |
| --- | --- | --- | --- |
| A1 | Will desktop preparation and tablet review fit the work and access needs? | Research lead and planner. | Observe representative settings; revise layout and device requirements. |
| A2 | Which sources and definitions support readiness, and how stale is too stale? | Data specialist and maintenance supervisor. | Inspect records; decide what the prototype can represent. |
| A3 | Who owns each clarification and approval? | Workflow owner and affected roles. | Agree responsibilities and exceptions before live handoffs. |
| A4 | Does the combined view improve decisions? | Research lead and representative planners. | Compare task interpretation, errors, and coordination with the current process. |

## 13. Validation plan

| Type | Question and method | Success / failure to observe | Next decision |
| --- | --- | --- | --- |
| Implementation QA | Exercise C1–C4 at 1440 × 1000, 768 × 1024, and 390 × 844; include keyboard and source errors. | Context preserved; labels accurate; controls reachable; no misleading success. | Correct implementation before sessions. |
| User / workflow | Ask planners to find a blocked job, distinguish an unconfirmed job, explain evidence, and identify the next responsible role. | Correct explanations and justified next actions; record confusion, errors, and missing context. | Retain, revise, or remove capabilities. |
| Data | Inspect actual sources, timestamps, definitions, population, and exception records with specialists. | Evidence fits D1–D3 and agreed freshness needs. | Establish feasible scope before live integration. |

Agree participant coverage, baseline tasks, and decision criteria before testing. Include variation in experience and relevant access needs. Record observations and outcome measures separately from this plan. Look for unintended effects and alternative explanations as well as support for the hypothesis.

## 14. Delivery and iteration record

| Version / record | Input | Proposed change | Traceability | Result / next step |
| --- | --- | --- | --- | --- |
| Initial direction | S1–S4. | List, evidence detail, and clarification handoff. | D1–D3; C1–C4. | Planned interaction and data validation. |
| Illustrative revision scenario | Suppose a prototype review still reveals the confusion described in S2 despite the initial status explanation. | Retain the separate states; move the missing-source explanation beside the status and replace a generic “Clarify” action with “Request parts update” for that gap. | Revise C1–C2 labels, acceptance criteria, and prototype together. | Hypothesis: the adjacent explanation and specific action improve interpretation and next-step selection. Repeat equivalent tasks; no completed study result is recorded. |

If actual findings contradict the proposed workflow, revise the blueprint rather than preserving the interface for its own sake. Link accepted changes to delivery items and the next test.

## 15. Next steps and release decision

1. Observe the current planning workflow and confirm role boundaries with affected practitioners.
2. Verify the work-order and parts definitions that D1–D3 require.
3. Build the bounded prototype with labeled sample data, then review implementation and user comprehension.
4. Expand toward live use only after data fitness, authority, recovery, and user-task criteria are reviewed and accepted by the responsible team.

The next decision is whether the proposed combined view addresses a demonstrated planning need—not whether every template section has been filled.

## References and companion artifacts

- [The Product Experience Blueprint method](https://www.chrisdurgin.com/publications/product-experience-blueprint)
- [Blank PEB template](https://www.chrisdurgin.com/resources/product-experience-blueprint-template.md)
- [hse-agent: reusable human-systems guidance](https://www.chrisdurgin.com/publications/hse-agent)

Research notes, workflow records, a data-availability matrix, approved design-system guidance, backlog items, and actual validation results would be linked here as they become available.