第 13 章安全、合规与可访问性

这一章谈的三件事,安全、合规、可访问性,在很多设计师眼里,是"别人的事":安全是工程师的事,合规是法务的事,可访问性是"有余力再说"的事。

这种认识,是 ToB 设计一个普遍而危险的盲区。这一章想纠正它。我的核心主张是:在 ToB,安全、合规、可访问,不是设计之外的附加项,而是设计之内的硬约束。它们必须从一开始就被设计认真对待,并且要在界面层被显性地、恰当地表达出来。把它们当成事后补丁,是要出大问题的,而且这类问题,往往是"出局级"的,不是"扣分级"的。

一、为什么这三件事是设计的硬约束

先说清楚,为什么这三件事对 ToB 设计是"硬约束",而不是"软建议"。

因为 ToB 软件服务的是组织,而组织的运转,嵌在一个由法律、监管、责任构成的现实世界里。这三件事做不到的后果,组织往往无法承受。一个金融系统不合规,会被罚款、被监管处罚,严重的甚至吊销牌照。一个医疗系统数据泄露,会酿成严重的事故和法律责任,还可能伤害到具体的病人。一个政务、教育、公共服务系统不可访问,会把一部分公民(残障人士、老年人)直接排除在公共服务之外,这既是法律问题也是伦理问题(伦理部分,下一章会专门谈)。

注意这些后果的性质:它们不是"体验差一点、用户少一点"这种可以慢慢优化的问题,而是"做不到就出局"的红线。所以,安全、合规、可访问在 ToB 不是"做得好加分",而是"做不到出局",它们是产品能不能存在的前提。

设计师在其中的责任是什么?是把这些约束,翻译成恰当的界面表达。安全、合规、可访问的要求,最终都要落到用户能看到、能操作的界面上。一个权限规则,要体现为"用户看到/看不到什么、能/不能点什么"。一个合规要求,要体现为"某个操作必须留痕、某个信息必须脱敏"。一个可访问要求,要体现为"这个按钮屏幕阅读器能读到、键盘能操作"。

这种翻译,是设计师独有的、无法假手他人的工作。工程师能实现一套权限系统,但"无权限的功能到底该隐藏还是禁用"这个体验决策,是设计师的事;法务能列出合规要求,但"怎么让必要的合规动作不打断用户"是设计师的事。所以,这三件事不仅是设计师该关心的,而且有相当一部分,只有设计师能做好。

二、安全:把权限模型变成界面秩序

ToB 安全的核心,很大程度上是"权限",谁能看什么、谁能做什么。这背后,是一套权限模型。

最常见的权限模型是"基于角色的访问控制(RBAC)",给角色分配权限,再把用户归入角色。这和我们全书反复讲的"角色"一脉相承:角色不仅决定了用户看到什么功能(第五章的角色化),也决定了他被授予什么权限(安全)。更精细的还有"基于属性的访问控制(ABAC)",权限不只看角色,还看各种属性(数据归属、时间、地点、设备等),能表达更复杂的规则,比如"只能看自己部门的数据""只能在办公网络内操作"。

权限模型对设计的影响,是深刻而具体的。它是信息架构的一层"隐形骨架",同一个系统,不同权限的用户看到的是不同的界面。设计师必须把权限的逻辑想清楚,并在界面上如实地表达。

这里有一个常见的、需要拿捏的设计决策:没有权限的功能,是该隐藏,还是该禁用并提示?

两种做法各有适用场景,这是有讲究的。隐藏:界面更干净,用户看不到与自己无关的东西,适用于那些"这个角色压根不该涉及"的功能,比如普通员工根本看不到"系统管理"入口,干净利落。禁用并提示("此功能需要 X 权限,可联系管理员申请"):用户知道有这么个功能、也知道怎么获得它,适用于那些"用户可能需要、且可以申请"的功能,让用户有清晰的预期和路径,而不是一脸茫然"为什么别人有我没有"。

选错了会很尴尬:该隐藏的去禁用提示,界面被一堆灰色的、点不动的东西塞满,徒增困惑和挫败;该提示的去隐藏,用户明明该有这权限却找不到入口,只能到处问。判断的依据,是"这个用户是否应该知道这个功能的存在、以及他是否有合理路径去获得"。

权限设计还有一个常被忽视的体验维度:别让安全变成处处掣肘的折磨。

