Care throughout the work
Agree the product’s requirements and risks, make the decisions visible, and retain useful evidence as the work develops.
Consider semantic structure, keyboard paths, focus, labels, contrast, content, reflow, and motion from the start. Review the whole journey with its loading, error, and recovery states, then combine automated checks with manual and assistive-technology review appropriate to the product.
Evidence to look for: reviewed task flows, documented issues, component behavior, and checks against the agreed accessibility target.
Map sensitive data, identities, roles, and trust boundaries. Review authorization, validation, dependencies, secrets, and operational access. Plan specialist security assessment where the product’s risk calls for it; ordinary application review is not a substitute for every form of assurance.
Evidence to look for: access rules, risk decisions, dependency review, and tested permission and failure paths.
Keep responsibilities and data ownership clear. Record the reasons for architectural and stack decisions, including their costs and constraints. Prefer a structure the operating team can maintain over complexity that has no present purpose.
Evidence to look for: architecture diagrams, decision records, contracts, and a practical path for change.
Consider loading, interaction latency, network conditions, API behavior, database access, and background work. Set performance expectations around important tasks and representative devices, then measure those paths as the product changes.
Evidence to look for: task-based performance checks, asset and query review, and operational signals.
Define why data is needed, who can access it, where it flows, and how it changes or leaves the system. Plan schema migrations, retention and deletion behavior, backup, restore, and reconciliation with the people responsible for the product’s requirements.
Evidence to look for: data maps, access boundaries, migration checks, and recovery procedures.
Use unit, integration, contract, and end-to-end checks where they protect meaningful behavior. Combine them with design review, exploratory testing, and checks on representative devices. A passing test suite is useful evidence, not the whole definition of quality.
Evidence to look for: coverage of critical journeys, realistic test data, documented limitations, and clear release decisions.
Prepare deployment, rollback or roll-forward, monitoring, useful alerts, and incident ownership. Document the work someone will need to do under pressure. Revisit operational and dependency risks as the product evolves.
Evidence to look for: a release workflow, recovery instructions, agreed support responsibilities, and a maintained improvement backlog.
A shared definition
The release decision needs context, evidence, and a clear owner.
Set acceptance criteria around the important journeys and the consequences of failure. Record unresolved issues, explain their impact, and agree what needs to happen before and after release.
Requirements differ across products. Formal audits, specialist testing, regulated obligations, and service commitments need a defined scope and the appropriate expertise.
Explore launch & evolutionRead this website’s accessibility notes
