从哈罗单车上锁，聊聊任务链路优化设计的思路

一、起因

最近突然喜欢听着小曲蹬着车子，不过我没有自行车，所以就选用了大众款蓝色哈罗单车，不过有意思的是发现整个用车体验跟原来有了不少变化，除了车的外观差异，更让我印象深刻的是还车时只需要在手机上进行操作即可，不知道大家是否还记得原来的还车过程，这里我帮大家回忆一下；

这个过程本身没什么问题，但实际上匆匆忙忙的大家忘记手动上锁还车时有发生，并且当你想起来的时候，手机上也只能干看着扣费，还得折返回去进行锁车。本人更离谱，有次打开手机发现忘了手动锁车，一看行程，已经被人骑出去老远啦～

但这次不再需要手动上锁来还车了，整个锁车还车已经借助物联网技术将操作集成到手机上进行了，这意味着现在忘了还车还能亡羊补牢，并且还车也很轻松，考虑到最终骑行事件是在手机上完成闭环的，忘记上锁和离开后无法上锁也就一下解决了，这便是技术应用与交互链路优化设计的美妙之处！

人嘛，总是怕麻烦，想走捷径想偷懒才是常态，而任务流程或是交互链路优化就是帮大家更轻松更方便的完成任务操作，这不妥妥的用户体验优化必备能力项嘛～，那就简单聊几句优化设计的思路吧。

全链路场景设计：

二、任务链路优化有何价值

一般来说做交互链路优化的核心价值或是目标就那么几个；

1. 更好用

即更加高效便捷好用的意思，这短短三个字就直接包含了大家常挂在嘴边的易用性、可用性啥的了，好的交互就应该是尽可能的为用户提供简单好用的交互，举个例子，近期在使用阿里云 Flow 的流水线，期间我也用过其他家的 CI/CD 服务，相比之下我觉得阿里云 Flow 的流水线编排反馈就做的更胜一筹，“更方便”加一分。

2. 更准确

意味着为用户提供正确的服务、流程、功能、组件、信息反馈乃至视觉效果，为的是提升产品的可理解与易用性，从而达到降低学习成本提升效用，减少跳失率或出错等负面情况。

3. 提升意愿

嗯！花费那么多心思让产品体验变得更方便更准确就是为了提升用户的使用或付费意愿，算是任务路径优化设计的底层价值吧。

三、任务链路优化的流程

出于不同的行业差异，优化流程的细节可能有差异，但基本上可以通过五个阶段来概括：

1. 找到问题

在一套服务系统中，当用户反馈难用、麻烦、任务卡点、不如传统服务模式时，那就意味着有优化的空间，设法洞察问题、定位问题就可以开展工作了。

2. 优化目标

通常进行任务流程优化的目标基本上就是降本增效、解决卡点、体验升级，通常根据实际问题也会有更详细的优化目标用于执行推进。

3. 方案构思

出于问题与目标而进行的优化方案构思，这其中包含了优化策略、方案原型、版本兼容等问题，主要是为找到优化的好办法。

4. 方案验证

严谨些，设计者不能由个人主观认定方案一定可行，新的方案最好经过用户验证或量化测试来保障效果，并且测试验证的过程中遇到的新问题，也应该留意并放到持续改进中。

5. 持续改进

事实上这是一个不可避免的过程，原因有三：

1. 优化一部分后就可能会出现新的问题。
2. 问题可能没办法一次改到位，只能分批持续推进。
3. 最后则是伴随业务发展需要持续地做出改变来响应。

所以分好优先级后慢慢改吧，也许随着业务发展变化，有些问题就不是问题了。就像网络段子一样，当初一个需求十分紧急，但是研发排期太满，半年后这个需求还在，看来这个需求也不是十分紧急嘛～

这里再补充两个近期在用或接触到的优化流程～

PDSA 或 PDCA

PDSA 是指“计划-实施-研究-行动（Plan-Do-Study-Act&Amend）”，属于一种精益方法，常用于衡量变更的有效性，部分企业的专有云解决方案架构师也叫做 PDSA，并且有对应的平台组织。PDSA 虽然不能很好帮助产品做创新或直接解决问题，但在流程优化解决的实施与验证管理方面是好手，这一方法的四个步骤分别如下：

