---
name: govern-design-for-a-regulated-product
category: design
description: Govern regulated product design through applicable controls, traceable requirements, risk-based validation, controlled release, surveillance, and corrective action. Use when interface or service design affects regulated claims, safety, rights, records, or market authorization.
---

# govern-design-for-a-regulated-product

Make every consequential design decision traceable to evidence and authority.

## When to use

- Use for medical, financial, transport, public-sector, employment, education, insurance, identity, or other products where regulated outcomes and design controls are material.
- Obtain qualified domain and jurisdiction interpretation; this skill does not decide which law or standard applies.

## Preconditions

- Establish regulatory, quality, safety, legal, privacy, security, accessibility, clinical or domain, engineering, design, content, supplier, operations, and release authority.
- Identify products, intended uses, users, markets, classifications, claims, records, standards, existing approvals, post-release duties, and change-reporting thresholds.
- Preserve approved baselines, requirements, risk files, research, decisions, verification, validation, complaints, incidents, deviations, supplier evidence, release records, and corrective actions.

## Procedure

1. Create a **regulatory and design control map** linking each market, product, intended use, user, claim, classification, authority, standard, required record, review, approver, and release condition.
2. Define controlled design inputs from user needs, intended outcomes, accessibility, safety, privacy, security, content, interoperability, operations, and applicable obligations.
3. Maintain **traceability and change control** from need to requirement, risk, design output, implementation, verification, validation, labeling, training, release, and post-release signal.
4. Assign stable identifiers, version, status, rationale, source, owner, reviewer, approval, and effective date to consequential artifacts.
5. Integrate risk management: hazards or harms, sequence, cause, affected people, severity, likelihood, detectability, control, verification, residual risk, and authority.
6. Govern research and representative participation with consent or other authority, accessibility, privacy, data minimization, vulnerable-group protection, and documented limits.
7. Review third-party components, design systems, content, algorithms, suppliers, and generated outputs for intended use, evidence, configuration, provenance, updates, and failure.
8. Classify every change by affected requirement, risk, claim, market, compatibility, validation, record, notification, and release impact before implementation.
9. Build **validation and release evidence** from objective verification, production-shaped validation with representative users, accessibility, foreseeable misuse, failure recovery, content, security, data, interoperability, and operational readiness.
10. Keep independent review proportionate to risk and separate artifact authorship from approval where required.
11. Release only the approved version with controlled configuration, labeling, training, support, monitoring, supplier state, rollback, and distribution records. For each consequential interaction, retain a privacy-safe configuration attestation identifying market, application and design-system version, decision threshold, notice, vendor workflow, and active feature flags.
12. Run **post-release surveillance and corrective action** across complaints, accessibility reports, incidents, near misses, support, field performance, overrides, drift, regulatory changes, and supplier notices.
13. Triage signals by harm and authority, preserve evidence, contain unsafe use, investigate cause, correct affected product and records, verify effectiveness, and assess reportability.
14. Audit traceability, access, exceptions, overdue actions, training, evidence quality, and market configuration on a defined cycle.

## Failure plan

- If applicable controls or release authority are unresolved, hold the affected market or product use.
- If traceability breaks, block approval until requirements, risks, implementation, and evidence reconcile.
- If an urgent safety correction is needed, use the authorized emergency path, preserve the deviation, and complete retrospective evidence and effectiveness review.
- If a supplier change invalidates evidence, quarantine the affected version and reassess before distribution.

## Worked example

A regulated service operates in several markets and combines a shared design system, identity checks, automated recommendations, customer notices, and a third-party workflow. A design refresh changes error wording, navigation, thresholds, and accessible interaction while an urgent field issue needs a patch. The organization maps market controls, traces each change through requirements and risks, validates representative critical journeys, releases only approved configurations, handles the emergency patch through a documented deviation, and verifies corrective-action effectiveness with post-release signals.

## Done

- A design governance and traceability register records products, markets, intended uses, controls, requirements, risks, outputs, changes, evidence, approvals, suppliers, and exceptions
- A validation and release evidence package proves representative outcomes, accessibility, safety, privacy, security, foreseeable misuse, failure recovery, operations, configuration, and distribution controls
- A surveillance and corrective-action report reconciles complaints, incidents, signals, containment, investigation, reportability, corrections, effectiveness, residual risk, and governance improvements