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

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

代码封装

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

 

声明：* 本站所提供的资源均来源于互联网，站内所有文字、图片内容由网站会员上传而来，UI社不具备此内容的版权。由于将本站资源用于商业用途而引起的纠纷，本站不负任何责任。如果有侵犯到您的权益，请联系本站删除，谢谢合作！联系邮箱：Uishe#qq.com (请将[#]换成@)