1. 计划(Plan)：明确业务目标，聚焦核心的业务流程，识别潜在的改进点，定义问题与有效改善的可量化指标。这一步骤可以结合竞品分析、市场调研、SWOT 等手段来分析梳理。
2. 实施(Do)：根据现有的情况与目标，设计出可行的解决方案，然后发起执行与指标监控，之后则比较效果来衡量有效性。具体做什么则需要结合流程链路优化来，例如删减操作步骤、整合页面信息等。
3. 研究(Study)：收集数据相对于初始的业务状态进行数据比对与分析，看看对应的可量化指标是否有所好转以及是否有新的发现，例如效率、成本、门槛等指标。
4. 行动(Act & Amend)：根据研究分析的结果，确认哪些是可行哪些是不可行的，并做出下一步的行动计划，并通过反馈与研究洞察对业务流程进行持续的改进优化。

而 PDCA 则是指“计划-实施-检查-行动（Plan-Do-Check-Act&Amend）”，检查主要就是验证效果是否有效，有效的则应用或标准化，没用的则继续改进，相比下，PDSA 的内涵会更广泛些。

SDCA 循环法是一个持续改进模型

SDCA 是指“标准化-执行-检查-总结（Standardization-Do-Check-Action&Adjustment）”，跟 PDCA 有些类似，主要差异在于第一步骤；

标准化(Standardization)：识别和定义改进过程中需要标准化和优化的关键步骤和流程，例如软件系统的交互规范化、场景模块化、系统设计、流程统一等，亦或是产品客户端的操作手册、新手引导、统一操作流程、测试用例、准入门槛等标准化内容。

SDCA 循环法的目标是实现持续改进，可以减少重复性问题再次发生、精简和标准化执行，形成可靠、准确、高效的结果，是一种结构化的迭代的方法，且适用领域广泛。

四、优化过程的焦点

这里先放 AI 的答案：

看起来也没啥大毛病哈，那么接下来围绕下图的概念说说我认为的焦点：

1. 目标用户

通常完成一套服务的交付会涉及各种角色，那么就需要根据用户的特征或偏好提供差异化的服务与内容交互。一般需要人工操作的部分往往更容易出问题，通常借助用户研究、用户测试都能获取到一些有用的信息来指引任务链路优化。

2. 服务体系

即提供什么样的服务解决什么样的需求，之所以说服务体系是因为现在的产品很少通过单个或极少的服务来打造一个产品，这就意味着要对用户进行合理的分类管理，对标提供合适的服务与版本，减少不必要的服务或是混乱的服务带来的产品臃肿与任务链路混乱，例如招聘软件的招聘与应聘视角分离。

3. 使用场景

场景化或情景洞察一直是产品设计的重点，可以洞察到更多用户实际遇到或潜在的痛点，以及线上线下等环境带来的微小差异性，这对任务链路优化有很大帮助，作为焦点一定不为过，至于如何实践，我们可以通过观察线下传统服务的过程，或是采用用户测试的方法进行观察与分析获取优化指引，哪里用户卡住了或是吐槽了那就表明有优化空间。

4. 交互媒介

指在整个服务发起到结束过程中所经历的人群、设备、通信、内容、第三方服务等，就以哈罗单车的租赁过程为例，其中主要的核心媒介就包含了“用户、手机、应用、网络通信、商家服务器、自行车、付费服务”，那么以这些作为焦点有什么用呢？事实上一套完整的服务正是由这些媒介之间的不断交互，才使得哈罗的租赁服务可以如此灵活，所以在整个服务流程中让媒介之间更智能、自动、高效的完成衔接与交互，就成了必要的焦点了。

5. 构成信息

几乎进行任何服务都离不开特定的构成信息与交易，举个最简单的例子，晚上你来到街边摊，想要一份烤冷面，那么你除了要掏钱以外，你还要跟老板确认口味、加料、价格这些信息，这些就是构成任务进程的信息，这些信息可以通过问答式确认，也可以提供招牌信息给食客确认，总之将这些信息更简练准确的进行交互，就能实现任务链路的优化，在应用程序的交互设计中，常常表现为用正确的描述语、正确的交互组件、正确的视觉表达、正确的反馈等，事实上应用程序本身就是由各种各样的信息交织在一起所构成，所以“做任务链路优化不仅是减少操作步骤而已”。

