Pattern

HCD delivery checkpoints

Keep evidence, accessibility, and accountable human-centered decisions connected to the work from initial commitment through release and learning.

Connected MyKMHub content

Purpose

When to use this pattern

Use it when HCD findings must influence a product, service, policy, workflow, acquisition, or operational change delivered by multiple roles. It is especially useful when research, accessibility, design, engineering, and release decisions happen in separate tools or governance forums.

Checkpoints are decision moments, not mandatory meetings or stage gates. Integrate them into the team's existing planning and delivery model, and scale the evidence required to the consequence, uncertainty, and reversibility of the decision.

Working agreement

Establish a minimum delivery contract

Before work accelerates, agree on:

  • the outcome, people affected, constraints, and accountable owner;
  • where evidence and accessibility change requirements and decisions;
  • who recommends, reviews, accepts, and may approve an exception;
  • the records and evidence required at each consequential decision;
  • how unresolved findings enter the delivery backlog and remain visible;
  • release, monitoring, rollback, and post-launch learning expectations.

Put these expectations in the systems where delivery work is managed. A separate HCD checklist that does not affect requirements, ownership, or release decisions is easy to ignore.

Decision sequence

Use six connected checkpoints

1. Frame and commit

Decision: Is the problem, affected population, intended outcome, authority, and evidence need clear enough to begin?

Minimum evidence: Approved intake, known constraints, existing evidence, open assumptions, accountable owner, and decision deadline.

2. Define requirements

Decision: Have evidence and obligations become testable requirements rather than optional design advice?

Minimum evidence: User and operational needs, accessibility requirements, acceptance criteria, edge cases, and traceable rationale.

3. Review the proposed experience

Decision: Does the proposed direction address the prioritized needs before implementation becomes expensive to change?

Minimum evidence: Design rationale, content and interaction states, research findings, accessibility review, feasibility input, and unresolved tradeoffs.

4. Verify implementation

Decision: Does the implemented experience preserve the approved intent and work with representative users, technology, and assistive technology?

Minimum evidence: Implementation review, automated and manual accessibility results, usability evidence, defect disposition, and requirement coverage.

5. Decide release readiness

Decision: Are remaining risks understood, owned, time-bound, and acceptable to the person with authority to release?

Minimum evidence: Acceptance results, unresolved issues, exception decisions, monitoring plan, support readiness, and rollback or mitigation conditions.

6. Learn after release

Decision: What happened in use, what must change, and which knowledge should be retained for future work?

Minimum evidence: Outcome measures, feedback, accessibility signals, support patterns, workarounds, incidents, decisions, and reusable lessons.

Traceability

Carry evidence forward without copying everything

At each checkpoint, link to the governed source and record only what the decision needs: the question, finding or requirement, confidence and limitations, decision, authority, owner, and next review condition.

  • Preserve the difference between observation, interpretation, requirement, and decision.
  • Keep accessibility criteria specific enough to test manually and automatically where appropriate.
  • Record changed or rejected recommendations and the rationale, not only the final direction.
  • Update the source record when evidence changes rather than allowing disconnected copies to compete.
  • Retain links from defects and acceptance results back to the requirement and evidence they evaluate.

Governance

Make exceptions explicit and temporary

An exception should identify the unmet requirement, affected people, evidence, consequence, compensating measure, accountable authority, owner, due date, and condition that triggers reconsideration. Schedule it as governed work rather than silently relabeling it as a future enhancement.

Legal or policy review does not replace accessibility and user evaluation, and an automated test result does not establish that an experience is usable. Escalate when a release decision would accept material risk without the necessary authority or evidence.

Leadership review

Check whether HCD can change delivery

  • Can every material user need be traced to a requirement or decision?
  • Do accessibility criteria cover content, interaction, states, and assistive technology?
  • Are reviewers involved while change is still feasible?
  • Do unresolved findings have an owner, priority, rationale, and review date?
  • Can the release authority see user and accessibility risk alongside delivery risk?
  • Does post-launch evidence change the backlog, operating model, or reusable guidance?
  • Can another team understand what was decided and why without relying on individual memory?