混合云场景下“监管控”的设计模型及规则,AlibabaDesign,产品设计,可视化

混合云场景下“监管控”的设计模型及规则

混合云场景下“监”的设计模型及规则

云计算的全面爆发浪潮下，云平台已经不是简单的单个业务场景，而是由多种业务，多种云产品，多种云平台的组合与链接。“混合云”概念应运而生。而作为非技术出身的设计师，似乎很难与此类平台中的技术型用户建立同理心。

在实际混合云的业务场景探索过程中，我们发现了可以通过“监、管、控”三种典型的用户视角切入，通过总结设计场景化的设计模型，来保证混合云平台的用户体验一致性与规范性。

本期，我们重点分享“监”的视角：

什么是“监”

监（monitor）表示用户通过观察数字信息 ,数据图表 , 对应关系等方式获取数据 ;从广义来讲，数据是反映产品和用户状态最真实的一种方式，通过数据指导运营决策、驱动业务增长。

为什么需要“监”

任何云产品的使用 , 都依赖数据 ，这些数据可能是与业务目标直接相关的核心指标。数据监控是及时、有效的反馈出数据异常的一种手段，通过对数据的监视去观察是否异常，进而分析数据。在业务运行过程中，“监”不像其他产品，是业务的参与者，监控是一个旁观者，看着业务正常、高效运行；在发生异常时，监控像个侦探，发掘问题的源头；在灾难发生时，监控是兜底人，帮助业务系统发掘根本问题，第一时间恢复运行。对于一些隐藏较深的间接数据，是从侧面影响核心数据的，这个影响可能具有滞后性。如果能在其影响核心数据前，监控间接数据，并及时采取控制措施，那么可以将业务损失降至最低，影响范围降至最小。混合云作为云产品的一种，监控产品也构成“数据—人—行为”的闭环，设计此类产品需要满足用户两层需求：1. 提供准确实时的产品数据 ; 2. 产品数据引导正确的用户行为。

“监”场景下的用户分析及设计策略模型

只有清楚了解了用户，才能回归用户视角去思考问题，去基于他的体验痛点，给出    设计主张。进而我们从“监”产品的用户角度出发 , 来进行一系列的设计演变. 首先我们把企业中使用云的用户分为四类：决策者、运营管理人员、云用户、运维人员 , 通过分析各类用户人群功能及场景 ,进行具体的页面形态设计 。

主要人群核心诉求及数据场景分析

对于混合云产品用户 , 始终遵循兼容 , 准确 , 高效的设计准则进行全局设计 , 设计的核心点在于对数据进行处理及分析 , 按照设计模型 , 通过确定主次关系 , 层级关系 , 关联依赖 ,不同维度及对比分析 , 确定数据表达类型 , 在确定类型的基础上 , 进一步按照元素 , 结构 , 布局的设计形态进行深入化设计 。

结合混合云多种业务场景 ,总结概括不同图表类型 ,在结构上辅助设计图表选择

图表样式选择

提炼设计规范 ,统一设计元素

认知标准统一

在自然界中，原子是最小存在的单元，原子结合在一起形成分子，这些分子可以进一步结合形成相对复杂的有机物。而在产品的视觉体系里最小颗粒度的原子，我们理解是圆角、颜色、文字、栅格尺寸等这些最基础的视觉的组成要素；利用这些基础要素，我们形成以组件为单位的设计内容，如标题、按钮等控件。原子单位（基础设计要素）、组件、模块、模板、页面组成一个设计稿。在既定的设计语言和风格的指引下，归纳统一 ,实现设计语言的规范化、产品化和工具化。在基础模型的基础上 ,保证视觉展现相对统一 ,规范原子级组件样式 , 整理出数据卡片样式 ,图标使用规范 ,及大屏基础样式 ,规避相同数据多种相似样式情况。

01 数据卡片规范

02 图标图形使用规则举例

在混合云跨业务跨平台场景中，设计师经常会遇到对相同概念的名词选择图标或图形化的场景。为了整体平台的统一性,设定图标使用规范 ,规范覆盖天基、混合云、应用运维业务场景。提炼核心名词,分别统一线性,面性,2.5D,3Dicon的使用场景及规范。