6. 业务模型

本来是没有业务模型这一环的，但考虑到实际的业务场景中会有很多复杂的部分，常常盯着这些细小的部分往往容易一叶障目，而业务模型的优势就是鸟瞰全局，并以简单易懂的图像进行表达，这个过程可以让我们更好的理解业务的概念与边界，可以看到各种界面与交互媒介之外的业务本质，帮助我们在优化过程中清晰重点与方向，以达成结果为导向，避免在细枝末节上投入过剩或南辕北辙。

五、一些还不错的思路方法

1. 无前置轻快任务先行

当有多个任务进程需要处理时，就可以参考此原则来优化任务操作的路径，有点先易后难的意思，当多个任务之间没有前后的依赖关系或限定要求时，那就先处理轻小快捷的事项，当用户已经完成部分事项后，剩余事项就更容易推进了。

当然也可以根据此原则将前置条件整合处理，这样在后续的任务路径中就可以减少相应的条件卡点，例如大量安卓应用第一次安装启动时就会向用户索要存储、录音、相机等基础权限，那么之后使用相关服务时，就不用触发授权窗口了，不过权限还是要遵循用户隐私政策法规哈。

2. 渐进式交互

就是将复杂的任务进行拆分，通过循序渐进的方式一点一点完成任务，这样可以减少任务达成的门槛，让用户更加专注，并且可以在过程中培养用户的意识，是任务链路优化的常见手段之一，也是游戏新手村屡试不爽的教学模式。

3. 并行规划

通过规划使多个任务事项穿插或并行开展，本质就是任务事项的拆分管理与资源规划协调，通过使更多事项同时或尽早进行，来加快任务目标达成，以效率来推动任务链路优化的目的。

在资源规划协调时，可以通过时间、状态两方面下手，重复的、自动的、久等的、卡点的可以考虑先行，然后再处理其他琐碎事项即可。

4. 群体划分

即我们常说的用户分层，通过提供差异化的服务或任务路径来对应不同的用户群体，以减少无效或干扰的流程操作，例如常见的会员与普通用户就会享受到两种不同的服务体系。

5. 技术创新

通过科技技术的应用，可以为用户带来更多的便捷与新鲜感，特别是具备商业属性的技术，会更快地成熟与普及，然后影响到更多人的生活方式。这个过程可以概括为“科技-认知-应用-习惯-直觉”，就像现如今的扫码支付、人脸识别、指纹解锁一般，不仅在各种领域都有了应用，并且你一看到相关信息，直觉就会引导你该如何操作。

6. 约束与枚举

面对各种复杂的操作、选择、输入输出时，尽可能的枚举出选项或模板，这样用户操作会更规范也不容易困惑，对于那些用不了或有特殊含义的内容则通过样式、组件、提示等进行合理的约束，避免任务流程出错，也帮助用户识别与理解，例如报错信息就要约束用红色反馈，电话号输入就要约束为数值输入等。

7. 5why 分析法

一个老生常谈的方法，可以帮助我们深入问题和洞察底层含义，用法就是面对问题不断的追问为什么。

8. 场景化分析

简单讲就是在解决或优化任务链路的时候，带上人物、目标、行为、环境、时间诸多因素综合性思考，形成一个更完善而真实的洞察环境，以帮助获取更多有价值的优化信息，此前有出过一期关于场景化思维的专栏文章，写的比较详细，有兴趣的可翻阅一下：

9. ESIA 分析法

ESIA 是企业流程优化中比较出名的方法，但也不仅限于企业流程优化，其核心理念就是减少流程中非增值活动，以及调整流程的核心增值活动。由消除-简化-整合-自动化（Eliminate-Simply-Integrate-Automate）四个步骤构成，在任务链路优化中也是一个不错的思路或策略。

10. ECRS“分析法

是工业工程学中程序分析优化的四大原则，主要由取消-合并-调整顺序-简化（ Eliminate-Combine-Rearrange-Simplify）构成，此前在做一套代码流程优化过程中，此方法给我带来了不少帮助。