安全和效率天然有张力,管得越严,用得越不顺。糟糕的安全设计,会让用户每点一下都撞墙、动不动就"无权限"、申请个权限要走九曲十八弯、还看不到申请进度。我见过一个系统,权限切得过细,结果一个员工想完成本职工作,要分别申请七八个细碎权限,每个都要等审批,等他权限齐了,黄花菜都凉了。这种"安全"反而成了业务的阻碍。

好的安全设计,是在保证安全的前提下,尽量减少对正常工作的干扰:该管的严管(高敏感操作绝不放松),不该管的别添乱(常规工作流畅通行),权限不足时给出清楚的说明和便捷的申请路径。在"安全"和"效率"之间找到那个恰当的平衡点,是 ToB 设计师的一项重要功夫。这又是"理性之美":在刚性的安全约束里,做出不折磨人的、体贴的设计。

三、合规:让操作可追溯、信息可保护

合规的要求千差万别(不同行业、不同地区的法规各不相同,且时常更新),但落到设计上,有几个反复出现的共性主题。

一是操作可追溯。很多合规要求的核心,是"凡操作必留痕",谁、在什么时间、做了什么、改了什么(从什么改成什么),都要有完整、不可篡改的记录(审计日志)。这对设计的要求是:关键操作的留痕要被妥善地设计,既要完整准确地记录(不能漏),又要让有权限的人能方便地查阅和追溯。这里有一个常被做得很烂、却很重要的设计点:审计日志的可读性和可检索性。我见过太多系统的审计日志,是一堆密密麻麻、满是技术字段和编码的流水,真出了事要查"上个月谁改了这条记录",得让工程师写脚本去捞,这种日志,合规上"有"了,实用上等于"无"。一份好的审计日志,应该让有权限的业务人员自己就能按对象、按人、按时间方便地查询,能看懂"谁在何时把什么从 A 改成了 B"。把审计日志当成一个需要认真设计的功能,而不是一个堆数据的垃圾桶。

二是信息可保护。合规常常要求对敏感信息(个人隐私、商业机密、金融数据、医疗数据)进行保护:脱敏、加密、访问控制、最小化展示。设计上,这体现为几个判断:敏感字段什么时候该打码、什么时候该明文(以及谁有权看明文,比如客服只能看到手机号后四位,而风控在特定流程下可看全)?信息的展示遵循"最小必要"原则,不该出现的地方就别出现,不是所有页面都需要把身份证号完整列出来。在数据隐私法规日益严格的今天(各国各地区都在加强个人信息保护立法),这一块的分量越来越重,设计师必须有这根弦。

三是合规与体验的平衡。和安全一样,合规也常常和体验有张力,合规要求的那些确认、留痕、声明、授权,都可能给流程添堵。设计师的价值,是在满足合规的前提下,把这些必要的"麻烦"做得尽量顺滑、不突兀。举一个正反对比:一个必须的"用户授权同意"(合规要求),可以做成一个突兀的、强制全屏、必须勾选一堆条款才能继续的弹窗(让人烦躁、闭着眼睛就点了同意),也可以融入流程、在恰当的位置清楚而不打扰地呈现、把关键条款用人话讲明白。同样满足合规,体验可以天差地别。又是"理性之美"的用武之地:在刚性的约束里,做出柔性的、体贴的设计,让合规不成为体验的敌人。

四、可访问性:从 WCAG 到 AI 时代的新挑战

可访问性(Accessibility),是这三件事里最常被 ToB 设计师忽视的一个,但它的重要性正在快速上升。

可访问性的核心,是让所有人,包括有视觉、听觉、运动、认知障碍的人,都能使用你的产品。这在 ToB 尤其重要,原因有二。一是 ToB 软件常常是"必须用"的工作工具,如果一个有障碍的员工,因为系统不可访问而无法完成工作,这直接剥夺了他的工作能力,这不是"体验差",而是"被排除在外",是严肃的问题。二是越来越多的地区,把可访问性写进了法律(尤其是政府、公共服务、大型企业领域的采购),不达标就直接失去投标资格、直接出局。

