主题 3.2 — 设计系统与原型制作

一个设计系统把良好的设计决策转化为共享的、可复用的基础设施——这样无障碍性、临床安全与一致性就只需被构建一次、然后在各处被继承,而不是在每一块屏幕上被重新争论、重新破坏。

为什么这在医疗与照护领域很重要#

在医疗与照护领域,界面往往是临床决策与患者之间最后的几厘米。一个令人困惑的用药字段、一个无法访问的日期选择器、一个在一项服务中意味着"取消预约"、在另一项服务中意味着"取消并丢失你的数据"的按钮——这些不是外观问题。它们是患者安全问题、公平问题与信任问题。当每个团队都从零开始设计自己的组件时,缺陷会成倍增加,安全保证在整个项目组合中就变得无法推理。

一个设计系统是让你停止反复为同样的错误买单的方式。当一个无障碍的、经过充分测试的组件被构建一次、并在数十项服务中复用时,你在一个地方修复一个无障碍缺陷或一处安全模糊之处,每一项服务都会继承这个修复。另一种选择——处处都是定制的前端——意味着未知的、参差不齐的质量:有些服务满足网页内容无障碍指南(WCAG),有些则悄悄地排斥了那些最依赖公共卫生服务的人。

一致性也是一个理解力问题。患者与员工会在各项服务之间移动——一个国民保健署(NHS)应用、一家信托机构的门诊门户、一个全科诊所的预约工具——每一种陌生的模式都会施加认知负荷。在一个包括不适的人、焦虑的人、老年人、数字排斥者,或使用辅助技术的人在内的人群中,这种负荷不是均匀分布的。共享的模式能为所有人降低这种负荷。本主题讲的是让安全、无障碍、一致的设计成为阻力最小的路径、而不是一种英雄主义行为的机制——组件、模式、令牌、原型与设计运营。

核心概念#

一个设计系统是用于构建一组数字服务的可复用组件、模式、样式与指导的单一权威来源。它不仅仅是一份风格指南:它把可运行的、已编码的组件与设计理由、无障碍说明,以及告诉你何时以及如何使用每一个组件的使用指导配对在一起。两个最相关的公开范例是 NHS 设计系统(由 NHS England 维护,构建于 NHS.UK 前端之上)与由政府数字服务(GDS)维护的 GOV.UK 设计系统。两者都是开放的、免费提供的,并在数百万次互动中经受了考验。

一个组件库存放着离散的构建模块——按钮、表单输入框、页头、错误摘要——而一个模式库存放着针对反复出现的问题的更高阶解决方案:如何询问出生日期、如何组织一个问题页面的结构、如何报告一个错误、如何询问用户的 NHS 号码。组件是词汇;模式是句子。两者都借鉴了基于组件的软件工程,在这种工程方法中,系统由松耦合的、可独立测试的、可复用的部件组装而成。

设计令牌是以命名变量形式表达的最小共享决策——一种颜色、一个间距单位、一个字体大小、一个焦点状态的轮廓。因为令牌是按名称引用、而不是硬编码的,对一个令牌的一次改动(比如说,增大最小触控目标尺寸或对比度)会一致地传播到使用它的每一个组件。令牌是让一个系统在扩展规模时保持连贯的机制,也是让一个共享系统能够为本地使用而调整主题、却不必分叉它的机制。

单一权威来源是这个支配性的理念:每一项设计决策都在恰好一个地方被主控,因此它无法在各项服务之间悄悄失去同步。当一个组件的设计、代码与指导都存放在一个权威库中时,你就消除了那一类图示与产品不一致的缺陷。

软件原型制作是构建刻意不完整的服务版本、以便在你承诺构建真实产品之前先学到一些东西的实践。原型从低保真(纸质草图、灰度线框图)到高保真(交互式的、逼真的、通常用代码构建)不等。GDS 的原则是为学习而制作原型,而不是为保留它:一个原型的工作是通过与真实用户的可用性测试来回答一个问题,之后就被丢弃——这是一次性(或"快速")原型制作,不同于你打算把它打磨成生产版本的演进式原型。