03 大屏使用规范

越来越多的大屏场景出现在混合云业务中 ,针对大屏类的界面设计 ,梳理出基础版规范原子级样式 ,规范后续大屏界面。( 由于数据安全要求，数据部分已做模糊处理）

案例分析

对于决策者而言主要是通过数据助力决策 , 关注核心数据 , 注重全局信息 , 风险类信息及告警信息 . 使用场景通常为数据大屏 , 全局决策页面等 。

以混合云多Region大屏为例 , 首先对已有数据进行初步分析 ,确定大屏场景及各region之间的关系 ,从而进行初步框架设计 ,确定整体布局。

根据数据属性 ,选择合适的图表类型 ,多region大屏主题内容需突出专有云与公共云region使用分布情况 , 可以根据模型选择面积地图作为基础图形 ,进行视觉风格延展 ,增加较强的视觉处理形式 , 突出中心区域精细程度 。

基于数据变量的cpu使用率 ,slb负载均衡等使用条形图表示.

在大屏设计场景中，除了梳理业务、选择展现方式以外，也需要思考每个空间对观者的重要性；不浪费页面的每一寸“土地”，并且让“土地”的设计令用户感到愉悦、一目了然，还能快速获取到想要的信息。

对于运维人员主要是通过资源监控 , 发现告警 ,进行资源运维 ,在混合云运维平台产品维度监控案例里 , 设计需要反应多层级架构的产品分布

正常/异常状态，监控状态：到达终态、未到达终态。

我们首先确定数据之间的关系 , 区分出核心产品架构区 。

1.产品数量 , 集群总数等突出数值信息模块 ,选用小卡片结构将每部分信息进行聚合 ,

2.产品架构部分确定多层级架构形式 , 选择横向分布图 , 统一使用圆形基座 ,增加层级元素

以上是对混合云“监”相关业务场景做了简单模型梳理及规范介绍 ,面对复杂多样的云场景 , 需要我们持续优化模型形态及规范 ,满足准确 ,高转换 ,千人千面业务数据设计的同时, 保证全局的规范适用性 ,及视觉效果一致性。

“管”视角下的设计思维和策略

云计算的全面爆发浪潮下，云平台已经不是简单的单个业务场景，而是由多种业务，多种云产品，多种云平台的组合与链接。“混合云”概念应运而生。而作为非技术出身的设计师，似乎很难与此类平台中的技术型用户建立同理心。

在实际混合云的业务场景探索过程中，我们发现了可以通过“监、管、控”三种典型的用户视角切入，通过总结设计场景化的设计模型，来保证混合云平台的用户体验一致性与规范性。

本期，我们重点分享“管”的视角：

一.什么是“管”

1.管什么

混合云业务的管理对象可分为“人”、“资源”、“场”三个要素，每个要素都包含“云上”和“云下”两种属性。云上的设计要素一般是虚拟概念，非常抽象；云下的设计要素是实体概念，容易感知和可视。

人、资源、场之间通过“关联关系”建立连接，关系可分为“内部关系”和“外部关系”。

• 内部关系：人与人、资源与资源、场与场的关系。比如，在资源内部存在从物理层→云底座→云产品集群→A-PaaS→I-PaaS→应用的层次进行资源粒度的划分。

• 外部关系：人与资源、人与场、资源与场的关系。比如，在混用云不同业务场景下，用户选择不同云形态的部署方式和产品能力。同时，用户在企业中通过组织管理模型和权限控制，调度和管理云上资源，以满足业务场景的需求，又使得人、资源、场形成更复杂的设计网络。

2.如何管

混合云用户的管理场景非常复杂，无论什么业务平台，用户都会在其上面进行各种“管理”行为，企业内外部用户在同一种产品中的行为也存在差异：

3.如何洞察

行业里对用户行为有关的理论研究，主要有福格模型和唐纳德·诺曼的行为阶段理论：福格（Fogg）理论将人的行为拆解为动机、能力和触发条件三个要素，认为只有当三个要素同时满足时，行为才会发生。可以表示为B=MAT，其中B（Behavior）是行为，M（Motivation）是 动机，A（Ability）是能力，T（Triggers）是触发。福格理论体现的是行为的内在属性，是提升体验的关键切入点。

唐纳德·诺曼（Donald Norman）对“行为”划分为：行为→任务→动作→操作。他认为目标导向的行为是“以任务为中心”。所以在这个结构中，行为由任务构成，任务由动作构成，动作又由操作构成。动作是人们如何适应手中的工具，而使用工具展开的内容就是任务。诺曼的这个理论，可以帮助我们拆解复杂的行为阶段，以更细颗粒度的视角分析体验痛点。

我们以“福格行为模型”和“唐纳德.诺曼对行为的阶段定义”为基础，并结合自身业务特性和管理诉求，推导出：

二.典型的用户行为路径

我们从混合云多个产品平台的管理行为中抽象了两种典型的用户行为路径：

1.目标确定的长链路线性路径

体验痛点：

这种长链路的行为路径往往包含多重任务，任务具有顺序性和连贯性，任务与任务之间可能需要一定时间等待。完成一个任务，可能是下一个新任务的开始，在任务衔接中极易发生行为断点，从而不能顺利推进目标。其实这是一个“触发”的问题，用户没有在接连的操作中获得持续的行为刺激点，就容易因为外部因素而放弃。

混合云有很多产品配置功能，都是这种长链路多步骤的操作体验，多则六七步，每步下有几十到几百个配置项不等。试想如果手动逐个配置，必定会让用户痛苦难言，甚至崩溃。这是”动机”预设不当的问题。

2.利用条件约束，持续将当前状态推向目标状态的选择性路径

体验痛点：

这种路径与顺序路径的最大不同就是，不区分步骤和状态，与前一环节动作无关，与之前的目标无关。整个过程只关心三个方面：当前状态、目标状态和约束条件。在问题发生前，把所有的约束条件定义好，保障不出问题，而不是在问题发生时需要追溯前一环节。如果某一个方案走不通，那么可以采用其他方案重新推进目标，如上图所示。

此链路中用户心智是：尝试多渠道任务并行，条件变化不影响目标的推进。比如：尝试通过改变不同手段查找告警异常的原因，排查定位最终问题。过程中用户也会经历试错失败的挫败感，以及无法分解目标的未知感。

三.如何打造更好的管理体验？

1.一致性体验

A.尊重用户在多平台上的使用惯性，保持产品能力一致

混合云用户基本上都会使用多个云平台，或者多个云厂商的平台。我们希望尽可能尊重这类用户在某些行为上的一致性，例如资源的开通变配、资源的计量计费、资源审批流程等场景，用户对操作具备一致的前置经验，设计保持一致性可以减少用户学习成本，让用户在不同平台使用中体感统一。

例如，国内外主流云厂商控制台在资源创建的功能上，除了支持自定义创建资源，几乎都提供模板创建的能力。无论是“一键购买”、“快速配置”都是把相关的信息聚合在一起，缩短步长，大大提高表单填写效率。所以，我们在构建混合云资源创建的产品体验时，也一定要满足自定义和模板创建这两类用户“已经学会并习以为常”的创建习惯。

2.效率与反效率体验

A.效率体验

提升长链路路径的效率：混合云某运营平台主要是围绕企业/组织如何更好的运营（分配、使用、管理）云资源展开的，“企业”和“产品”是运营平台中最为核心的两个模块。其中“企业”模块包括对组织、资源集、用户、角色、登录策略的管理，体验链路是以长链路线性化任务操作为主。我们可以利用如下设计策略来解决该链路的痛点：

1）管理等待、利用合理的引导和全局通知反馈，缓解等待焦虑。

2）细化用户行为的颗粒度，聚合有关的信息，用模板化的思路解决重复配置的问题。

提升选择性路径的效率：混合云某运维平台主要围绕云资源一体化监控运维来展开。用户最为高频的操作链路是查看告警→根源溯源分析→告警定位→查看告警详情→处理告警，这是一个选择性路径的业务场景。我们为了减少用户在告警根源定位中的试错成本，把成本转移到系统中去，让系统承担更多的行为判断和用户引导。比如，通过算法智能判断故障疑似根因，或通过拓扑展现上下游关系，以便提升故障排查的效率。

B.反效率体验

关于告警处理：在混合云运维平台的告警处理列表中，我们去掉了对告警的“批量处理”操作功能。从功能上看，这会让处理操作不那么高效。但这其实是一种“反效率”的体验。因为处理告警本身就是一个需要“谨慎”的事情，对每条告警用户需要溯源分析后找到根因，然后谨慎选择何种“处理”方式。“批量”会让用户忽视处理本身，而追求盲处理的速度。如果告警过多，则说明运维人员响应不够及时，是需要自我反思的。拿时间换效率，有时是必要的。

对所有云资源的运维管理操作都需要二次确认：在特定场景下，我们需要设置一定的用户行为门槛，为用户安全或产品目标服务。在混合云运维平台中，所有对资源的运维变更操作都需提醒用户二次确认的，设计上往往用模态弹窗承载提示内容，内容中也会透出操作对象的详情，以便再次核实。适度的打断会让操作更聚焦、更谨慎。如果没有确认弹窗，也许效率会提高，但误操作带来的用户损失成本可能更高，甚至是无法估量的。

3.服务化体验

流程编排

在混合云场景中，存在一种“运维工程师”的角色，其职能是处理业务发展过程中出现的频繁变更、隐患排查、软硬件资源管理等等。这些角色是保证业务高效且平稳运行的关键角色。传统运维工程师遇到复杂或者批量任务时，通常需要进行重复性的完成某一个单一任务，由于业务规模量级可能会非常大，运维工程师涉及到的资源种类、数量、任务类型也非常多，如果还是靠人肉去逐个操作，必然会造成大量的重复性劳动，且与业务追求快速响应的目标也是相背离的。

流程编排就是在此痛点下诞生出来的一套通用解决方案，其实这个概念在行业内并不陌生，就是工作流的概念。在一个工作流中，通常有一些“节点”，每个“节点”都可以承载不同内容的工作任务，而不同的“节点”可以进行串联，从而实现用户只要触发这个流程，系统便会自动执行相应的任务，直至任务结束。

在混合云运维业务中，我们尝试将这一整套通用的工作流与运维领域的特点相结合，设计出一套能支持不同业务场景的“编排”方案，我们将整个方案分为3个阶段：

执行前：在流程执行前，我们需要定义整个流程的目标、范围、触发条件，这些参数将会在用户每次执行流程之前需要明确，设计上建议使用步骤条来引导；对于有特定事件的触发条件的流程，可以通过模版分类方法来做区分，即将特定的流程与特定的事件配置规则，以卡片式或者列表型模版作聚合展示。

编排中：流程编排涉及到的操作和传统后台会有点不同，更接近于“画”的概念，因此在编排界面设计上，一定要考虑到用户的使用成本，通过明确入口（如何创建？如何引导用户使用案例模版？）和编排状态（怎么保存，怎么发布，怎么退出），以及流畅的节点链接（流程之间怎么衔接？怎么兼顾自由度和效率？）来营造出高效、沉浸式的编排体验。

执行后：用户在执行后，需要明确整个流程的运行状态，这个状态可能是节点与节点之间的流动关系或者流动状态，也可能是节点内部的运转状态，总之，用户需要在执行后关注这个“流”的实时状态，以确保流程的顺利运行。我们在设计上采用了不同色彩的流动的线条动画来突出运行过程，以非模态抽屉来展示具体的节点信息，此外通过dashboard大盘来展示综合数据，比如流程总数，进行中数量，完成的数量，执行的成功率等。

混合云场景“控”视角下的设计思维与策略

云计算的全面爆发浪潮下，云平台已经不是简单的单个业务场景，而是由多种业务，多种云产品，多种云平台的组合与链接。“混合云”概念应运而生。而作为非技术出身的设计师，似乎很难与此类平台中的技术型用户建立同理心。

在实际混合云的业务场景探索过程中，我们发现了可以通过“监、管、控”三种典型的用户视角切入，通过总结设计场景化的设计模型，来保证混合云平台的用户体验一致性与规范性。

本期，我们重点分享“控”的视角：

一、什么是“控”

控，即控制。在百度中的解释是为了确保组织内各项计划按规定去完成而进行的监督和纠偏的过程。控制的目标就是让事物按计划进行，满足用户的预期与规划，如若出现偏差及时找出原因并采取调整措施。

在信息化、智能化时代下的混合云体验设计中，设计师应该从哪些方面着手，才能帮助用户更好的掌控他们的产品，以此来满足使用体验是本环节探讨的重点。

我们先来对“控”的场景做一个界定。黄帝内经中提到：治未病。未病先防、既病防变，瘥后防复。

• 未病先防：是指在为患病之前采取预防的方法从而避免疾病的发生。
• 既病防变：是指当已经处于疾病状态时，要早期诊断，及早治疗，防止疾病转变殃及其他未病脏腑或危及生命。

• 瘥（chài）后防复：是指疾病的“愈后”阶段，仍处于不稳定状态，需要巩固治疗，防止疾病复发。

荀子也曾说过：防为上、救次之、戒为下。一曰防；二曰救；三曰戒。先其未然谓之防，发而止之谓之救，行而责之谓之戒。古代思想中未雨绸缪、见微知著、防微杜渐的预防思想体现了古人对于个体状态或行为的掌控策略。这种思考同样适用于云计算时代下用户对个体资源的掌控需求，那就是“先预防、后纠错”。确实，云上服务，我们首要确保用户数据的安全性、系统的稳定性，需要通过更加信息化、智能化的方式，减少甚至预防故障的发生，所以在纠错、纠偏之前，需要通过设计及技术手段，预防错误的发生，以各种智能化预警、容灾备份等手段在故障真正到来之前进行谋划，最大程度降低故障的发生。

根据“先预防、后纠错”的思想，将“控”（为了确保按计划完成任务的监督和纠偏行为）的行为场景分为三个阶段，帮助设计师更有针对性的进行策略输出。

预防错误发生阶段，用户追求的是系统的稳定，希望异常不要发生，这也是混合云控制台体验的常态化心智诉求。如果异常出现后，用户更关注的是安全，一方面是异常有无对其他服务或数据造成影响，一方面是处理异常的过程中是否符合规范、规定，不会对其他数据或资源产生误操作。在这两个阶段下，用户的心智存在一些差异，心智的差异在不同阶段中，用户的目的也略有差异。

因此，在混合云设计体系中，我们将“控”更聚焦在：从预防错误，处理异常到恢复系统可用状态的过程。在异常、偏差出现之前让用户提早感知到风险，尽可能的了解风险的发展趋势与后果，从而主动规避或遏制。过程中，也需要设计主动透传产品的稳定、可控，建立用户信任。异常出现后则及时处理干预，控制影响面扩大，确保过程中的所有进程与操作都符合用户的预期与安全规范，直至对象回到正常状态。

在预防错误，处理异常到恢复系统可用状态的过程中，“控”的要素主要有哪些？通过对混合云产品设计对象的分析，总结为四个关键要素：态势、感知、时效、链路。

二、“控”场景下的设计策略与分析模型

在“控“的各个阶段下，用户的行为与感知都围绕着设计的“引导思维“，帮助用户掌控系统状态与操作节奏。”引导思维“会贯穿在系统控制的各个环节，比如操作后的反馈也会起到引导的作用，操作完成不是行为的结束，而是下一个操作的开始。因此，我们将引导在混合云体系中使用的场景进行梳理举例，并按引导对用户的干扰程度进行层级划分，可以看出，不同的操作触点下，设计师会选择与之对应的引导策略来帮助用户更好的掌控系统。

为了方便设计师在引导体系下对信息状态和组件的选择，我们结合信息本身的属性，将引导体系下的信息类型进一步明确，根据系统、用户主动性的大小，将信息分为：“通知”、“提示”和“反馈”：

1、系统主动推送。用户属于被动接受的一方，不受用户的操作限制，此时信息类型为“通知”。

2、用户操作前或操作中系统给予的信息，用来引导下一步行为。用户和系统处于即将交互或交互过程中，为了让用户更加正确的操作、更好的感知操作进度和状态等进行的说明，此时信息类型为“提示”。

3、用户主动操作后的结果。系统是根据用户的操作被动显示对应信息，此时信息的类型为“反馈”。

基于“控”的场景、要素以及不同阶段下用户的心智，引导策略的倾向，我们总结出以下设计分析模型，帮助参与这类复杂控制台产品的设计师，快速找到方法，尽可能快速梳理思路，设计出满足产品功能、用户需求且思考全面的运维产品。在“控”的分析模型中，设计师除了要掌握对信息的运用，还需要关注用户在过程中的认知与感受，让用户从「被动」的接收系统状态到「主动」选择操作与结果，给予用户更大的掌控权和灵活度，帮助用户主动规避风险、主动选择解决方案、主动控制系统。

三、如何有效预防错误，规避异常

在异常发生之前的预防阶段，用户的心智是追求稳定，避免异常的发生。在这个触点下，用户一方面关注系统及资源的实时状态和发展趋势，如果有可能发生风险就要及时干预；另一方面则关注所有可能造成异常的信息如何快速让用户感知，从而做到心中有数，早做准备。下面就结合预防错误阶段中的“态势”和“感知“进行详细设计介绍。

1、风险前置，消除潜在隐患

云上操作需格外谨慎，生产环节的任何故障都会被放大，威胁到用户的数据安全。因此，必要的设计引导可在用户操作之前将风险前置，及时提醒用户有可能的风险。在预防错误的阶段，我们重点关注信息“通知”和“提示”。根提示对象的重要性和用户操作频次，设计将风险引导分为三级：不打扰用户的消息通知->轻量级干预的风险提示->重要级强制的风险提示。

不打扰用户的消息通知。如用户登录系统后，以通知形式提醒近期的安全公告，例如常见的封网公告。这种消息提示的量级最轻，让用户感知到即可，用户可以关闭不再显示，也可以不进行处理，不会对用户当前的行为产生影响，用在任意需要告知用户重要信息的页面中。

轻量级干预的风险提示。如用户进行高风险的运维变更操作，采用弹窗「二次确认」的形式让用户确认风险，点击“确认”操作后，才可继续行为。这种提示会对用户当前的行为进行打断，出现也较高频，重量级一般，常用于资源的增、删、改操作。

重要级强制的风险提示。这种风险提示将结果和影响前置，用户必须在主动了解本次操作的风险及可能的结果后，才能进行后续操作。如下图所示，不勾选风险确认，“提交”按钮则无法点击。这种风险强制确认的约束力最强，它是在用户达到目的的必经之路上进行的有效干预，最大化降低误操作的可能。

2、风险预警，帮助用户主动规避

状态感知。针对状态的掌控，通过警示色彩的运用让用户快速辨识，如健康度的色彩和趋势图的结合，让用户明确低于50%将触发异常。右图端口水位，采用指标结合折线图进行可视化呈现，异常水位超过基线，明确告知用户超出正常多少。在表达状态方面，设计不仅仅是一个数值、一个色块，而是体现一段趋势的有效信息的聚合，用户可更有体感的掌握当前资源的状态及历史变化，方便用户及早判断是否要人为干预。正常的指标则不需要过多元素辅助，减少信息触达的噪声，让用户快速进入紧急故障的处理环节。

趋势预测。同样以水位预警进行说明，目前越来越多的系统朝着自动化、智能化的方向发展，设计结合系统的智能化可以带给用户更具可靠稳定的体验。基于用户购买并使用中的产品，通过智能水位分析，让用户掌握产品当前使用的容量以及剩余的可用容量，如下图用户可以很直观的掌握当前产品的实时使用率，以及未来一段时间容量是否满足需求。根据预测增长曲线提早进行策略干预，如果预测水位将超过基线，则提示用户存在风险，并引导用户选择对应的解决方案，如通过扩容、设施弹性策略或回收部分弃用资源来应对即将发生的异常，将风险可能性降到最低。

3、稳定感知，建立可信赖的安全策略

未知带来恐惧，当人对事情缺少了解，就会产生慌乱、犹疑。作为体验设计师，我们也一直致力于通过设计加强用户对产品的掌控，使操作符合用户的心智模型。通过设计将可能遇到的风险提前告知；将界面信息传达的更为精准，将用户的隐私进行有效保护，这样可以在很大程度上提升用户操作的稳定、安全的感受。

管理等待。等待体验是用户在云产品中一定会经历的，比如数据表查询、监控视图刷新、任务提交后的结果反馈等。等待的过程用户对系统的工作状态是无感知的，因此需要设计引导，缓解用户的等待焦虑。对此，在混合云体验设计中，我们对不同等待时间下用户的感知程度和设计策略也进行了分级设计。针对「弱感知的等待」，通过Loading快速完成加载；「强感知的等待」，则一定需要设计的引导，告知用户实时进度、相关原因及处理办法，让用户明确系统仍处于稳定可用的状态；对于超长等待，可通过异步处理的手段，让用户可以不必限制在当前页面，确保不让用户因等待而产生“不专业”“不稳定”“不可控”的心理感受。

细化空状态。针对空状态一定要运用引导策略告知用户空状态的具体原因，提供帮助文案、操作建议等解决方案，表明在下一个界面可以做什么，引导用户进行操作。空状态的主要场景有：

• 初始化不存在对象或数据
• 用户无权查看页面

• 需要用户先操作再显示内容时
• 用户删除数据后

• 没有返回结果的搜索或过滤器
• 数据无法加载到页面或特定部分/组件中

针对不同的空状态，梳理场景，建立相同场景下一致的交互体验与呈现，传递稳定的界面元素。当列表或文本信息为空时，可用“-”展示。图表中数据为空时要考虑两种场景，数据无法获取用“–”表示，无数据用“0”表示，“–”为占位符，而“0“可以点击

当组件中信息为空时，也有行为上的区分，一种是用户主动清空了数据，如待办事项；一种是初始化状态下无数据，如用户暂无实例；以及搜索后组件中无匹配内容，如列表数据。这种情况设计通常采用“文字加图形“的形式进行提示，对于初始化场景可引导用户下一步的操作。最后一种则是空状态页面，常见的有404、403、无权限等，采用“缺省场景插图、原因说明、引导操作”共同构成。空状态的设计策略可以有效降低未知的恐惧，增加确定感和可控感，满足用户渴望稳定、安全的心理需求。

三、如何规范处理异常，恢复可用

规范，包括了对异常的响应时间、处理方式、处理过程等要符合公司的基本要求。在线上环境中，出现故障需要用户快速处理，避免影响面扩大，如重要运维场景下3分钟不响应故障则会自动升级。操作过程中系统加载或因处理故障而带来的用户等待时间，都会影响操作效率。因此在处理异常阶段，排查问题的“响应时间”和“操作链路”直接影响用户体验，下面将重点分析处理过程中设计对“时效”“空间”的节奏把控。

1、划分信息主次，提升响应时效

信息分层。在对故障的响应方面，设计可以通过暴露关键信息，建立信息主次规则，帮助用户捕捉关键信息缩减时间。从信息本身出发，主动帮助用户进行主次区分，快速获取关键部分。信息可以按：强调、正文、辅助、次要的优先级进行分层，运用格式塔相关设计原理，通过大小、位置间距、色彩对比等方式进行主次轻重区分，帮助用户聚焦信息关注点。通过设计帮助用户提取出关键信息、区分状态主次。如常见的告警级别，从紧急->严重->提示->一般，根据告警的严重程度进行信息表现的递进式设计，突出强调的同时，弱化次要信息对用户的干扰。此外，建立状态的一致性，无论是浅色页面还是暗色页面，故障等级的色彩规范保持统一，可以很好的缩减用户辨识与学习的时间，提升处理效率。

高效触达。除了控制台PC端上的呈现，在移动端可以更好的发挥设计提示引导的优势，将异常的通知和操作有机串联。如用户代办任务的处理，通过标签引导，标记用户响应的时间；针对那些需要用户立即执行的任务，增加独立的操作入口，一键快速处理。此外还可以借助移动端的短信、电话第一时间通知用户故障，提升响应时效。

2、链路清晰透明，给予足够的掌控感

随着云产品向智能化、无人化方向发展，越来越多的操作由系统自动完成，通过设定的逻辑程序实现自运维、自修复，这也意味着有些信息对用户是不透明的，很难感知，甚至有些操作都不需要用户手动干预，系统可以根据提前设定好的程序自动完成。因此在复杂任务、复杂链路下，需要设计进行可视化的呈现，帮助用户掌控系统安全。

链路掌控。设计师通过界面将“黑盒化”的运行逻辑进行“白盒化”转译，帮助用户排查问题。有些企业在发布环节下会有严格的安全规约，如下图所示，用户需要先在测试环境发布，观察8个小时没有问题后可以发布到预发环境，预发环境下观察4小时没有异常才可以正式上到海外、国内生产环境。在这样一个长链路的任务中，设计对步骤组件做进一步延展，将“间隔时间“融入步骤组件中，且不会增加原本的步数，信息传递更为准确。每个发布步骤中用户都可以设置等待时间，支持用户暂停或手动开始，便于异常情况的响应和处理，降低风险。在链路呈现上，用户可直观了解每两批之间的间隔时长以及当前进行中的时间剩余多少，如果存在不按发布规则进行的操作，如“跳过停留时间”则以「红色」提醒进行警告。

操作掌控。在任务过程的节点展现上，设计将当前状态下用户可进行的行动点明确告知，根据状态的不同，匹配对应的操作，降低误操作的同时进一步提升过程中的掌控感。如上图集群列表中，变更失败时支持回滚、终止，变更中支持暂停或撤销等。通过设计对流程和信息的再加工，有效告知用户当前任务的运行状况，辅助用户充分掌控任务各环节的状态，并主动提供让用户离开「非预期」状态的途径。

3、主动式操作引导，使操作合规结果顺意

主动式帮助。为了保障用户操作的合规性，设计上会将规范操作以引导帮助的形式，贯穿在用户的行为链路中。一方面通过设计，主动帮助用户按正确的流程进行，一方面提供随手可得的帮助引导，让用户按规范完成操作。

混合云业务中，很多用户是即使用公有云产品又有自己的私有云环境，在私有云场景下，研发运营人员需要到客户现场部署服务与整套系统，此时，初始的部署过程是极其重要且复杂的。如下页面，从部署准备到IDC检查最后到云平台部署，每个部署环节下又包含很多步骤，为了让用户感知到部署的流程，设计了一个全局进度和步骤进度引导，建立全局与局部的关系。

如何在一个屏幕下让用户按照规范的流程部署，并且及时了解大量的说明和注意事项？设计上采用了分栏结构，让帮助指南模块常驻，操作过程中遇到疑问可随时快速查阅，建立用户与系统间的流畅节奏。

结果反馈。在云计算业务中，数据计算分为实时计算和离线计算。实时是对当前资源的即时操作，如运维下的盯屏操作，可实时更新数据并根据用户操作快速返回结果，数据是实时到达的；离线则是服务器读入所有的操作数据，然后进行一次性处理，这就导致很多结果是异步的。

状态不同步会给用户在处理异常的过程中造成极大困扰，清晰的反馈可以有效缓解情绪。一般的实时操作后，以轻量的全局提示反馈用户操作成功，在异步场景下，则要明确告知用户需要等待一段时间，避免用户操作后无法立即查询到结果，如新建集群，创建成功后，后台系统需要将配置信息按步骤下发，并且在系统下一次检查资源时才可以发现新增了集群。这种情况，设计不仅可以提示用户需要等待，还可以将概览信息进行展示，让用户核对同时确保自己的操作被系统所接收，此外，一些步骤操作的结果页除了结果反馈，设计上也会增加相关操作的引导，不仅可以向用户主动介绍其他产品功能，也可以主动引导用户选择下一步行为。

四、总结

以上是关于“控”这个场景下的常用设计策略，可以有效帮助用户预防错误，在异常发生之前引导用户规避，建立稳定可靠的信任感；在异常处理的过程中，则通过信息主次和一致性，让用户快速获取关键信息并及时处理。此外，设计对链路流程的规划、引导及呈现，可以主动帮助用户掌控过程与结果。

原文：https://mp.weixin.qq.com/s/l-wlTanidhkjwCma1bw0ag