综述
本文介绍基于Fiori的设计规范使用的一些经验与心得（什么是Fiori）。文章以一个需求为例，介绍模块设计师从拿到需求，转换需求、进行任务分类、绘制故事版以及用户交互图谱，最终将需求转换为页面的过程。
背景
转换思维模式
许多企业软件以模块对软件进行划分，虽然有用户权限的设置，但是大多数用户看到的，往往是一个个模块入口堆积的页面，信息是按照模块单据一层层逐级展示给用户的。与传统设计理念不同的是，Fiori提出基于用户设计的理念。Fiori的设计原则第一条便是:Role-Based（如下图）。它要求设计要以业务、需求以及用户实际工作为依据，为用户在特定场景，特定时间下提供合适的信息，帮助用户更好的完成其工作。（更多关于Fiori设计原则解读：被忽略的设计原则）。
Fiori 设计原则
Role__ Based: “SAP Fiori is designed for your business, your needs, and how you work. It draws from our broad insights on the multifaceted roles of today’s workforce. SAP Fiori provides the right information at the right time and reflects the way you actually work.”
这对设计师也是新的挑战。因为以往2B的设计师拿到的需求通常是以增加功能为主，要转换成以基于用户的设计方式时，设计师的思维模式首先要进行转换：不仅要懂得该需求业务层面的含义，还要理解用户诉求背后的原因，了解用户使用产品的情境及如何使用产品，他们对产品的预期，技术在特定情境与控件上的相关局限性，以及各个设计原则适用的情况，从而制定合理的交互流程，选择合理的页面与交互控件，输出最终的设计文档。
传统以单据为中心的设计方式转换为基于用户角色的设计思维
精简规范轻装上阵
在SAP，Fiori是针对公司全部的产品线给出的设计规范，需要考虑SAP产品生态链中许多产品的业务逻辑，以及全球用户的使用习惯，并且针对不同使用情境，给出了多种设计解决方案供各个产品线选择。因此，Fiori的设计规范描述的非常详尽。有成熟的设计规范为基础，对设计师本身画图的能力的要求相对较弱，而综合的设计能力要求则更强。
凡事都有两面性，我们的产品线在使用Fiori的设计规范时，问题就来了。首先，2B的产品的功能广泛，模块之间关系错综复杂，设计师需要厘清需求就需要花大量的时间；其次，如此多、且详尽的设计规范如果让团队中的每一个人了熟于胸，熟练选择、到合理运用也需要很久；最后，针对具体产品的一些需求、场景，涉及可用的页面及组件的选择是需要相对统一、稳定的，以保证不同模块间的设计到达最终用户的使用体验相对一致，来降低用户学习的成本，体现公司产品品牌一致性。
因此，一套清晰、简单易用的设计规范的重要性自然被凸显出来。我们的团队指定1-2人做了基于Fiori设计规范的精简规范。目的是让每一位设计师能够花最少的时间开始工作，提高他们的工作效率，把更多的时间花在前期深入了解需求阶段；此外，遇到不能满足的特殊需求，团队内部可以基于需求扩充设计规范，保证设计效率与质量。Fiori当然也在不断的更新迭代，团队也需要不断的学习更新自己的规范库，保证产品与公司的战略一致。
实操案例
接下来，本文以一个需求案例为例，来说明一下，模块设计师如何在这样的情境下运用设计规范。
1.转换需求
理想的情况是，产品团队的每一个人的思维都能够转变成基于用户设计的方式。但是，现实情况是：一些产品经理在同一领域或产品耕耘良久，其思维模式的转变还是需要时间的，所以，设计师拿到的需求可能还是这样的：提供创建销售发票的功能。传统的设计方法可能就在原有产品基础上，套用现有模板，开放这样的功能即可。
但在基于用户设计的思想下，产品模块的设计师就需要与产品经理进一步沟通：首先，需要确认需要执行该任务的主要角色，以及其主要的工作任务有哪些，最好能够梳理出对应的用户画像；接下来，需要了解该任务是用户在什么情况下需要做的，与用户其他需要做的任务关系是怎样的，实际工作中如何执行，需要与什么角色合作，操作的频率如何，在整体任务中的优先级是如何的，用户使用产品过程中的痛点及用户预期是怎样的等等？这些信息有时根据需求还需要组织专门的用户研究活动，进行深入了解。
设计师获得如上所述的一些信息后，将需求按照用户用例进行重新整理，结果如下：
- 长期合作的老客户
任务：应收会计收到老客户付款，按照已知客户信息开具应收发票，并将发票返回给客户。
- 新客户/非长期合作客户
任务：应收会计收到客户付款，电话与客户沟通确认合同内开票细节内容，确定没问题后创建应收发票，过账之后再将发票返回给该客户。
2. 任务分类
清晰了具体的任务及对应执行的角色，我们接下来将对任务进行分类。Fiori将用户任务归纳为五种类型：日常任务、紧急任务、监控任务、分析任务以及专家任务（如下图），并根据不同的任务类别有对应推荐的界面模板。
Fiori的任务分类
根据任务分类的描述，我们可以把总结出的任务归纳为日常工作类别。工作类别的确定是第一步，在后续提交设计方案时，以及跟开发沟通中还会涉及到任务的优先级问题，优先级的确定还需要结合用户画像，以及该角色主要的工作内容，用户使用频率，产品功能定位等要素，与产品经理一同商定。
3.绘制故事版
基于上述用户用例及任务分类，设计师可以同产品经理一起绘制故事版，故事版的主要目的是为了让项目组的其他同事也能够对用户需求有直观感受，同时帮助设计师梳理需求发生的先后顺序，为后续设计用户交互流程提供参考。
故事版
4.编制用例图谱
有了故事版来串联需求的各个环节，接下来，以此为依据，与产品经理共同理清更多的细节：完成该任务需要交互的其他角色、完成该任务的目标，完成任务的背景内容，执行该任务的先决条件以及触发该任务的时机或条件；最后，逐个步骤进行描述用户将如何与系统进行交互，用户需要提供的行为与信息，以及系统需要提供的信息与反馈，最终获得用户执行任务的完整流程，如下图。
用例图谱
5.输出设计文档
Fiori的设计指导中，系统应是按照用户任务组织信息的。页面呈现的内容是能够帮助用户快速执行任务，系统展示的每一页信息应与用户角色所要进行的工作相关，其不仅仅是用户权限的管理，还有按照用户任务重要性以及优先级展示信息。根据我们上面梳理的用户用例图谱，接下来我们针对系统与用户的触点，根据对应的信息，在精简的设计规范库中找到合适的控件与页面，串联任务流程：
i. 在第一个步骤中，用户登入系统后，系统需要呈现创建应收发票入口。以下界面是Fiori提供的开始页面，页面上将用户任务封装为一个个应用，作为用户工作的起点，供用户快速执行任务。设计师根据需要，将创建应收发票作为独立应用，显示在下面开始界面中。因为该任务是日常工作，且与用户主要工作内容高度相关，因此，将入口排列在页面显著的位置。
在开始页面提供用户创建应收发票的应用作为任务起点
ii.接下来，用户通过系统提供界面进行信息录入。初步选择设计规范中标准信息录入界面，考虑到此过程涉及两种不同程度的客户，会对用户录入信息有影响，但并不必体现在系统界面当中，因此，可以在设计文档中添加备注，方便用户快速完成录入工作：
a.对于老用户，系统中已经存储了相关的信息，因此在选择老用户时候，系统自动给出对应创建应收发票有效信息，较少用户输入。
b.对于新用户，不中断用户的主要任务为前提，提供便利的创建客户方式，辅助客户快速完成开票任务。
此处还有一个细节，作为用户日常工作，用户是需要连续录入一批同样的单据的，当完成一个单据的录入及保存后，如何快速开始进行下一张单据的录入也需要考虑进来。因此，在标准录入页面中选择加入优先权重的按钮，并且将”保存且继续创建“作为优先级最高的按钮凸显出来（如下图），方便用户快速继续录入。
信息录入界面
iii. 用户填完必要信息后，用户提交系统保存，系统验证信息合法性并执行保存。此时需要区分：点击”保存且继续创建“后，为达到让让用户继续快速录入的目的，选择继续使用信息录入界面，但给出保存成功的信息提示；点击“保存”按钮后，在给出保存成功提示信息后，考虑让用户看到被保存的录入信息，选择使用信息显示界面模板以展示所有信息。为体现顺畅的操作流程，对于处理信息填写有误等，导致不能保存的情形，因为设计规范已经详尽列举，且已经给出具体设计解决方案，设计师则只需要根据已有的设计需要，结合对应的错误类型，给出相应的错误提醒、错误原因及推荐的解决办法，这部分与产品经理讨论确认后，即可作为后续补充说明添加在文档后即可。
“保存且继续录入”界面
“保存”后界面
除了对当前提交单据的浏览，考虑到用户对所有保存的单据的预览可能性，需要再选择一个页面模板满足这一需求，此处选择master-detail结构页面，方便用户切换历史单据，并查看每一单据的细节。
Master-detail 页面
通过该案例可以看到，Fiori的页面跳转逻辑与传统中ERP的信息层层剥离的方式不同。Fiori基于任务的页面跳转逻辑是给用户更加快捷的完成任务的入口与界面，减少用户经过的步骤及界面，提高用户完成任务的效率。
传统层层剥离的信息展示方式与基于任务的跳转逻辑
如果不理解Fiori设计的精髓，只是按照页面与控件使用copy出一套外观像Fiori，实际与Fiori的核心理念却南辕北辙的系统，差别也一目了然（如下图）。这只是一个简单的小例子，放大到整个系统，这样的影响必然会把产品引向另一个极端。每人节约1分钟，该角色一年可以节约的时间，到整个企业范围内可以节约的资源都是ERP软件可以提升优化的空间。
传统设计方式与Fioir设计方法的差异
个性化需求如何满足
作为业务模块的设计师，使用设计规范，必然会遇到规范库中不能满足需求的情况。有些可能是规范完全不能满足的需求，有些则是使用规范不能达到最理想的设计效果。如果你对需求的理解非常深入，在是否自定义这部分的设计时，有以下建议（如下图）：
- 进行价值评估：结合需求重要程度/用户使用频率/产品策略等选择是否牺牲可用性，以及对使用现有规范的弊端进行说明，综合判断是否进行新设计方案。
- 对于频繁出现的同类型设计进行统计，提交设计规范建议，寻求支持。此时也可以结合价值评估，判断是否暂用规范。
总结
作为一个服务企业软件设计的团队，多人协作，项目产品多且周期长，还是需要设计规范以保证设计语言的运用，使产品不仅在视觉上有一定的一致性，使用上也能有据可循，减少用户的学习成本，体现公司品牌一致性。设计师在基于成熟的设计规范进行产品设计时，应该更多的把精力放在理解用户真正的需求上，从繁冗复杂的流程中梳理高效快速的任务流程，将服务意识融入ERP从出厂到用户使用各个环节中去，为用户创造真正有价值的企业软件。
（本文不是严格design led development的设计流程，也不涉及design gate 审核等内容）
相关阅读：
什么是Fiori
被忽略的设计原则
若有收获，就点个赞吧
0 人点赞