DesignOps(设计运营)是大规模运行设计工作的学科——保持一个共享设计系统在整个机构或整合照护系统(ICS)范围内健康、有资金支持、值得信赖的人员、工作流程、治理、贡献模式与工具。它之于设计,正如平台工程之于代码:运作良好时几乎不可见,出问题时却痛苦地明显。原型制作在诸如 Figma 这样的设计工具中进行,或直接使用一个设计系统的前端在代码中进行,这把我们带到了前端网页开发——HTML、CSS 与 JavaScript 这一层,复用在这里真正降低了重复、成本与风险。

本主题刻意不重复涵盖用户需要什么(见主题 3.0——用户研究与服务设计)或文字如何撰写(见主题 3.1——内容设计与健康素养)。这些学科为设计系统提供输入;本主题讲的是把它们的结论安全地带入生产环境的可复用机制。

最佳实践#

1. 先采用,再构建。 从 NHS 设计系统与 GOV.UK 设计系统出发,而不是自行发明。它们已经编码了多年的无障碍测试、内容设计,以及在医疗与政府服务中的真实使用经验。重新发明一个日期选择器或一个错误摘要,不是对稀缺、昂贵的设计与工程产能的良好利用,一个自制版本几乎总是无障碍性更差。为本地需求扩展并调整这些系统的主题;不要在没有刻意的、有文档记录的理由的情况下分叉它们。

2. 把无障碍性与临床安全构建进共享组件,而不是单个屏幕。 一个设计系统整个经济与安全论证的基础,就是你只修复一次、然后在各处继承它。一个无障碍的、支持键盘导航的、经过屏幕阅读器测试的出生日期组件,只需构建与保证一次,就能保护使用它的每一项服务。把 WCAG 合规、合理的错误处理,以及与安全相关的行为(对破坏性操作的清晰确认、剂量与测量单位的明确无歧义)烘焙进组件本身,这样团队就不容易把它们弄错(见主题 1.9——数字包容与无障碍,以及主题 1.6——临床安全与风险管理)。

3. 为学习而制作原型,而不是为保留它。 把原型当作廉价、快速地回答一个具体问题——"一位健康素养低的患者能完成这项转诊吗?"——的一次性实验来对待。让保真度与问题相匹配:早期用低保真草图来测试流程与理解力,后期用高保真的、已编码的原型来测试真实的交互、无障碍性与边缘情形。要抵制把一个原型直接推向生产环境的冲动;为学习速度而优化的原型代码,很少能安全、安保、可维护到足以支撑一项运行中的临床服务。

4. 当交互与无障碍性才是问题所在时,在真实的前端中制作原型。 设计工具原型(Figma 及类似工具)非常适合快速、协作地探索布局、流程与内容。但它们无法忠实地测试键盘导航、屏幕阅读器行为、焦点管理,或在老旧的 NHS 资产硬件上的性能表现。当这些正是风险所在时,使用设计系统的前端在代码中制作原型,这样你测试的东西才接近真实用户实际用真实辅助技术所体验到的东西。

5. 在构建之前用真实用户测试原型。 一个从未展示给具代表性用户的原型,只是一个昂贵的意见。与反映你真实人群的人一起测试——包括老年人、残障人士、数字信心不足的人,以及在时间压力下工作的员工。即使只有五位参与者,也能揭示出大多数严重的可用性与理解力问题,在原型中发现它们,比在生产环境中发现它们便宜好几个数量级(见主题 3.7——测试与质量保证)。

6. 把令牌当作一致性的契约来管理。 把颜色、间距、排版与交互状态表达为命名的设计令牌,并以对待一次共享依赖变更同等的严肃程度对待它们的变化。令牌让你能够在整个系统范围内强制执行最小对比度、触控目标尺寸与焦点可见性,并让一个本地团队能够为自己的品牌重新调整主题,而不破坏底层的无障碍保证。当一项国家标准发生变化时,你想要的是只改动一个令牌,而不是审计一万个屏幕。

