用户任务分类的方法

在Fiori的设计语言中，Role-Based被作为基础原则指导设计活动。在实际的项目中，它是如何执行的？在Fiori提供的设计流程中，有一个关键的对用户任务分类的方法，这个分类方法在企业级产品的设计中是通用的。本文将会对这个方法进行详细介绍，并基于自己的经验，提炼不同任务类型的设计思路。

首先需要理清楚：任务、角色、用户，这三者之间的关系。举个简单的例子，假设交互设计师的任务是：做控件、写文档；视觉设计师的任务是：画图标。那么小强作为某公司员工，他的角色是交互设计师和视觉设计师，每天的日常任务即：做控件、写文档、画图标。在这样的结构下：任务是最小的单元；不同任务的组合，构成了角色；同时，一个用户可以有多个角色。

通常设计师可能先要同产品经理深入讨论需求，必要时候展开相应的用户研究活动，了解用户角色、需求及用户日常工作需要完成的任务，通过user journey map梳理用户日常工作任务与流程、其先后顺序与任务之间的关联性等。有了以上信息，可能有人通过任务频度、优先级对任务进行分类，这种方法快速方便，但缺点是颗粒度过粗，任务与设计组件之间的关联关系难以直接建立。Fiori的任务分类方法可以很好的解决这个问题，它将用户任务分为以下五类：

• 日常任务 Routine Task
• 突发任务 Firefighting Task
• 监控任务 Monitoring Task
• 分析任务 Analytical Task
• 专家任务 Expert Task

这5大类任务几乎涵盖了全部的企业级产品的任务类型，同时将特定场景融入其中。下面详细解读每种任务类型，以及与其相关的设计组件和对应的设计目标。

日常任务-Routine Task

日常任务，顾名思义，天天要做的，例行公事。这种类型的任务通常是有固定的流程，周期性的，并且对操作效率有较高的要求。用户对这样的任务非常熟练，甚至是肌肉记忆，不需要动脑筋就能完成。典型案例：会计人员每天都要去查看系统内的凭证，手工录入单据，审核报销的材料，合同的审核，收付款等。

这类任务占系统的大部分比重，涵盖了绝大部分基础交互行为：增删改查。对应的设计组件及设计目标也非常容易归纳：

• 首页：为用户提供更有效的聚合信息，方便用户基于系统数据做出决策，执行后续任务。
• 列表页：有序、可控的呈现同类型的业务数据。尽可能提供批量操作，或在列表行内提供操作。避免让用户执行冗余的导航行为，如，跳转下一页面完成少量数据修改动作。
• 过滤器：通常显示在列表页内，让用户更方便筛选和精确的定位到目标对象，
• 详情页：结构化的呈现业务对象信息。对需要进行大量创建任务的角色，创建页面需要提供高效录入方式。如，支持全键盘录入。
• 系统内的全局搜索：简化系统路径，让用户更高效的定位到目标对象。

突发任务-Firefighting Task

突发任务即突发的、需要及时处理的任务。这种任务通常由外部因素触发的，比如电话、邮件、人为通知等，用户需要对此作出及时的反馈，并在系统里执行相应的操作。典型案例：销售人员接到客户电话或者邮件，需要对一个具体的订单发货日期进行修改。

这类任务通常会打断用户当前正在进行的任务，或者要求用户同时处理多个任务。任务起点通常不固定，但是终点通常会是在一个对象的详情页。整个任务流程可能会存在跨层级和模块的复杂导航。所以尽可能多的给用户提供上下文内容，对信息的优先级进行排序，这些对用户的决策和后续操作至关重要。通常使用的设计组件和设计目标如下：

• 系统内的全局搜索：由于任务的突发性，全局搜索可以更好的帮用户定位到目标。所以尽可能的让用户将全局搜索作为这类任务主要的导航方式，并且搜索的结果需要提供足够的信息和后续操作，让用户做决策。
• 通知：可以是导航的一种形式，并且通知消息要给用户提供足够多的上下文，帮助用户做后续的操作。
• 预览卡片：给相关的业务字段提供一个预览卡片，可以减少用户的页面跳转，让用户更高效的获取到对象的关键信息。
• 列表的查找，排序，筛选：列表页的常见功能，可以更好的帮助用户组织信息。
• 反馈：在完成任务的时候给用户提供较为明显的提示，告知任务已完成。

监控任务-Monitoring Task

监控任务，有目的性的去监控某个具体领域的数据和指标等。信息高度聚合，展示结果开放是监控内容上的特点。其实这类任务对某些角色也有可能是日常任务，但由于目的和内容的特殊性划分到监控类。最常见的组件就是各种仪表盘。这类任务对内容的定制化要求极高，固定的角色可能对内容的要求基本固定，但每个用户都可能都有自己的偏好和特化的需求。很多管理层用户对这类任务有强烈需求，我甚至见过老板要求把公司的核心数据显示在电视上，挂在办公室里面天天看着。

