被忽略的设计原则（一）

不知道有多少人在阅读一套设计规范的时候会去看设计原则的部分，并且花时间深入思考它背后的含义？至少以前的我，接触一个新的规范时候都是直接从视觉交互的部分开始，觉得这种假大空的文字是纯粹的装饰品，就像装帧上必不可少的高大上扉页而已。作为设计规范的真实消费者，没什么必要去研究设计原则。后来，工作职能的转变使我看待设计规范的角度发生了变化：我一直忽略的设计原则，其实是设计规范硬核的内在，它是设计过程中指导的思路与方法。而页面、控件等组件的交互行为是设计的基本的元素。

我关注的最多的设计规范是SAP的Fiori，Salesforce的Lightning，蚂蚁金服的Ant Design。Fiori发布于2013年，后两者发布于2015年。我用了很长的时间观察和学习这些设计规范的变迁，这三者有各自的风格和特性并且都在不断的进化，组件日益成熟。大家肯定会问：这种情况下，不同的设计规范到底有哪些差异？回答问题之前，我们先来做个小实验吧。

体验的不同

实验内容

控制变量法：用不同的设计规范来转换相同的页面，并比较他们之间的差异。基于同一张SAP Business One（以下简称B1）的Sales Order，进行“翻译”后所得结论如下图：

SAP Business One - Sales Order

B1转化为Fiori

B1转化为Salesforce Lightning

B1转化为Ant Design

根据不同产品的设计规范转换的界面，他们的体验差异是什么呢？（个人精力有限，不能去还原整个系统。这里以小见大，希望能够基于这个实验来展开思考）

发现问题

单纯运用设计规范的组件转化页面，当前页面最主要的作用是提供用户信息，那么从用户信息获取效率来说（暂不考虑老用户的惯性偏好），3个页面的效果高下立判：Ant Design转化出来的界面可读性是最好的，控件的作用也更清晰。

设计的过程如果只考虑交互控件的使用，页面的信息呈现，必然会造成设计中心的偏移，忽略了真实的用户和需求。这就是为什么Fiori和Lightning转化出来的界面体验平淡。企业级产品的体验是一个整体，单纯组件的堆砌是无法构建出一个好的用户体验。所以我们需要一个有指导意义的设计原则给我们提供产品设计上的方法、思路、理念。

那么我们逐个看一下不同设计规范的设计原则，理解这些设计原则的在产品设计上的指导意义。

Fiori的设计原则

1. ROLE-BASED

第一条，也是最重要的一条，就是要基于角色。单单没有考虑这一条原则，就势必让实验中使用Fiori的转化B1的结果产生巨大的偏差。在传统的企业级应用中，信息冗余的现象很严重，一张单据总是会混杂着多个路径或use case，并且对用户缺乏业务流程上的引导，这会造成用户上手及其困难。Role-Based就是为了解决这个问题的思路。

要基于角色，首先你必须了解用户，提炼出他真正需要的的内容，去掉冗余的部分。通过基于角色和场景，围绕核心的use case去构建你的设计。回到B1的Sales Order上来，当你使用Fiori去重新设计的时候，你需要思考的不是哪个控件合适，而是我的目标用户是谁？这个用户的角色是什么？他的日常任务有哪些，他在什么场景下面需要查看订单？他需要看到哪些信息？通常他基于这张订单需要做哪些动作去推进业务？理解这些问题，才是设计的出发点。

Fiori的最佳案例S4HANA中，系统的单元不是模块而是应用，把基于用户角色和场景构建起来的应用集成到系统中去。而传统的ERP，系统是基于功能的，是模块化的，并没有非常清晰的角色的概念。如B1，角色只是一个权限的容器，系统中并没有场景的概念。这也是为什么一张订单页上面布满了所有的内容，毫无业务上下文，毫无引导性可言。当你想要在整个业务层面去重新思考的时候，这需要把B1这一张订单本身关联的所有业务场景全部抽取出来，再基于角色重新梳理一遍，这样产出的设计才更容易让用户理解，体验也会更好。