7. 运行一种贡献模式,而不是一座围墙花园。 一个只接受一个中央团队输入的设计系统,永远会落后于真实的服务需求,并会招致交付团队的怨恨。发布一条清晰的路径,让团队能够提议新的组件与模式,并明确什么会被接受、由谁审查,以及在任何东西被提升到共享库之前无障碍性与安全性如何被保证。这是核心的 DesignOps 工作:它平衡了本地灵活性与共享一致性之间的张力,而不让系统腐烂或分裂。

8. 对变更进行版本管理、文档记录与沟通。 把设计系统当作一个拥有用户(你的交付团队)、路线图、发布说明与支持渠道的产品来对待。语义化版本、变更日志,以及清晰的弃用通知,能让团队按照自己的节奏安全地采纳改进。未经记录的破坏性变更,会摧毁让团队选择共享系统而不是自行搭建的那份信任。

9. 衡量采用率与质量,而不仅仅是存在与否。 一个设计系统只有在被使用时才能创造价值。追踪哪些服务使用了共享组件,团队在哪里不得不构建定制替代方案(以及为什么),以及随着采用率上升,无障碍合规性是否有所改善。高比例的本地变通做法是一个信号,说明系统缺失了某种真实的东西——把它们当作积压清单,而不是不服从来对待。

与团队讨论的问题#

1. 共享一致性与本地灵活性之间的界线应当划在哪里?谁有权决定? 这是任何设计系统的核心治理张力。太僵化,交付团队会感觉受阻,构建影子组件,并绕过系统——从而碎片化你本想保护的那种一致性。太松散,"系统"就会变成一堆缺乏共同安全或无障碍保证的、关联松散的一次性作品。在医疗与照护语境中,利害关系是具体的:有些差异是合理的(一项精神健康危机服务与一个常规预约工具确实有着不同的需求),有些差异却是危险的(确认一项破坏性临床操作的方式不一致)。一个好的答案会说出哪些决策是不容商量的(无障碍性、安全攸关的模式、核心交互行为),哪些对本地主题调整是开放的,并定义一个明确的、人性化的流程,让团队能够请求例外或贡献一个新模式,而不仅仅是禁止分歧。

2. 无障碍性与临床安全实际上要如何在我们的组件内部得到保证——谁来签核? 声称无障碍性与安全性已经"烘焙进去"很容易;要真正保证它却很难。这个问题迫使你具体说明保证流程:谁按照 WCAG、用哪些辅助技术、与哪些残障用户测试每一个组件;与安全相关的行为如何依据你的临床安全流程(DCB0129/DCB0160)被审查;以及在一个组件被发布为"可安全复用"之前,附带了什么样的证据。这场讨论应当揭示出诚实的缺口——也许你有自动化的对比度检查,却从未与一位真实的屏幕阅读器用户测试过,或者你的临床安全官从未审查过共享组件库。一个有力的答案会产生一位具名负责人、一套明确定义的测试制度,以及一条规则:没有组件能在没有文档记录的无障碍与安全证据的情况下进入共享库,因为一个被五十项服务继承的缺陷,是五十倍的伤害。

3. 当最初的热情消退之后,谁来资助、配置人员并维护这个设计系统? 设计系统常常是在一阵精力迸发中被创建的,然后在创始团队离开之后被悄悄抛弃,留下一个团队不再信任的陈旧库。这从根本上是一个 DesignOps 与资金问题,而不是一个设计问题。诚实地讨论你是否有一支常设的、获得资助的团队,把这个系统当作一个持续的产品来负责——拥有支持、贡献审查、版本管理,以及跟上 NHS 与 GOV.UK 上游系统步伐的产能——还是你在依靠一种会蒸发的善意。在一个 ICS 中,这一点更加尖锐:这个系统是由一个占主导地位的机构拥有,还是被共同治理,或是在它们之间无人认领?一个好的答案会把设计系统当作一项长期存在的基础设施来对待,拥有具名负责人、一份持续的预算,以及与它所构建的国家系统之间清晰的关系,而不是一个会"完成"的项目。

