# Human-Centred Design Plan: [Product or project name]

> A plan for the human-centred design (HCD) activities of one project across its life cycle:
> how the team will understand the context of use, specify user requirements, produce design
> solutions and evaluate them with users, who is responsible, when each activity happens and
> what evidence it leaves. Structure aligned with ISO 9241-210:2019 (second edition, July 2019),
> clause 5 (principles), clause 6 (planning) and clause 7 (activities). ISO 9241-210 is a paid
> standard: this template cites its clause numbers and uses original wording. Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use Quillmere Libraries, a
> fictional city library service rebuilding its borrowing app.

<!--
Guidance: How to use this template
- Write this plan at project start, next to the project plan, and update it at each phase gate.
  ISO 9241-210:2019 clause 6 expects HCD planning to be part of the project plan, not a side note.
- Section 3 is the core: one row per activity with an owner, timing, method and output.
- Each activity in section 3 should point to a working template (research plan, usability test
  plan and so on) so the plan stays short and the detail lives where the work happens.
- Common pitfall: a plan that puts all user involvement in one usability test before launch.
  HCD is iterative; plan at least two evaluate-and-revise loops while change is still cheap.
-->

## Document control

<!-- Guidance: Name the person accountable for HCD in the project. Without a named owner, user activities are the first thing cut when time runs short. -->

