安全是混合云管控体验的基本盘,也是核心竞争力。
 
 

Background

背景

 
去年,我们在混合控制台战役中也着重对安全体验做了全面提升。我们发现,混合云企业客户比个体用户会更加关注“人、财、物、权、法”的管理安全,安全感几乎需要渗透到操作链路的所有时点。观察用户在操作前、中、后的情绪曲线,我们认为:
  1. 通过包容性设计,让用户第一印象觉得很安全。比如,色彩使用上遵照常规语义通识,避免歧义。
  2. 在操作中通过实时反馈设计,让用户用着放心。比如,创建资源过程中,实时展示可用余量还剩多少。
  3. 在条件校验中进行容错设计,建立结果安全感。比如,输入信息校验前置、错误信息提示优化等。
  4. 在操作变更中尽量减少错误发生,营造变更安全感。比如,删除时二次确认、按钮置灰避免二次提交。
  5. 当已经发生了错误,通过优化报错反馈,让错误有迹可查,从而辅助尽快修复错误。
  6. 如果无法修复错误,通过回退机制尽量挽回。比如,资源删除默认放入回收站以防止误删。

Part 1

管控安全感

 

1 感知确定

 

研究表明,人们为了满足自己的安全需要,有时表现为寻求确定感,有时表现为寻求不确定感。具体来说,在不安全情况下,人们寻求不确定感;在安全情况下,人们寻求确定感。所以,为了在控制台体验中营造安全感知,需要让用户对不同场景、不同对象、不同状态时刻保持确定感。
我们总结了需要让用户感知确定的四种场景:
1)感知余量:总量=已用+余量。有些场景”余量”更需要被关注,因为“余量”决定了能否继续正常使用。
2)感知临近异常:“正常”让人感到“稳定”,“异常”让人感到“危机或不确定”。设计师除了要关注这两端的状态外,“临近异常”也是值得注意的。适当强化临近异常的状态展示,可以提前引导用户意识到异常即将发生,采取行动尽量规避异常发生。
3)感知有/无权限:有无权限直接影响是否需要展示。一般用户无权限的操作或内容,我们建议系统直接不展示,看不见意味着不会犯错,对用户会更安全。
4)感知当前是否可用:是否可用与权限无关,与状态有关,一般由某一时点下不同状态导致。我们建议将不可用的内容或操作 disable,但并非不展示,让用户依然能看见并保留一定暗示性。
 

2 放心使用

 

为避免一次性数据请求带来多个报错增加用户的修改成本,我们建议在较为复杂或输入项过多的长表单中增加实时校验的能力,或者在特定业务逻辑下(比如去重逻辑)也增加该能力。
 

3 有迹可查

 

当发生错误时,专有云用户和公共云用户对报错内容的诉求不同。公共云用户是资源使用人,运维能力较浅,当发生错误时,可以直接联系客服或通过工单解决。专有云部署在客户自己的私域,用户往往既是资源使用人又是运维人员,具备一定运维技能。还有一类是在客户现场驻场的运维人员,也需要通过查看尽可能详尽的报错信息来定位和排查问题。
报错信息一旦详尽,设计时就必须考虑如何在有限的空间内进行有效的展示。我们在单条报错和批量报错场景下,将错误详情字段默认折叠以节省空间,不干扰大部分非运维人员;只有当用户有运维需求时,可点击展开错误详情字段进行问题定位。
 

4 可以挽回

一些控制台提供给用户不可回撤操作,比如下线机器、删除数据等可能是高风险甚至是危险的。这些高风险操作会给用户带来心理压力,使得用户在使用产品时需要时刻小心。但想要完全杜绝错误发生,需要从产品机制上确保可回退,比如让部分核心云资源管理支持“回收站”功能,一方面可以节省资源,另一方面也可减轻用户使用产品时的心理压力。
 

Part 2

一体化落地

 

1 思考框架

业务彼此不互通,很可能让各自设计师在同类场景上重复造轮子;设计师经验不同,也可能导致同类规范存在交叉,相似但又不能完全被复用。我们抽象出了「TFACC 模型」,它能引导设计师从业务、用户、设计三个视角切入思考,从类型、功能、行为、容器、内容这五个维度细化分支,然后进行交叉分析,梳理出完整的规范全貌。
下面以「二次确认」为例,介绍我们是如何用它来制定规范的。

2 拆分推导

首先,要明确什么是“二次确认”?为了让用户减少甚至避免对重要数据的误操作或对重要操作的误触,我们需要在必要且合适的时候,让用户思考是否要这么做?目的主要是:
  • 防误触
  • 提醒用户检查
  • 告知用户提交后会发生什么
根据后果的严重性,我们将二次确认分为危险型和普通型两种类型,区别在于主行动按钮颜色不同,红色按钮比品牌色按钮更具警示性。根据确认是否打断操作,可选择用气泡或弹窗两种容器承载信息。根据用户确认前的行为,是选择了单个对象还是多个对象进行操作。二次确认的内容量有哪些,除了标题、详情、CTA 按钮,还可能有什么?
然后将有关联的子维度进行交叉分析,梳理出规范细则,主要明晰不同场景下对应的交互方式和布局样式。
最后,用树型脑图可视化指引如何正确选择合适的模式,并对应准确的设计方案作为参考。

Part 3

代码封装

 
设计规范沉淀到文档或者站点上还远远不够,受使用者经验影响,容易被误用。我们认为,只有将“设计规范本身”和“如何应用规范”全部代码化封装到物料或工具中,才能最大化保证设计规范被正确使用。比如,二次确认场景下,“如何选择对的弹窗样式”通过扩展弹窗类型让前端实现准确调用,“如何展示合理的内容”通过分区来对内容合理规划,这样能从一定程度上提升规范在实际开发应用环节的使用正确率。