1. 取消( Eliminate)：首先是根据规模、阶段或目标，考虑哪些是可有可无的，或价值有限的，能换掉的就换掉，能去掉的就去掉。
2. 合并( Combine)：在不影响最终目标与质量的前提下，根据某些属性，将多个工序进行合并或融合。同时也要考虑融合后的体验与兼容性，如若不然就不要强制合并了。
3. 重排( Rearrange)：即将相关的工作流程或内容进行新的顺序调整重组，以满足更合理更流畅的结构，例如减少了流程往返操作的不便、先易后难的配置表单。
4. 简化( Simplify)：不是取消或减少而已，而是经过以上工序后。将剩余的或整体进行简单化、完整化、便捷化、智能化处理，可以是新技术应用也可以是交互方式的调整不等。

任务链路优化的思路或方法肯定还有诸多，这里不再列举了，实际上掌握或了解几条比较实用的就差不多了。

六、一些还不错的分析工具

说完了以上内容后，再补一些常用的优化工具，当然了，主要是我个人常用或觉得实用的一些：

1. 整合分析类 

思维导图：可以快速帮助我们对信息进行树结构化与逻辑整理，并且可以结合图文以及功能图标等来完成管理及计划，能够将业务或功能框架快速显现出来，是很好的辅助工具之一；

矩阵表格：可以很方便的将信息进行罗列与比对分析，在一些信息介绍或数据分析时常常会用到；

服务蓝图：可以将完整的服务过程绘制出来，能够包含人物角色、前后台关系、阶段过程、状态扭转、交互触点等；

体验地图：可以将服务、目标、用户、交互、反馈进行阶段化整合分析；

泳道图：可以根据时序对流程进行可视化，可以很好的传达职能部门或是角色之间的交互过程，也可以细分交互媒介、服务终端等因素之间的关系；

流程图：主要就是围绕一个事件的开始到结束过程的流程可视化，流程图可以系统化的梳理业务逻辑与交互链路，泳道图也仅是流程图的一种，相信大家都很熟悉了，就不过多赘述了；

鱼骨图：是一种根因分析工具，有头有尾有分支，像鱼骨，常用于定位问题发生所导致的根因，也可以用来制定任务目标进程的管理；

状态机：一种针对事件状态扭转关系的流程图，用于描述系统的状态和事件，以及事件引发系统在状态间的转换过程，有点像是一系列的if语句，在中后台的系统设计中常常会有需要梳理状态的情况发生；

业务框架：业务框架主要是一种将业务过程和活动进行组织和分类的方法，具有较大的颗粒度与较强的全局性，常用于表达业务框架单元之间的组成与活动关系。而业务模型主要是指业务概念关系的可视化简图，前文的流程图、泳道图、状态机等等都可以是业务模型；

2. 监测洞察类

交互自检：主要用于交互设计的查缺补漏跟避错，同时在交互链路自检的过程中是可以主动发现问题，并验证优化是否可行或合理；

使用性测试：也叫做可用性测试，是对优化结果或Demo进行测试检验的过程，通过模拟真实的任务操作过程以达到洞察、探索、比较、效果验证等目的；

A/B测试：常用于方案之间的效果比较或验证，通常都是借助工具引流获取一批真实用户的测试反馈，是一款真实有效的验证手段，不过方案之间的差异不宜过于悬殊；

数据漏斗：像任务链路这种多线程或是节点较多的事件，单薄的点击率或转化率的作用是很有限的，这时候就需要在相关任务节点上布满更多的埋点，将用户流量与数据转化的情况用漏斗视图表现出来，然后就可以针对任务链路进行分析或比较了；

最后

本次的分享更多是从系统设计本身出发，实际上人总是最不可控的因素，在整套任务链路优化的过程中，也可以多考虑人工部分的管理与培训优化，想象一下一家电商店铺，什么都还挺好的，结果你跑去咨询客服的时候，人家爱搭不理，你问一点他答一点，就是不一次说清楚，你能舒服吗？

写到这里已经几千字了，不打算找案例展开讲了，最后再为那些不爱看字的朋友们浓缩式总结一下；

等待少点引导多点，能一次说清楚的就不要云里雾里，能简短操作的就不要搞复杂，能给选项能给规范的就不要让用户瞎填，一次做不完的就分几批做，交互组件要匹配不要生搬硬套，能给自动方案的就不要让用户瞎折腾，能用先进实惠的智能技术就不要技术落伍了。如果觉得写的还不错，期待点赞收藏或分享，我将再接再厉～

不定期更新，欢迎关注或评论区留言，下期见！