| Field | Value |
|---|---|
| Document ID | [HCD-001] |
| Version | [1.0] |
| Status | [Draft / Approved / Active / Closed] |
| Owner (HCD lead) | [@design-lead] |
| Approvers / reviewers | [@product-owner], [@project-manager], [@engineering-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Project plan | [link or document ID] |
| Life cycle model | [*Example:* agile delivery in two-week sprints with quarterly releases] |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Approved at project start gate |

## 1. Scope and goals

<!-- Guidance: Say what system the plan covers, who its users and other stakeholders are, and what usability, accessibility and user experience goals the project commits to. -->

| Item | Value |
|---|---|
| System in scope | [*Example:* Quillmere Libraries borrowing app, iOS and Android, and its web version] |
| User groups | [*Example:* adult borrowers, parents borrowing for children, older borrowers, assistive technology users, branch staff who help borrowers] |
| Other stakeholders | [*Example:* branch managers, IT operations, accessibility officer] |
| Usability goals | [*Example:* 80% of borrowers reserve a title and change its pick-up branch unaided; SUS mean at or above 68] |
| Accessibility goal | [*Example:* conform to WCAG 2.2 level AA; see design/accessibility-checklist] |
| Out of scope | [*Example:* staff back-office system] |

## 2. HCD principles for this project

<!-- Guidance: ISO 9241-210:2019 clause 5 sets out the principles of HCD. Restate each one as a commitment for this project, with how you will show it. -->

| Principle (paraphrased) | Project commitment | Evidence |
|---|---|---|
| Design is based on an explicit understanding of users, tasks and environments | [*Example:* context of use documented before design starts] | Context of use description, personas |
| Users are involved throughout design and development | [*Example:* borrowers take part in every release cycle] | Session logs, recruitment records |
| Design is driven and refined by user-centred evaluation | [*Example:* no release without a usability test of changed flows] | Usability test reports |
| The process is iterative | [*Example:* at least two test-and-revise loops per major flow] | Revision history of designs and reports |
| Design addresses the whole user experience | [*Example:* branch pick-up and notifications are in scope, not only screens] | Journey map |
| The team has multidisciplinary skills and perspectives | [*Example:* research, design, engineering, accessibility and branch staff in reviews] | Team list, review attendance |

## 3. HCD activities and schedule

<!-- Guidance: ISO 9241-210:2019 clause 7 describes four linked activities. Plan each one with an owner, timing, method and output, then repeat the loop as needed. -->

```mermaid
flowchart LR
  P["Plan HCD (clause 6)"] --> A["Understand and specify context of use"]
  A --> B["Specify user requirements"]
  B --> C["Produce design solutions"]
  C --> D["Evaluate designs against requirements"]
  D -->|"Requirements met"| E["Solution meets user requirements"]
  D -->|"Iterate"| A
  D -->|"Iterate"| B
  D -->|"Iterate"| C
```

| ID | Activity | Phase and timing | Method | Owner | Output |
|---|---|---|---|---|---|
| ACT-01 *(Example)* | Understand and specify the context of use | Discovery, sprints 1 to 3 | Interviews, branch visits, analytics review | [@researcher] | design/research-interview-guide, design/research-synthesis, product/persona |
| ACT-02 *(Example)* | Specify user requirements | Discovery, sprint 4 | Requirements workshop from insights | [@product-owner] | User requirements with IDs and acceptance criteria (product/user-story) |
| ACT-03 *(Example)* | Produce design solutions | Alpha, sprints 5 to 10 | Sketches, prototypes, design system components | [@designer] | Prototypes, design/design-system updates |
| ACT-04 *(Example)* | Evaluate designs: expert review | Each sprint | Heuristic evaluation | [@designer] | design/heuristic-evaluation |
| ACT-05 *(Example)* | Evaluate designs: user testing | Sprints 7 and 10, then each release | Moderated usability tests | [@researcher] | design/usability-test-plan, design/usability-test-report |
| ACT-06 *(Example)* | Evaluate accessibility | Sprint 10 and each release | Checklist review and assistive technology testing | [@accessibility-officer] | design/accessibility-checklist, quality/accessibility-audit |
| ACT-07 *(Example)* | Monitor in use | After release | Support tickets, feedback, analytics | [@product-owner] | Release review, inputs to ACT-01 |

## 4. Roles, resources and integration

<!-- Guidance: ISO 9241-210:2019 clause 6 covers responsibility, plan content, integration with the project plan, and timing and resources. Show where HCD sits in sprint and gate decisions, and the budget it needs. -->

| Item | Plan |
|---|---|
| HCD lead and authority | [*Example:* design lead; can block a release when a severity 4 usability problem is open] |
| Team | [*Example:* 1 researcher, 2 designers, accessibility officer at 20%] |
| Participant budget | [*Example:* 40 participants per year, incentives and recruitment fees] |
| Tools | [*Example:* prototyping tool, remote session tool, research repository] |
| Integration with delivery | [*Example:* research and test findings enter the backlog with an ID; sprint review includes a user evidence slot] |
| Gate criteria | [*Example:* beta gate needs ACT-05 report with no open severity 3 or 4 problems in core tasks] |

## 5. Risks and dependencies

<!-- Guidance: List what could stop HCD work from happening or from influencing decisions. -->

| ID | Risk | Mitigation |
|---|---|---|
| HCDR-01 *(Example)* | Recruitment of older and assistive technology users is slow | Partner with branch staff and local disability organisations early |
| HCDR-02 *(Example)* | Findings arrive after sprint commitments | Test one sprint ahead of build; keep a findings slot in planning |
| HCDR-03 *(Example)* | Research data protection approval delays fieldwork | Reuse approved design/research-consent-form; book privacy review in sprint 1 |

## 6. Conformance and evidence checklist

<!-- Guidance: ISO 9241-210:2019 includes an informative annex with a checklist for supporting claims of conformance. Use this project checklist to show that each planned activity happened; check the official text for the formal conformance requirements. -->

- [ ] HCD plan approved and linked from the project plan.
- [ ] Context of use documented and reviewed with users or user representatives.
- [ ] User requirements recorded with IDs and traced to design and evaluation.
- [ ] At least two evaluate-and-revise loops completed for each core flow.
- [ ] Usability and accessibility goals in section 1 measured and reported.
- [ ] Open user-related issues tracked to closure or accepted with a reason.
- [ ] Lessons learned recorded at project close.

## Standard and licence note

Structure aligned with ISO 9241-210:2019, Ergonomics of human-system interaction, Part 210:
Human-centred design for interactive systems, second edition, July 2019 (ISO lists it as
confirmed at its 2025 review), clauses 5, 6 and 7. ISO 9241-210 is a paid publication: this
template cites its name, edition and clause numbers only, and all wording is original. Official
text: ISO, purchase or licensed access: https://www.iso.org/standard/77520.html. Check the
current official version before relying on it. WCAG 2.2: https://www.w3.org/TR/WCAG22/.
Template licence: MIT.