最近思考了很多关于如何设计一个简洁的、移动的 OA 系统，或者说是 BPM 系统，在尝试了各种不同风格的软件之后，我产生了对于任务驱动的好感。这里先翻译一篇国外关于用户界面上采用任务驱动来设计的文章，先从用户界面这个小的尺度来推敲任务驱动的核心是什么。
原文载于 http://www.uxmatters.com ，作者是 Oleksandr Sukholeyster，原文链接 http://www.uxmatters.com/mt/archives/2014/12/task-driven-user-interfaces.php
拥有 IT 部门的组织比没有的组织更有效率，实际上，如果你的组织没有有效地维护软件并且使软件更高效地提供服务，钱就打了水漂。
在与用户进行会话的过程中，用户体验在消费类应用程序的影响是显而易见的，但是对于企业类软件却并非如此。对于不是软件公司的那些组织来说，使用软件自动化业务的进程往往是非常缓慢的。然而，企业应用在用户体验上的效果直接作用于企业和组织的表现上。如果一个企业雇员使用的软件在用户体验上更加友好、使用起来更方便，那么雇员的生产力和效率会更高，在一个企业中，人力（注：人员就是生产力）的成本越高，这一点就越明显。
那么企业雇员通常在做什么呢？他们通常完成自己的独立工作，完成他们的经理分配给他们的任务。企业越大，工作细分的程度越高。在细分好的环境中，良好的细分帮助雇员把自己能力最强的部分发挥在对应的工作上，取得最优的效果，而不是每个人都做很多事，最终绩效只能取得一个平均数。但是在日程生产活动中的细分，带来了沟通上的问题，如下图所示：
一个典型的任务工作流程和沟通：
在这个流程里，一个普通的雇员（可能做任何工作），或许不需要经常和他人交流分配子任务的内容；
任务驱动的 CRUD 界面
为了更好的分配任务并提供恰到好处的反馈，很多工具被聚合起来，包括但不限于：语音、电话、电子邮件和及时通讯工具。随着企业的发展，能够自动完成任务分发的需求也在增长。自动化的任务管理可以帮助经理人跟踪并掌握正在发生的事情、减少风险并且保障在合适的时间完成合适的任务。
尽管自动化非常有用，但那时很多端对端的企业流程还是需要人工参与交互。比如为了推进一个业务流程，人们会需要处理请求或者管理异常或者其他必要的操作。
相较于聚合了“创建-读取-更新-删除”，首字母缩写为 CRUD 的很多低效率自动化程度不高的传统应用程序的用户界面，随着任务流概念推出的“任务驱动的用户界面”是更好的。但是步行的是，每天的工作和生活中还是有很多的 CRUD 界面的程序在运行着。CRUD 界面的用户是这样跟着文档信息流来完成操作的：打开展示数据的界面——改变数据对象的属性。在另一个界面里，改变一个值，例如把值 xyz 变成 ABC。
举例：在一个医疗应用中，需要改变对于病患的描述
- 在 CRUD 系统里：医生找到病患的档案——描述；然后点击编辑，编辑内容；保存
- 在任务驱动的系统里：医生找到病患的档案——描述；然后点击编辑描述，编辑内容；保存
在那些对于业务而言没有太高贡献价值的系统，CRUD 的工作流还是很有效的，但是更重要的、更复杂的任务要求下，CRUD 就变得没那么高效了，此外，在这些情况下，出错的概率也在增加；在一个流程中，用户可能漏掉了一步，又或者有很多人完成的任务，每个人的完成方式不同，使得制作任务完成报告变得困难。在针对目标 A 的变动情况很方便地可以生产报告的时候，回答如下问题是很困难得，甚至不可能；例如：“用户通常在哪一步出现疑惑？”“在工作流结束之后，用户的普遍表现如何？”以及其他类似要求根据用户行为提出的问题。
工作清单应用
在一个任务驱动的用户界面背后，或者就此归纳一下最重要的两件事：
- 用户希望怎样使用软件？
- 在流程中，软件可以如何引导用户？
任务驱动的用户界面，是 命令——查询——责任——分离（CQRS），这一创造高性能可扩展企业架构核心元素的基石。越来越多的企业开始转型成为流程驱动的企业，使用工作流引擎，BPM 软件来自动化他们的流程，工作清单应用，正如下图所示的进行了聚合。一个典型的工作清单应用让用户可以检视一个任务清单，查看任务详情并完成任务。
在市场上已有的软件和用户实际需求之前任然存在差距。例如一些软件商没有做好国际化；一些软件的任务过滤和分级功能需要强化。如果一个任务不能被完整的支持，那么流程应当被设计成允许可替代的情况。
现在，让我们忘掉业务流程管理 （ BPM）等等软件和模型，我们先专注于人们工作的方式，我们必须考虑：
- 任务池的基本任务：雇员需要完成的
- 分配给雇员的任务：通常情况下，任务根据重要性被分配给不同的雇员
能够直接分发任务给指定的人或者小组是必须的，并且也应该创建一个他们可以选择任务的任务池。例如公司里面有一个小组调查贷款的核验情况，可以直接分配到人身上，也可以让整个小组自由选取，在这两种分配方式上，实际可以决定分配方式的是每个人负责的区域，基于这一点这两种方式都行得通。
一个人完成任务的三个关键要素如下：
- 上下环境：一个人完成一项任务需要收集哪些数据？决策的时候哪些额外信息是有益的？
- 引导：一个人该如何完成任务？正确完成一个活动需要那些指导方式？
- 数据：哪些数据需要被提取并用于整个的大任务？一个人该如何报告任务结果？
下图展示了一个任务流：
每个任务的定义应当可以回答下列问题：
- 谁能完成任务？——包括群组角色和动作类型
- 哪些需要完成？——定义了任务
- 这些任务怎样完成？——列示了任务的输入和输出
- 关联参与者？——列示关联的需要参与的人
- 什么时候必须完成任务？——定义了任务的时间
在实际操作中，有时任务会变成了员工需要完成的工作对象，以下是操作中一些典型的要素：
- 升级——如果员工基于任何理由无法完成任务、无法按时完成任务、或者结果不符合预期；升级通常需要指导者重新分配任务、重启任务或者取消任务
- 取消——如果任务取消了，那么需要做必要的操作来修正影响。例如会议取消了，日程应用应通知参与方会议的取消，并释放对应的如会议室等资源
- 顺序——一个任务的输出是另一个任务的输入
- 并行——在一个任务开始之前，所必需的任务必须都完成
- 任务池——任务不会直接分配给某个人，而是某个群组。每个人可以从中选择自己的任务
- 任务分配——分配的实际方法
- 固定的——每个人领取自己的指定任务
- 动态的——任务的完成人没有确定
- 有分配规则——按照不同的要求进行分配
- 提醒——一个任务的提醒应当多次发出，例如基于任务的时间和需要提醒的系欸但进行提醒
结论
现在的应用程序基本上都有自己的任务界面。一个良好设计的、任务驱动的界面会导致更好的结果。此外，关键词引导或者互动式的用户引导可以帮助用户做出正确的操作。因此，应用的用户体验应该集成到流程之中，用于集中用户的注意力和行为，而不是盯着数据不放。在此基础上，我们可以创造出更有效率的软件。