可访问性有成熟的国际标准,就是 WCAG(Web 内容无障碍指南)。它提供了一套具体的、可执行的要求,涵盖四个核心原则,设计师不需要背全文,但应该理解这四个原则并融入日常。可感知:信息要能被感知到,比如图片有替代文本(让屏幕阅读器能读)、不能只靠颜色传递信息(呼应第七章,要辅以图标、文字、形状)、足够的颜色对比度(弱视者也能看清)。可操作:界面要能被操作,比如所有功能键盘都能完成(不依赖精确的鼠标动作,这对运动障碍者至关重要)、清晰的焦点指示(用键盘时知道自己"选中"在哪)、不设置会让人来不及反应的时间限制。可理解:信息和操作要易于理解,比如清晰的标签、可预期的行为(第六章的一致性)、友好的错误提示。健壮:内容要能被各种辅助技术(屏幕阅读器等)正确解析,这要求规范的结构和标记。

这些大多是举手之劳却影响巨大的事:给图标配上文字标签、保证对比度达标、让键盘能走完所有流程、状态不只用颜色区分。它们不需要多少额外成本,只需要设计师"心里有这根弦"。

而 AI 时代,给可访问性带来了全新的、严峻的挑战。

上一章讲生成式 UI 时已经预警过(而且预警了两次):当界面由 AI 动态生成,它可能打乱屏幕阅读器的朗读顺序、破坏键盘导航的逻辑、让依赖辅助技术的用户彻底迷失。一个为视力正常用户"智能优化"、不断变化的动态界面,对一个依赖屏幕阅读器、靠记住固定结构来操作的视障用户,可能是一场灾难,他刚记住的顺序,下一刻又变了。

这意味着,在 AI 时代,光遵循传统的 WCAG 已经不够了,我们还需要针对 AI 生成内容的、专门的可访问性准则,给 AI 的生成能力设置边界,确保无论界面怎么动态变化,可访问性的底线(朗读顺序合理、键盘可达、有稳定的锚点)始终被守住。这是一个全新的、还在探索中的领域,也是这一代设计师要去开拓的责任。

最后,我想纠正一个对可访问性的普遍误解。很多人觉得可访问性是"为少数人做的、费力不讨好的事"。但事实上,好的可访问性设计,往往让所有人都受益,这叫"通用设计(Universal Design)"的理念。更高的对比度,让强光下的所有人(比如户外作业、第三章讲的特殊环境)都看得更清。清晰的键盘操作,让追求效率的熟练工(第六章)也更快,他们也爱用键盘。简明的结构和文字,让每个人(包括疲惫的、分心的正常用户)都更易理解。

可访问性不是慈善,而是好设计的应有之义。把它做好,你不只是帮助了有障碍的用户,你是让产品对每个人都变得更好。这个认识转变很重要,它能让你从"被迫做合规"的心态,转向"借此把产品做得更普适、更好"的心态。

本章要点清单

三件事是"硬约束"非"软建议":做不到是"出局级"后果(罚款/事故/失去投标资格),不是"扣分级"。
设计师的独有责任:把安全/合规/可访问"翻译"成界面表达,很多决策只有设计师能做好。
安全:权限是信息架构的隐形骨架。无权限功能"隐藏 vs 禁用提示"按"是否该知道 + 能否申请"判断;别让安全变成处处掣肘(权限别切太碎、申请要顺、有进度)。
合规:操作可追溯(审计日志要可读可检索,别做成技术流水垃圾桶)、信息可保护(脱敏、最小必要)、把必要的合规动作做得顺滑不突兀。
可访问性:WCAG 四原则(可感知/可操作/可理解/健壮),多是举手之劳;AI 动态界面带来新挑战,需专门约束;通用设计让所有人受益,非慈善。

小结

这一章,我们正视了 ToB 设计三个不可逾越的硬约束。安全,核心是把权限模型翻译成清晰的界面秩序,并在严管与效率间找平衡;合规,核心是让操作可追溯(审计日志要可读)、信息可保护,并把必要的"麻烦"做得顺滑;可访问性,核心是遵循 WCAG 四原则,应对 AI 动态界面带来的全新挑战,并理解"通用设计让所有人受益"。这三件事,都不是设计之外的附加项,而是设计之内、必须从一开始就认真对待的责任。

讲完了这些硬性的约束,我们自然会触及一个更深的话题:设计的责任,不止于满足法规,还在于它对人、对社会的影响。这就把我们引向了第四篇,以及其中那个关于设计伦理的章节。但在谈伦理之前,我们先升维到组织层面,设计如何在一个团队、一个组织里规模化地创造价值。下一章,进入第四篇:设计团队与设计领导力。