4. 我们与上游的 NHS 与 GOV.UK 系统是什么关系?随着它们的变化,我们要如何保持同步? 采用一个国家级设计系统不是一次性的下载;它是对一个你无法掌控的基础设施的持续依赖。这个问题迫使你刻意地决定,你处于"轻度调整主题并紧密跟踪上游"到"分叉并分歧"这个谱系的哪个位置。每一种选择都有代价:保持紧密意味着按别人的节奏吸收上游变更(一次新的无障碍修复、一个修订过的模式),并偶尔要重做本地定制;分叉则意味着你要自己承担国家团队本会免费给你的每一次未来的无障碍与安全修复。在医疗与照护领域,分歧的拉力是真实的——临床工作流程与本地品牌会造成真实的压力——但每一次分歧都是一项常设的负债。一个好的答案会说出谁在关注上游的发布说明,本地扩展是如何被组织的、使其能够经受住一次上游更新,以及一项拟议的分歧在被允许之前必须通过的明确测试,这样"我们需要它看起来不一样"就永远不会悄悄变成"我们现在维护着一个陈旧的、无障碍性更差的 NHS 日期选择器分叉"。

5. 我们要如何真正守住"为学习而制作原型"与"为保留而构建"之间的界线? 每个人在原则上都同意,一次性原型不应变成生产服务;失败发生在截止日期压力之下,当一个令人信服的高保真原型就摆在那里,直接上线它看起来像一条捷径。这个问题让这条界线变得具体,而不仅仅是一种愿景。讨论究竟是什么在实际上阻止原型代码——为学习速度而优化、而不是为安全性、韧性或可维护性——被提升为一项运行中的临床服务:是一种技术上的隔离(原型在一个无法触及生产环境的沙箱中构建),一道治理关卡(没有临床安全签核就无法上线),还是仅仅是一种在交付日期第一次滑坡时就蒸发的共同良好意愿?医疗与照护领域的利害关系是具体的,因为一条临床路径中未经保证的代码,是一次患者安全暴露,而不仅仅是技术债。一个诚实的答案会承认压力将来自何处,说出谁有权说不,并定义"从经过保证的组件重新为生产环境构建"实际上要求什么,这样这条界线在被检验时才能守住。

6. 我们要如何知道这个设计系统实际上是否在起作用?当指标令人不安时我们会怎么做? 一个设计系统可以存在、被精美地文档化,却依然几乎没有创造价值,如果团队悄悄绕过它的话。这个问题把讨论从"我们有一个设计系统"推向"它是否名副其实"。决定你将衡量什么:各项服务间的采用率、定制变通做法的比例与原因、随着采用率上升无障碍合规性是否真的改善,以及团队通过复用而不是重建节省了多少时间。困难的部分不是收集这些数字,而是提前商定你将如何解读它们——因为高比例的本地变通做法,是共享系统缺失了某种真实东西的信号,而不是交付团队不服从的证据。一个好的答案会承诺把令人不安的采用数据当作积压清单与路线图的输入,定义谁审查它、多久审查一次,并抵制只衡量讨喜的东西(存在、下载量),而不是真正重要的东西(更安全、更无障碍、更一致的服务真正被交付)的诱惑。

实践中:一个医疗与照护案例#

一个覆盖三家急症信托机构、一家精神健康信托机构与一家社区服务提供者的整合照护系统,决定整合其面向患者的数字资产。今天,每个机构都运行着自己的门诊门户;它们之间有四种不兼容的日期选择器,三种不同的询问 NHS 号码的方式,以及天差地别的无障碍合规性。一次内部审计发现,四个门户中只有一个通过了其预约流程的基本屏幕阅读器测试——一个明显的公平与临床安全暴露。

该 ICS 组建了一支小型的、联合资助的设计系统团队。他们没有从零开始构建,而是采用 NHS 设计系统作为基础,并为 ICS 特定的品牌定义了一层薄薄的本地设计令牌,再加上少数真正属于本地的模式(例如,一个预约传译支持的共享模式,这是任何一个国家系统都没有涵盖的)。每一个共享组件都携带有文档记录的 WCAG 证据,并在发布之前依据 DCB0129 流程获得该 ICS 临床安全官的签核。

