1. 降低心理压力
云计算产品提供给用户的不可回撤操作，例如下线机器、删除数据等可能是高风险甚至是危险的。这些高风险操作会给用户带来操作心理压力，使得用户在使用产品时需要时刻小心。在产品设计上遵循以下原则可以有效的减轻用户使用产品时的心理压力。
- 不知道读者是否经历过，当正要点击某个按钮时，按钮因为某些原因移位导致你点到了别的东西。在 To C 应用中这种体验最坏情况可能只是用户找不到先前的位置。但在云计算产品中可能会导致用户失误删除数据或者错误下单给企业造成损失。保障用户在页面操作时的视觉稳定对于云计算产品的安全操作非常重要，产品可以使用累积布局偏移 (CLS)指标来衡量和优化该部分的用户体验。
- 对用户的提醒绝对不是“加红加粗”就可以的，对于高风险操作应当有着统一的符号、文字和色彩标识，并做到操作前明确提示操作后果，操作后及时反馈。对于部分产品还可以设置安全操作区域的概念，将高风险操作按钮放置在集中位置，给用户提供在特定区域内可以安全操作的心理预期。
2. 保存用户状态
用户状态指的是用户在使用产品时产生的状态，例如标签页的展开收起，未完成的上传文件等等。它们通常不会被持久化到服务端，在下一次进入页面或者浏览器刷新时就会丢失。这些状态的丢失不会阻塞产品的使用，但会对用户操作效率与体验带来不好的影响。良好体验的云计算产品应当遵循以下原则：- 目前大部分云计算产品界面都使用了最新技术构建，但是操作状态在不少的线上产品被直接舍弃，当页面切换、工作空间变更时，浏览器会整体并重置状态。刷新并重置浏览器可以省去开发者维护内存状态的成本，但这种偷懒的做法只会给用户带来更多的麻烦。
- 在云计算产品中，可能会出现需要用户长时间等待的异步操作，例如上传文件或者异步操作状态机更新。当用户切换页面时，将当前未完成任务收纳至后台并同时给出提示对用户更加友好。
- 有时我们不得不丢失用户状态，例如用户刷新浏览器或跳转至其他产品。在这种情况下，我们可以给予用户强提示，明确告知用户当前的操作状态会丢失，避免用户产生困惑。
3. 保证数据时效
除了少数在线文档编辑产品以外，大部分云计算产品仍然采用的是轮询的方式从后端获取最新数据，这也就意味着在轮询的间隔中，产品中展示的数据可能与真实数据并不一致。使用者们大多会对于界面数据的滞后有心理预期，但是当用户在界面中进行切换页面，启停任务等操作后，数据依然滞后就会变得让人难以理解。为了保障在轮询机制下的数据时效，我们可以从以下几点入手：- 这里特定的时机指的是用户对页面进行操作的时机，通常来说有浏览器窗口聚焦、导航路由切换、页面切换、状态机操作等等，产品可以根据情况对这些常见操作进行聚合，并在这些操作后对页面的数据进行刷新，保障时效性。
- 数据不仅在界面与接口间需要保持同步，在界面内部同样需要。想象一下，如果一个任务的状态在页面的顶部显示正在运行，而在底部显示累计运行时长为 0 秒，一定会对用户造成困扰。对于描述同一实体的相互关联信息，例如对于单个作业的运行记录、运行时长与状态，在界面的不同区域需要同步进行更新，防止出现界面展示数据状态自相矛盾的情况。
4. 提供及时反馈
操作反馈指的是产品对用户操作所产生的反馈，通常指界面发生的变化，例如状态更新、页面跳转、弹出窗口等等。操作反馈是用户与产品交互的关键一环，无法得到操作反馈会让用户感受到无助和懊恼，严重伤害产品的用户体验。我们可以按操作先后顺序将反馈分为以下两类：- 对于一些不可逆操作，在用户操作前要明确告知当前操作的后果，以减少用户发生误操作造成问题或者资损的可能性。
- 产品设计中，会存在由于用户权限等原因而产生的不可点击区域，当用户试图操作这些不可点击区域时，应当给出不可操作的原因提示，避免用户误认为该项功能出现 Bug 不可用。
- 所有的用户操作在执行后都应当立刻产生反馈，无论该操作是否能立刻得到结果。
- 当前的操作可以立刻得到结果，例如“文件删除成功”、“数据保存失败”等情况。这种情况下常使用浮层信息提示用户操作结果，当有额外的失败信息需要展示时，浮层中还可以包含额外的指引内容。当页面的展示因为用户操作会产生明显变化时，例如列表数据直接新增或删减情况，也可以略过浮层信息提示，直接更新列表内容。
- 用户的操作需要经过一段时间才能得知结果，例如“文件上传”，“异步数据更新”等情况。这时我们可以使用进度条来标识当前的进度。如果系统无法给出阶段性进度与无法计算进度百分比的情况，可以新增“转换中”状态，或者添加虚拟进度条的方式减轻用户的等待焦虑。
5. 减少用户犯错
云计算产品的操作流程通常不可避免的冗长和繁琐，这是由其复杂的业务属性决定的。随着流程复杂度的提升，用户在操作流程中发生错误的概率也会变高。频繁发生的错误会迫使用户重复进入流程，给用户带来懊恼困惑等负面情绪，甚至会让用户对产品丧失信心。在产品设计与开发时，我们需要尽量做到以下几点：
- 云计算产品的很多操作有着很严格的前置依赖，例如在操作前需要获得授权，或者启动任务前申请相应的资源。当用户未满足这些前置条件进入了操作流程，就进入了必定报错的死胡同。提前检查前置依赖并设计后续引导流程可以协助提升流程成功率。
- 有时用户很难意识到操作执行后带来的影响，让用户在正式执行操作之前预览变动可以帮助用户预见下一步可能发生的情况，并及时修正可能发生的错误。
- 错误已经发生后应当立刻对用户透出。用户一段时间内可能会跨多个功能区域进行操作，如果错误没有及时透出，使用者会很难将错误结果与原因关联。
- 缺乏操作指引的报错信息会让用户对产品充满抱怨，良好的报错信息不仅要包含错误的内容，还应当包含给用户的操作建议。它们可以协助用户快速了解当前状况，并采取下一步行动。
6. 统一概念名词
云计算产品天然有着复杂度高，产品概念多的特点，这些产品概念需要用户深入学习后才能逐步理解。部分云计算产品的概念名词不统一，同一实体在不同的文案上有着不同的名称，这会误导用户并严重影响产品的使用体验。- 云计算产品中同一个实体在不同的时期可能会有着不同的名称，例如一段 SQL “文本”，在保存后可能会被称为 “文件”，在执行后可能会被称为 “任务”、“实例” 或者 “作业”。无论产品的逻辑有多么复杂，对于产品中的同一概念应当使用相同的名称描述。
- 云计算产品中有许多的概念并没有标准的中文翻译，例如 Kubernetes Deployments、Yarn Job、Flink TaskManager 等等。大部分云计算产品用户在上云之前已经熟知这些概念，如果产品对这些概念进行了翻译反而会使用户产生困惑。
7. 设计友好路由
URL 是云计算产品中定位应用信息的唯一标识，用户可以收藏或者分享当前 URL 以达到快速访问或排查问题的目的。完整的 URL 一般由 schema、 authority 、path、 query 和 fragement 组成，而良好的 URL 导航路由应当符合以下的要求：https://example.com/project/664f7c4d2153/?name=ferret#typology
\_____/ \_________/\___________________/ \_________/ \______/
| | | | |
scheme authority path query fragment
- 在 URL 中应当包含完整的关键业务信息，例如常见的
path 中包含的页面结构信息，query 中包含的表单请求信息，fragment 中包含的页面位置信息，当打开包含这些信息的 URL 时，应用应当可以直接装载特定页面，将请求信息回填，并定位到特定的页面位置。 - 当在页面中关键信息发生变更时，例如切换工作空间、更改列表页码、跳转链接时，URL 中的对应关键信息应当同步改变。这样可以方便用户随时收藏或者分享当前 URL。
- 网页标题指的是在浏览器中打开特定网页时，浏览器顶端标签显示的信息内容。可被用户理解的网页标题不仅可以指示用户当前访问的位置，还可以在多标签页访问及前进后退时帮助用户与其他标签页进行区分。
- 当 URL 被访问时，应用应当对 URL 中的信息进行鉴权与纠错处理，同时跳转到正确的 URL 上。以此防止用户越权访问，或者因接口拒绝访问而死锁。
8. 谨慎合并操作
云计算产品有时多次操作合并成一次快捷操作提供给用户，例如批量购买资源、重新启动等。这些合并操作可以提升用户效率，提升用户体验，但如果接口无法提供原子事务保障时，合并操作应当谨慎提供给用户。原子事务指的是在一次事务内发生的修改，要么全部发生，要么全部都不发生。云计算产品的很多操作不仅仅与数据库打交道，还会与基础服务设施，例如虚拟机、虚拟网卡打交道。这些基础服务设施大多无法提供像数据库一样的原子事务保障。在无法提供原子事务保障的情况下 ，不同的合并操作应当遵循不同的设计原则。- 需要经历中间状态的非原子失误操作禁止提供给用户。一键提交功能如果对应的是分别提交 A 与 B，当提交 A 成功而提交 B 失败时，用户将陷入必须手动单独操作 A 或者 B 的尴尬境地，更坏的情况是在产品中未考虑这种情况时造成的用户场景死锁。
- 对无法提供批量原子事务保障的操作应当明确告知用户单次操作的结果。当批量操作在某次操作失败时，应当明确提示用户，并询问用户下一步的操作建议。
9. 小心默认数值
默认值在大部分情况下是贴心且友好的，但是云计算产品中对待默认值要格外小心。相信不少人在接触云计算产品的繁琐步骤时，都会略过文档，不停点击下一步直至不能再继续为止。在这种操作逻辑下，默认值代表着这个值是被产品推荐，同时是无害的。以下两种类型的设定不建议在产品中给出默认值。- 云计算产品有大量的设定是与安全和资产相关的，例如是否开启自动续费、公网安全策略等等。这些重要设定如果系统给出了默认推荐，是很容易被用户忽略，造成安全风险与资产损失。
- 由于各种原因，云计算产品的一些设定在初始化后很难甚至无法被再次修改，例如机器所在的地域、工作空间的名称等唯一标识信息等等。这些无法被修改的信息在初始化的操作流程中同样不建议系统给出默认值。
10. 调整信息密度
许多云计算产品的初学者会抱怨界面的信息密度过大，导致他们不知从何下手。与此同时，一些老用户却会指责界面的信息密度过低，需要翻页跳转后才能查看完整信息。许多产品经理与交互设计师被这两种相反的用户建议搞得不知所措。云计算产品的信息密度设计应当遵循以下原则。
- 云计算产品天生就是有上手门槛的，新手用户在初学阶段很难完全掌握信息的作用。如果所有的信息都是用户刚需且相互关联，那么牺牲留白空间以展示这些信息是完全值得的。毕竟学习成本只有一次，而使用成本却是每次都会产生的。
- 在云计算产品的监控与管理系统中，用户通常需要查阅大量的信息才能够做出决策。与此同时，云计算产品在发展的过程中会经历信息的缺少、过载与收敛的过程。如果产品仍处于对用户暴露的信息不足阶段，例如报错信息、底层计算逻辑和关键指标仍然不足以让用户排查出相关问题时，隐藏所谓的“视觉过载信息”来获得良好的阅读体验显然是本末倒置的行为。
wyq0503于2022-03-02发布在
