My Secret Rainbow

JCD 驱动 – 复杂系统设计应对之道

摘要

面对企业级产品，由于系统复杂度和业务领域的专业壁垒，用户、产品、业务、技术的理解和分析难度都远远高于C 端。特别是进入业务深水区，技术术语层出不穷，角色链路错综交织，场景越来越复杂，在理解和分析业务上设计师需要耗费的精力越来越多，设计师如何高效且深入的分析业务，直接影响到设计解决问题的深入度。基于蚂蚁金服CTO 线的业务土壤，我们不断尝试打磨，探索出以JCD 为核心的企业级产品设计思维，助力设计师在深耕业务上有章可循，有方法可用。

复杂系统的特点

做企业级产品 3 年多，刚从 C 端业务转过来时，最大感受是对业务理解起来很艰难。随着经验的增加，对 0 到 1 产品驾驭起来轻车熟路，可到业务深水区，还是感觉痛苦。技术术语层出不穷，用户角色多，一个用户身兼数个角色，系统之间的关联关系也很复杂，随着业务的深入设计师会感觉对产品逐渐失去掌控力。一个简单的芝麻信用分，需要 20-30 个中后台产品和各种角色一起协同支撑。然而复杂是守恒的，系统复杂性的总量是一个衡量，当前台的呈现更简单时，隐藏在幕后的复杂性就增加了。

我们面临系统的复杂性表现在三个方面：

• 多角色，重协同。
• 链路长、错综交杂。
• 技术术语多，业务难理解。

但企业级产品会有一个主线，是从「事情」的角度出发，关注一件又一件事情被完成。企业场景下我们再把事情描述的具体一些，就是一个又一个的 Job 。设计师要做的就是通过设计，包括参与的角色、使用的工具以及协作方式等，让 Job 被高效完成。

JCD 设计思维应对复杂系统

我们先对比一下，从「用户」视角和从「Job」视角出发，关注的维度有哪些差异呢？从用户视角出发我们需要关注用户的个人痛点、情绪、兴趣、人种志（年龄、性别、收入）等信息，会更关注人，核心是为了满足用户的需求。在Job 视角下，需要关注 Job 的目的、参与角色、协作方式、工具等信息，而且 Job 对角色是有要求的，比如航空公司飞行员，按岗位要求，他需要不断提升自己业务能力，每年要去复训两次，学习新的技能和知识来满足岗位对飞行员这个角色的要求。

基于我们的业务土壤，以及出发视角，我们探索出一套适合企业级产品的设计思维，JCD（Job – Centered Design ）以 Job 为中心，设计完成 Job 所需要的一切，包括角色、工具、协作关系等。以 Job 被高效完成为决策依据的设计思维。它是一套适用于企业级产品设计的发现问题、解决问题的方法论。

在 JCD 设计思维下，将设计流程分为四个阶段，发现、构思、呈现、度量。每个阶段下有不同的方法、产出、资产。Ant Design 在「呈现」阶段帮设计师大大提升了效能，设计师才有更多的精力投入到「发现」阶段去更深入去理解业务和角色。接下来重点分享一下在发现阶段的两个方法，角色分析和业务分析。

JCD 方法 – 角色分析

常用的 C 端的用户画像，如下图，会关注用户人口统计学的信息，如名字、性别、年龄、所在地、家庭情况、用户的习惯、爱好等信息，这些信息在复杂的企业级产品中是不需要去关注的。

企业级产品角色画像

在JCD 的视角下，我们企业级产品的角色画像应该关注的三个维度：角色概览、工作能力、工作内容。而工作内容是最核心需要关注的信息，包括了工作的描述、工作的痛点、需求和使用的工具。

一个角色往往需要完成多个Job，描述一个Job 包含：

• 四要素：情景、角色、活动、目标。
• 一个句式：在什么情景下，角色需要完成什么样的活动，来达成一个目的。

举个例子，在飞行前 1.5 小时（情景），角色（飞行员）需要去查看飞机情况（活动A）、气象情况（活动B），来判断能否起飞（目标）。

为了给设计提供具体的依据，我们需要进一步纵向解构Job，来构建 1 个完整 Job 场景，设计师可以阶梯式对一个Job 进行拆分，Job 下面有多个Activity，Activity 下面有多个 Task 组成，Task 下面有不同的 Action，到这种颗粒度可影响到设计界面中的具体元素。

看一个具体案例，如何拆解一个 Job，首先用我们的上面的四要素和句式描述。

Job：飞行前 1.5 小时，飞行员需要查看飞机情况、查看气象情况，来判断能否起飞。

在飞行员这个角色的 Job 里包含了两个 Activity ：1. 查看飞机情况；2. 查看气象情况。

查看气象情况这个 Activity 下包含了三个 Task：1.查看起飞地天气；2.查看降落地天气；3.查看备降地天气。

每个 Task 下面会有不同的 Action。除了 Job 的纵向拆解，我们还需要关注每个 Job 场景下的需求、痛点、费力度、成就感。

以 Job 场景为核心，串连角色协作关系

做好一件复杂的事情，往往需要多个角色在多个工作场景中协同配合。我们会以Job 场景为核心，梳理角色之间的协作关系，建立全局视角。比如，在飞机起飞前，机组飞行员查看飞机和飞行信息、查看起降地天气等；同时乘务组空姐们为此次飞行做相应准备工作。准备完毕，机长会通知机组和乘务组开始登机。上飞机后机组需要检查驾驶舱情况，乘务组检查客舱情况，检查完毕，会一起协同机场地勤人员安排乘客登机。完成登机后，飞行员需要联系机场管制申请起飞…….. 设计师可以通过Job 场景去串联角色之间的协作关系，如下图。

以上是「角色分析」的方法，是从 Job 出发洞察角色的工作需求以及协作模式，帮助设计师构建角色协同的全局观。

JCD 方法- 业务分析

业务分析的方法是借鉴面向实体的思路帮助设计师去深入分析复杂业务。企业级产品中会有各种技术术语、复杂的数据流转、业务逻辑等，我们需要一个系统的方法来分析和理解业务，为设计提供准确有深度的信息输入。我们的用户大部分是软件工程师，这个思路可以让设计师在理解和认知上对齐用户的心理模型。我们业务分析的有三个维度：

• 产品定义
• 实体建模
• 业务逻辑

通过以上三个维度，从纵向和横向去深入和全面的理解业务。

首先，产品定义。

通过沟通交流、桌面研究的方法，去了解产品和用户相关信息，熟悉相关概念和技术背景、沉淀信息资料，来收集产品的信息，具体的产出有名词库、产品画布、产品的关系图、业务结构图、产品形态图等，这里不展开详述。

其次，实体建模。

实体建模是本次分享的重点，实体建模按照面向实体的思想分析业务，围绕实体进行问题和内容抽象和分析，聚焦于产品内实体和实体间的关系，以及实体的生命周期的分析。

我们先看什么是实体，参考领域建模（此处感谢幻星给实体的定义）给实体一个定义：

实体是产品中客观存在，具有唯一标识的并可以相互区分的业务载体，通常包含属性和行为。

企业级产品系统的实体，很多情况下都是熟悉的字母，陌生的单词，在设计之前设计师如何去准确、系统的去分析实体。

举个例子，现实世界中，「机票」是一个实体，在产品里，可以把「机票订单」看成一个实体。围绕着机票订单，我们梳理出它的基本属性信息，以及它具有的所有状态和对应操作，设计师可以进一步把这些状态和操作梳理出一个「机票订单」这个实体从产生到消失整个生命周期经历的过程。这些分析可以作为后续任务流程和设计细节的信息输入。

一个实体不能构成一个产品，一个系统会有很多实体存在，我们需要进一步去梳理「机票订单」与系统中其他实体的联系。在下图的案例中，机票订单与机票是聚合  n：1 关系, 一张机票订单会包含多张机票，机票订单与收支明细是关联 1：n 的关系，一张机票订单会关联到多个收支明细，比如会有支付成功、退款等明细。

最后，业务逻辑。

以上是实体建模的过程，产品定义和实体建模都是对业务内容层进行理解和梳理。但是我们的业务除了内容外，还有很多复杂的业务规则、业务流程，我们也需要进行梳理和分析，这样设计师才能对业务有全面的理解。

所以我们需要把结合实体、业务规则、业务流程，进一步梳理业务逻辑。最终会得到一张业务逻辑图，不仅能够帮助设计师洞察到业务的本质，也能帮设计理解业务的全貌。

第二个方法业务分析，是通过面向对象分析思路去深入的理解业务，为设计提供更精准，更有逻辑的依据。

总结

回顾以上三部分内容，JCD 是什么？Job – Centered Design 是以 Job 为中心的设计思维。JCD 的定义：以 Job 为中心，设计完成 Job 所需要的一切，包括角色、工具、协作关系等。以 Job 被高效完成为决策依据的设计思维。它包含了原则、流程、方法&工具、产出&资产，上面重点分享了其中两个方法「角色分析」和「业务分析」。

最后借用《设计心理学 2 》中的一句话分享一下我的感受，无论是工作还是生活，我们往往需要面对复杂的情况，我们要学会与复杂共处。复杂不仅是不可避免的，还是设计新的出发点和契机，基于企业级业务特性我们开始探索以 Job 为核心的设计思维 JCD。希望对大家有所启发，期待更多的小伙伴跟我们交流。

原文：https://www.yuque.com/seeconf/2020/ybcmvk

---

AUI四种模式的分类是为了更好的说明虚拟信息的位置及运动信息，正如物理学里认为，研究和描述物体运动，只有在选定参考系后才能进行一样，AR设计中的虚拟信息由于虚实结合的特性，也应该是整个物理环境的一部分。作为新的物体形式，定义基于不同参照物的类型，也是为了在设计和开发中更好的说明和研究AR界面设计。

原文：https://mp.weixin.qq.com/s/FmrDuvjqwZizeoR_M58oHQ