基于角色的设计的转变

2. ADAPTIVE

这一条原则光看标题的话是完全get不到点，真正的原则其实是Mobile First，然而这个理念本身也是非常的迷惑人。如果不仔细看内容还会以为无论做什么功能都要适配到手机上。其实不是这个意思。这里实际上指的是从移动端的简单场景出发，去构建设计的一种思维方式。

“Mobile first” means reimagining your approach to complexity by starting with the design of a simple mobile app. Starting with the smallest and most limited device and later enhancing the app for larger, more powerful devices has many benefits. It implies having to deal with some level of restriction that will force you to find smart ways to reduce, aggregate, group, and default information. This approach allows you to really focus on what’s important and can lead to amazing innovation in design.

在这个移动互联网的年代，绝大部门客户都期望应用是可以运行在各种终端上，所以产品如果能够尽做到这种高度的适配是最好的。（当然这个原则和产品策略有很大关系，如果确实不考虑移动端的场景，那么这一条可以直接忽略）Mobile First的本质是从移动端最核心的业务场景出发，而不是先考虑桌面端，然后再把一模一样的功能适配到移动端。当你重新审视一个场景的时候，你应该先考虑一下在移动端应该是如何工作的，什么是最重要的，然后再考虑你需要增加哪些功能能够让它可以运行在桌面端。适配原则不是单纯的多平台自适应，而是你要刻意的去设计。

当一个产品从0到1的时候，我们会不自觉的往上堆东西，然后再考虑移动端要砍掉哪些，接下来经常会因为移动端的诸多限制导致会去做很多妥协，最终导致了连基本的体验都保证不了。这条原则让我们从最基本也是最重要的东西开始思考，移动端硬件特性也在一开始就被考虑进来，这样可以保证核心功能在移动端会有比较好的体验。接下来再进一步的去添加更强大的功能，去适应桌面端。这样，你经历的是一个不断增强的思考过程，而不是忍痛割爱，不断妥协的过程。

3. COHERENT

举个大家耳熟能详的例子，微软的Office 365的网页版，在Office套件的不同工具中来回切换，用户的体验是非常连贯的，无缝式的。在不同的工具之间，用户不用登录多次。不同工具的交互行为和视觉感受极其统一，信息结构和业务逻辑的处理也是非常相似，在整个生态圈中用户能够非常清楚的感受到他使用的产品是一个整体，并不会有严重的割裂感。在这个基础之上，数据层面的连贯可以把整个生态系统串联起来，连贯性被提升到一个更高的维度。比如Outlook上的Calendar和Skype，Teams数据都是贯通的。再往深层说，在任何一个工具内，你都体会到微软对于Office 365产品的一致的理念和方向。

你可在这里创作、沟通、协作并完成重要工作。

• 这正是你所需的工具
• 可在所有设备上使用
• 在云中完成你的工作
• 我们还将随时为你提供支持

这就是Coherent做的非常好的典范。

Office 365

关于Coherent的思考，我觉得完全可以按照用户体验5要素来进行梳理。这里我大概总结了一下需要考虑的内容，从上往下也是一个从具体到抽象的过程，难度越来越高，内容上也从狭义的设计上升到更广义的范畴。