在重新构建门诊预约流程之前,团队先制作原型。他们从低保真开始,与十二位为反映本地人群而招募的参与者一起测试新流程的纸质与灰度版本——包括两位屏幕阅读器用户、三位 75 岁以上的老人,以及几位数字信心不足的人。这个原型揭示出一个严重的理解力问题:患者无法区分"改期"操作与"取消"操作。团队修复了这个模式,然后用设计系统的前端构建了一个高保真的、已编码的原型,并重新测试,这一次在一家合作信托机构门诊实际使用的硬件上确认了键盘与屏幕阅读器行为。

只有到那时,他们才动手真正构建,大部分生产服务是由经过保证的、可复用的组件组装而成的。十八个月后,一次 WCAG 更新收紧了焦点可见性的要求。因为焦点样式存放在一个单一的设计令牌中,团队只需发布一次变更,每一项 ICS 服务都会在下一次发布中继承它——在旧的碎片化资产之下,这样的修复本会意味着五个独立的整改项目,而且现实地说,至少会有一项服务被落下、依然坏着。

行业视角#

初创企业#

一家小型数字医疗初创企业几乎绝不应当从零开始构建自己的设计系统——它负担不起无障碍测试的开销,而投资者付钱是为了临床验证,不是为了定制按钮。在你为 NHS 用户构建产品的地方,采用 NHS 或 GOV.UK 前端,并把原型制作当作你的核心竞争优势:廉价、快速、一次性的原型与真实患者一起测试,能让你比资金更充裕的老牌企业学得更快。风险在于相反的方向——为了赶上一场投资人演示,把一个光鲜的高保真原型直接推向生产环境,把未经保证的、不安全的代码带入一项运行中的临床服务。即使在资金压力下,也要在"为学习而制作原型"与"为保留而构建"之间保持一条硬性的界线。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院,或一家正在委托一款面向患者工具的单一场所诊所——拥有在册的患者,却没有专门的设计或前端能力,也无法吸收定制组件的成本。它最有力的举措,是坚持要求任何供应商都在 NHS 或 GOV.UK 前端之上构建,这样无障碍与安全保证就是被继承的、而不是被承诺的,并把这当作合同的一项书面条件,而不是一种期望。它很少需要自己运行一个设计系统;它需要良好地使用一个,并认识到供应商光鲜的演示不是一项无障碍的、有保证的线上服务的证据。在它确实制作原型的地方——用它真实的、往往更年长或数字信心不足的患者测试一个新的在线预约流程——几次与真实用户的会话,能发现比一个精美的模型所能揭示的多得多的问题。它承担着与大型信托机构同样的法定无障碍与临床安全职责,因此诚实的问题不是要不要合规,而是如何从共享的国家基础设施中廉价地获得被继承的合规性。

大型企业#

一家大型 NHS 信托机构或健康科技公司已经有多个团队在构建重叠的界面,因此它的问题是碎片化与重复的成本。价值论证是一支获得资助的、常设的设计系统团队,运行一种真实的贡献模式,采用指标向领导层报告,并有一条通往临床安全与无障碍保证的清晰治理线。核心张力是政治性的:有实力的交付团队抵制放弃控制权,而一个强硬的中央团队会滋生影子组件。企业要靠让共享系统成为真正更容易的选择——有良好的文档、良好的支持,并有可证明的更高质量——而不是强制推行并寄予希望来取得成功。

政府机构#

一个国家机构,如 NHS England 或 GDS,把设计系统当作被它无法掌控的机构使用的公共基础设施来运营,因此开放性、稳定性与向后兼容性极为重要。它的义务是最强的:法定的无障碍法规、平等职责,以及一个共享国家组件中的一处缺陷会传播给数百万公民这一现实。这项工作更多的是关于管理,而不是发明——清晰的版本管理、弃用政策、详尽的无障碍证据,以及对下游数百个团队的响应能力。NHS 设计系统与 GOV.UK 设计系统之所以是参考范例,正是因为它们把这个系统当作一项长期存在的公共物品,而不是一个项目来对待。