• 内容定制化：需要针对当前的角色和用户定制合适的内容，并且给用户提供自定义的方式。
• 为后续分析做铺垫：通常监控是为了发现异常，后续任务可能是基于一个异常调用具体的分析工具，不断的缩小目标范围。所以监控本身通常是这类任务的起点。
• 信息聚合：本质上是对一类信息的内容进行提炼，以图表或数据的形式概括性的提供给用户，帮助用户对这类信息有一个全局观。所以仪表盘也好，嵌入式图表也好，目的都是一样的。需要基于用户的场景和角色，在合适的地方为用户提供这样的聚合信息。首页，列表页，甚至是详情页都是可能会需要的。

分析任务-Analytical Task

分析任务，对问题的本质进行分析进而得出结论，数据挖掘之类的任务。这类任务在系统中通常是领域专精，需要完成这类任务的用户通常也都是资深的专家。前面有提到，一般来说监控任务是分析任务的起点，所以分析工具要能够很好的和呈现信息的仪表盘等组件衔接上。

这类任务比较复杂，对设计的业务能力和设计能力都有极高的要求。往小了说，是交互式图表的设计，国内开源的组件库有AntV。往大了说，就是BI（Business Intelligence）工具，业内有很多产品专门来做这些任务，比如微软的Power BI，SAP的Analytics Cloud和Lumira，Tableau旗下的各种产品。关于交互式图表的设计，阿里在墨者学院里提供了非常优质的学习资源，感兴趣的同学可以访问下面的链接进行深入学习。我这里引用部分核心观点：人类寻求信息的基本逻辑——先大体，再局部，然后聚焦兴趣点进行探索，这是一个由表及里的过程。

数据获取：该层解决用户的第一个问题“是什么”，用户主要通过浏览查看来获取数据，其通用交互范式为 Overview + Detail（概览+细节），常见于传统数据报表、汇报型图表、大屏等，比如流量监控、区域销售大盘。

信息加工：该层解决用户的第二个问题“为什么”，当图上有看不懂的信息时，用户期望有人告诉他为什么会这样，或者自己查探明究竟，其通用交互范式为 Focus + Context（聚焦+关联），常见于富交互的统计报表，或海量、高维、多源的可视分析系统。

知识流转：该层解决用户的第三个问题“怎么办”，当获取洞见通用交互范式为 Annote + Guide（标记+指引），常见于可视分析系统、智能分析、智能决策系统，比如运营专员对异常点进行标记辅助管理员进行决策，智能系统对整体趋势进行解读与归因分析。

AntV交互设计指引
https://www.yuque.com/mo-college/vis-design/yygtlg
AntV图表用法指引
https://antv.alipay.com/zh-cn/vis/chart/index.html

对于BI工具的设计，交互式图表只是BI呈现数据的部分，更核心的是图表的编辑器的设计。这部分的设计难度非常之高，业务逻辑也很难理解，笔者目前也在学习阶段，先挖个坑，等以后学有所成了可以专门写一下这部分的内容。

专家任务-Expert Task

专家任务，这类任务通常业务流程和交互行为都很复杂，并且组件很难在其他模块复用。除此之外，用户学习成本高，需求多样化，设计上经常因为实现需求或者技术限制做出妥协。和分析任务一样，专家任务也是领域专精，用户通常都是资深专家（其实分析任务也是专家任务的一种，只不过分析任务更常见，设计思路更普世，所以独占了一个分类）。常见的任务有做排产计划，财务的对账，报表的设计，复杂的异常处理任务，各种编辑器，模拟和测试，系统的后台配置等。用户可能会有一个专门的工作台页面来完成相应的任务。

因为需求的复杂和多样化，对应的组件也是千变万化，这类任务很难沉淀出通用的设计思路。总的来说，这类设计对设计师本人的综合能力要求很高。设计一个专家任务，很可能就是一个项目，设计师需要学习新的业务知识，进行详细的用户研究，挖掘用户本质的需求，提炼业务流程，然后再展开相应的设计。

其实在这5种任务分类，背后还可能会有用户之间的协同任务，几个不同的用户，不同的角色，在系统里面共享和交换信息，共同完成一个目标。这里面会涉及到很多即时通讯，外部系统的集成，会话式交互，协同流程等问题，每个话题都是一个大坑，在这里就不详细展开了。

结语

以上就是Fiori给出的对用户任务进行分类的方法，非常的简洁和实用，对于企业级应用的设计来说很有指导意义。建议每个设计在开始之前，首先通过详细的用户研究来发现一个具体的用户的角色是什么，在日常工作中需要完成哪些任务，任务的频度以及任务之间的关联关系，再对用户任务进行分类。任务分类完成之后，每种任务对应的常用设计组件就一目了然，熟练的设计师基本上就有一个信息结构的雏形和初步的设计目标，知道如何选取合适的组件来构建整个交互设计了。