• 表现层：主要都是视觉上的元素。字体，间距，图标，配色，主题，动效，视觉风格，术语的定义等。
• 框架层：是框架和流程上的元素。基础控件，页面布局和框架，动作的位置，对象的状态，保存逻辑，校验逻辑，导航逻辑，增删改查逻辑，加载逻辑，系统通知，数据显示格式等。
• 结构层：系统的信息结构。对于一个功能来说，层级结构是什么样的，如何把最小单位的对象通过业务上的关联封装成一个整体。对于整个系统来说，系统的构建是基于角色还是基于功能，通过什么样的形式去组织内容然后再呈现给用户。
• 范围层：这一层连贯性主要体现在需求的转化，业务逻辑的定义上。对于同一类型的业务抽象出来的模型，应该遵循一致的逻辑来进行转化，比如通过单据状态的变更驱动业务的流程是ERP软件的核心原理，系统中每个单据模块都是基于这个原理流转的。不同的业务对象的耦合度，基于流程上下文的适配度也是连贯性的一种体现，B1订单中Price List和Customer的耦合，当订单选择了Customer之后，关联在这个对象上的业务属性Price List被统一的代入到这张单据中。将这种一致的原理，应用在系统中，则是这一层一致性的核心。除此之外，数据的贯通也体现在这一层面，不同工具之间数据的共享，single-sign-on之类的，在平台级的产品中尤为重要。
• 战略层：产品的商业价值，理念，方向，定位和品牌的一致性体现在这一层面。这一层对设计师的要求非常高了，只有对产品和市场有着深度洞察力的设计师，才有足够的能力把这些理念体现在产品上。对于这一层的一致性，并不是只有平台级的产品才有必要，才有可能做到这样高度的连贯和一致性。除了Office 365，还有一个小而美的产品QuickBooks在这一层面做的非常的连贯一致。这个产品无论是在产品的定位，业务流程的设计，还是信息结构，甚至小到一个个控件，都是一致的目的：快。整个系统是名副其实的Quick Book（快速记账）

4. SIMPLE

简洁，其实是对设计师最大的挑战。当你面对一个系统，去思考这么一个问题：我拿掉多少东西可以让这个界面不再可用了呢？就像毕加索的《牛》一样，去探索极简的边界。仅保留仅保留公牛之为公牛的必要线条，缺少了任何一根线条，都不能再算做是一头公牛。

毕加索《牛》

对于系统来说，首先你需要明白系统中每个元素的本质，比如服务的业务模型是什么样的，流程是由什么驱动的，哪些元素是相互关联的，字段在业务上是什么含义，在数据库中是什么形式被存储的。你需要把系统里面的这些基本元素全部抽象出来，在认知层面整理出一个网状的结构。在这个基础之上，你才能知道哪些元素对于一个具体的任务来说是必须的。

让用户专注的完成一个任务，意味着移除所有的干扰，只剩下完成任务的最根本的条件。当你去经历这样一个思考的过程，你才能从本质上抓住设计的要素。围绕一个固定的用户，尝试一下把页面上的功能和元素一个个的拿掉，看看拿到什么样的程度，他就无法完成任务了，你就知道什么才是构成一个系统的“必要线条”。

5. DELIGHTFUL

愉悦，作为最后一条。什么是令人愉悦的设计，to C的设计师可能非常的清楚。前些年有个火的词，就是找到用户的爽点，用户用的爽就是一种愉悦。对于企业级应用来说，令人愉悦或许并没有to C的产品那么的难，毕竟这个领域还在一个非常初级的阶段，光是满足业务上的需求就可以让用户赞不绝口了。当然，边际效应也是会递减的，用户爽多了，也是会趋于平淡。在这个基础之上，再把那些情感化的微交互和让人感到幸福的视觉设计带给用户，这是坠吼的（其实这一点Ant Design做的特别出色，后面会做分析）。

Fiori 设计原则的总结

5个词汇看起来非常简单，但实际上背后有着非常深层的思想方法。这5个原则优先级依次由高到低：Role Based提供了一个全新的视角去构建系统，Adaptive帮助设计师从最根本最核心的功能点出发，Coherent完全可以提炼出一个设计师从入门到飞升的发展轨迹，Simple则是对于设计师理业务能力的灵魂拷问，Delightful是让设计师不忘初心。这些原则对设计师非常具有启发性，：当在做设计的时候，只有从这些原则出发，最终的产出才是有着Fiori基因的产品，而不是像一开始的实验一样，拼凑出一个看起来像Fiori的界面。这样的套着Fiori皮的产品终将在使用一段时间之后产生“排异反应”。