常见失败模式#

• 被抛弃的系统。 一个设计系统在一片喧嚣中被建成,然后在创始团队分散之后被无人维护;团队失去信任,重新漂向定制工作。避免的方法是资助一支常设的产品团队,而不是一个一次性的项目。
• 说谎的图示。 设计文件与生产代码不一致,因为没有单一的权威来源,导致"设计系统"描述的是产品已经不再做的事情。让已编码的组件及其文档保持权威,并一起进行版本管理。
• 无障碍性被当作事后补充。 组件在没有真实辅助技术测试的情况下被发布,导致一个不具无障碍性的模式在各处被继承——放大而不是减少伤害。要求在任何组件被发布之前提供有文档记录的 WCAG 与屏幕阅读器证据。
• 原型直接进入生产环境。 一个高保真原型为了节省时间被直接提升为一项运行中的服务,把不安全、不可维护、未经保证的代码带入一个临床环境。执行一次性原则;从经过保证的组件为生产环境重新构建。
• 围墙花园。 一个中央团队拒绝所有贡献,导致这个系统从未满足真实的服务需求,交付团队绕过它。发布一个贡献与例外流程,把本地变通做法当作积压清单信号来对待。
• 一致性的表演。 在真正需要本地差异的地方(危机服务、儿科)强制推行僵化的统一性,以整洁的名义损害安全性与可用性。区分不容商量的决策与合理的本地决策。
• 测试了错误的保真度。 交互与无障碍风险只在一个无法测试键盘或屏幕阅读器行为的静态设计工具中被"测试",给人虚假的信心。当交互才是问题所在时,在代码中制作原型。

成熟度模型#

检查清单#

• 你已采用 NHS 设计系统与/或 GOV.UK 设计系统作为基础,而不是从零开始构建。
• 共享组件携带有文档记录的 WCAG 合规证据,与真实辅助技术及残障用户一起测试过。
• 与安全相关的组件在被发布供复用之前,已依照你的临床安全流程接受审查。
• 设计令牌管理着颜色、间距、排版与交互状态,让整个系统范围内的变更能从一个地方进行。
• 存在一个单一权威来源,已编码的组件及其指导存放在其中并一起进行版本管理。
• 原型的保真度与问题相匹配,用一个具代表性的用户样本测试过,并被当作一次性的东西对待。
• 与交互及无障碍性攸关的流程是在代码中、而不仅仅是在一个设计工具中制作原型的。
• 一支获得资助的、具名的团队把设计系统当作一个持续的产品来拥有,拥有路线图与支持渠道。
• 一份已发布的贡献与例外流程,让交付团队能够提议新的组件与模式。
• 采用率与质量被衡量,高比例的本地变通做法被当作积压清单、而不是不服从来对待。

关键来源#

• NHS 设计系统 ——NHS England:面向 NHS 数字服务的组件、模式、样式与无障碍指导。
• GOV.UK 设计系统 ——政府数字服务:面向英国政府服务的样式、组件与模式。
• GOV.UK 服务手册——原型制作与"制作一个原型" ——政府数字服务:关于为学习而制作原型并与用户测试的指导。
• NHS 数字服务标准 ——NHS England:共享的、一致的服务据以被评估的标准。
• 网页内容无障碍指南(WCAG)2.2 ——W3C 网页无障碍倡议:无障碍合规标准。
• 《2018 年公共部门机构(网站与移动应用)无障碍法规》 ——英国政府:公共部门服务的法定无障碍职责。
• DCB0129 / DCB0160 临床风险管理标准 ——NHS England:健康 IT 系统制造与部署的临床安全标准。
• 设计委员会双钻石模型 ——设计委员会:支撑探索与设计的发现-定义-开发-交付模型。

参考文献#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards