Product Experience BlueprintMaintenance planning workspace

Christopher Durgin · Version 1.0 · 22 October 2026

Illustrative example · Fictional maintenance-planning scenario

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.

Original example: CC BY 4.0. Credit Christopher Durgin and indicate changes when sharing or adapting.

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

Observe the current planning workflow and confirm role boundaries with affected practitioners.
Verify the work-order and parts definitions that D1–D3 require.
Build the bounded prototype with labeled sample data, then review implementation and user comprehension.
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

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.