在外出的时候，又是因为路线有点远的情况下，碰到路边的共享单车，是不是会为了图方便打开手机扫一扫立马走人呢？但是到结束的时候，会发现偶尔有忘记手动锁车的情况，这就非常不妙了。面对这种问题，笔者整理分享了一篇关于建议优化设计的思路的文章，大家一起往下看看吧！
最近突然喜欢听着小曲蹬着车子，不过我没有自行车，所以就选用了大众款蓝色哈罗单车，不过有意思的是发现整个用车体验跟原来有了不少变化，除了车的外观差异，更让我印象深刻的是还车时只需要在手机上进行操作即可，不知道大家是否还记得原来的还车过程，这里我帮大家回忆一下；
这个过程本身没什么问题，但实际上匆匆忙忙的大家忘记手动上锁还车时有发生，并且当你想起来的时候，手机上也只能干看着扣费，还得折返回去进行锁车。本人更离谱，有次打开手机发现忘了手动锁车，一看行程，已经被人骑出去老远啦～
但这次不再需要手动上锁来还车了，整个锁车还车已经借助物联网技术将操作集成到手机上进行了，这意味着现在忘了还车还能亡羊补牢，并且还车也很轻松，考虑到最终骑行事件是在手机上完成闭环的，忘记上锁和离开后无法上锁也就一下解决了，这便是技术应用与交互链路优化设计的美妙之处！
人嘛，总是怕麻烦，想走捷径想偷懒才是常态，而任务流程或是交互链路优化就是帮大家更轻松更方便的完成任务操作，这不妥妥的用户体验优化必备能力项嘛～，那就简单聊几句优化设计的思路吧。
一般来说做交互链路优化的核心价值或是目标就那么几个：
即更加高效便捷好用的意思，这短短三个字就直接包含了大家常挂在嘴边的易用性、可用性啥的了，好的交互就应该是尽可能的为用户提供简单好用的交互，举个例子，近期在使用阿里云Flow的流水线，期间我也用过其他家的CI/CD服务，相比之下我觉得阿里云Flow的流水线编排反馈就做的更胜一筹，“更方便”加一分。
意味着为用户提供正确的服务、流程、功能、组件、信息反馈乃至视觉效果，为的是提升产品的可理解与易用性，从而达到降低学习成本提升效用，减少跳失率或出错等负面情况。
嗯！花费那么多心思让产品体验变得更方便更准确就是为了提升用户的使用或付费意愿，算是任务路径优化设计的底层价值吧。
出于不同的行业差异，优化流程的细节可能有差异，但基本上可以通过五个阶段来概括；
在一套服务系统中，当用户反馈难用、麻烦、任务卡点、不如传统服务模式时，那就意味着有优化的空间，设法洞察问题、定位问题就可以开展工作了。
通常进行任务流程优化的目标基本上就是降本增效、解决卡点、体验升级，通常根据实际问题也会有更详细的优化目标用于执行推进。
出于问题与目标而进行的优化方案构思，这其中包含了优化策略、方案原型、版本兼容等问题，主要是为找到优化的好办法。
严谨些，设计者不能由个人主观认定方案一定可行，新的方案最好经过用户验证或量化测试来保障效果，并且测试验证的过程中遇到的新问题，也应该留意并放到持续改进中。
事实上这是一个不可避免的过程，原因有三：
所以分好优先级后慢慢改吧，也许随着业务发展变化，有些问题就不是问题了。就像网络段子一样，当初一个需求十分紧急，但是研发排期太满，半年后这个需求还在，看来这个需求也不是十分紧急嘛～
这里再补充两个近期在用或接触到的优化流程～～～～～～
PDSA是指“计划-实施-研究-行动（Plan-Do-Study-Act&Amend）”，属于一种精益方法，常用于衡量变更的有效性，部分企业的专有云解决方案架构师也叫做PDSA，并且有对应的平台组织。PDSA虽然不能很好帮助产品做创新或直接解决问题，但在流程优化解决的实施与验证管理方面是好手，这一方法的四个步骤分别如下：
而PDCA则是指“计划-实施-检查-行动（Plan-Do-Check-Act&Amend）”，检查主要就是验证效果是否有效，有效的则应用或标准化，没用的则继续改进，相比下，PDSA的内涵会更广泛些。
SDCA是指“标准化-执行-检查-总结（Standardization-Do-Check-Action&Adjustment）”，跟PDCA有些类似，主要差异在于第一步骤：
SDCA循环法的目标是实现持续改进，可以减少重复性问题再次发生、精简和标准化执行，形成可靠、准确、高效的结果，是一种结构化的迭代的方法，且适用领域广泛。
这里先放AI的答案：
看起来也没啥大毛病哈，那么接下来围绕下图的概念说说我认为的焦点。
通常完成一套服务的交付会涉及各种角色，那么就需要根据用户的特征或偏好提供差异化的服务与内容交互。一般需要人工操作的部分往往更容易出问题，通常借助用户研究、用户测试都能获取到一些有用的信息来指引任务链路优化。
即提供什么样的服务解决什么样的需求，之所以说服务体系是因为现在的产品很少通过单个或极少的服务来打造一个产品，这就意味着要对用户进行合理的分类管理，对标提供合适的服务与版本，减少不必要的服务或是混乱的服务带来的产品臃肿与任务链路混乱，例如招聘软件的招聘与应聘视角分离。
场景化或情景洞察一直是产品设计的重点，可以洞察到更多用户实际遇到或潜在的痛点，以及线上线下等环境带来的微小差异性，这对任务链路优化有很大帮助，作为焦点一定不为过，至于如何实践了，我们可以通过观察线下传统服务的过程，或是采用用户测试的方法进行观察与分析获取优化指引，哪里用户卡住了或是吐槽了那就表明有优化空间。
指在整个服务发起到结束过程中所经历的人群、设备、通信、内容、第三方服务等，就以哈罗单车的租赁过程为例，其中主要的核心媒介就包含了“用户、手机、应用、网络通信、商家服务器、自行车、付费服务”，那么以这些作为焦点有什么用呢？事实上一套完整的服务正是由这些媒介之间的不断交互，才使得哈罗的租赁服务可以如此灵活，所以在整个服务流程中让媒介之间更智能、自动、高效的完成衔接与交互，就成了必要的焦点了。
几乎进行任何服务都离不开特定的构成信息与交易，举个最简单的例子，晚上你来到街边摊，想要一份烤冷面，那么你除了要掏钱以外，你还要跟老板确认口味、加料、价格这些信息，这些就是构成任务进程的信息，这些信息可以通过问答式确认，也可以提供招牌信息给食客确认，总之将这些信息更简练准确的进行交互，就能实现任务链路的优化，在应用程序的交互设计中，常常表现为用正确的描述语、正确的交互组件、正确的视觉表达、正确的反馈等，事实上应用程序本身就是由各种各样的信息交织在一起所构成，所以“做任务链路优化不仅是减少操作步骤而已”。
本来是没有业务模型这一环的，但考虑到实际的业务场景中会有很多复杂的部分，常常盯着这些细小的部分往往容易一叶障目，而业务模型的优势就是鸟瞰全局，并以简单易懂的图像进行表达，这个过程可以让我们更好的理解业务的概念与边界，可以看到各种界面与交互媒介之外的业务本质，帮助我们在优化过程中清晰重点与方向，以达成结果为导向，避免在细枝末节上投入过剩或南辕北辙。
当有多个任务进程需要处理时，就可以参考此原则来优化任务操作的路径，有点先易后难的意思，当多个任务之间没有前后的依赖关系或限定要求时，那就先处理轻小快捷的事项，当用户已经完成部分事项后，剩余事项就更容易推进了。
当然也可以根据此原则将前置条件整合处理，这样在后续的任务路径中就可以减少相应的条件卡点，例如大量安卓应用第一次安装启动时就会向用户索要存储、录音、相机等基础权限，那么之后使用相关服务时，就不用触发授权窗口了，不过权限还是要遵循用户隐私政策法规哈。
就是将复杂的任务进行拆分，通过循序渐进的方式一点一点完成任务，这样可以减少任务达成的门槛，让用户更加专注，并且可以在过程中培养用户的意识，是任务链路优化的常见手段之一，也是游戏新手村屡试不爽的教学模式。
通过规划使多个任务事项穿插或并行开展，本质就是任务事项的拆分管理与资源规划协调，通过使更多事项同时或尽早进行，来加快任务目标达成，以效率来推动任务链路优化的目的。
在资源规划协调时，可以通过时间、状态两方面下手，重复的、自动的、久等的、卡点的可以考虑先行，然后再处理其他琐碎事项即可
即我们常说的用户分层，通过提供差异化的服务或任务路径来对应不同的用户群体，以减少无效或干扰的流程操作，例如常见的会员与普通用户就会享受到两种不同的服务体系。
通过科技技术的应用，可以为用户带来更多的便捷与新鲜感，特别是具备商业属性的技术，会更快地成熟与普及，然后影响到更多人的生活方式。这个过程可以概括为“科技-认知-应用-习惯-直觉”，就像现如今的扫码支付、人脸识别、指纹解锁一般，不仅在各种领域都有了应用，并且你一看到相关信息，直觉就会引导你该如何操作。
面对各种复杂的操作、选择、输入输出时，尽可能的枚举出选项或模板，这样用户操作会更规范也不容易困惑，对于那些用不了或有特殊含义的内容则通过样式、组件、提示等进行合理的约束，避免任务流程出错，也帮助用户识别与理解，例如报错信息就要约束用红色反馈，电话号输入就要约束为数值输入等。
一个老生常谈的方法，可以帮助我们深入问题和洞察底层含义，用法就是面对问题不断的追问为什么。
简单讲就是在解决或优化任务链路的时候，带上人物、目标、行为、环境、时间诸多因素综合性思考，形成一个更完善而真实的洞察环境，以帮助获取更多有价值的优化信息，此前有出过一期关于场景化思维的专栏文章，写的比较详细，有兴趣的可翻阅一下：通道: https://www.woshipm.com/pd/5588700.html
ESIA是企业流程优化中比较出名的方法，但也不仅限于企业流程优化，其核心理念就是减少流程中非增值活动，以及调整流程的核心增值活动。由消除-简化-整合-自动化（Eliminate-Simply-Integrate-Automate）四个步骤构成，在任务链路优化中也是一个不错的思路或策略。
是工业工程学中程序分析优化的四大原则，主要由取消-合并-调整顺序-简化（ Eliminate-Combine-Rearrange-Simplify）构成，此前在做一套代码流程优化过程中，此方法给我带来了不少帮助。
任务链路优化的思路或方法肯定还有诸多，这里不再列举了，实际上掌握或了解几条比较实用的就差不多了。
说完了以上内容后，再补一些常用的优化工具，当然了，主要是我个人常用或觉得实用的一些。
○思维导图：可以快速帮助我们对信息进行树结构化与逻辑整理，并且可以结合图文以及功能图标等来完成管理及计划，能够将业务或功能框架快速显现出来，是很好的辅助工具之一。
○矩阵表格：可以很方便的将信息进行罗列与比对分析，在一些信息介绍或数据分析时常常会用到。
○服务蓝图：可以将完整的服务过程绘制出来，能够包含人物角色、前后台关系、阶段过程、状态扭转、交互触点等。
○体验地图：可以将服务、目标、用户、交互、反馈进行阶段化整合分析，本身是挺好的工具，只是设计师作品集中的用点儿虚，但不影响自己拿来实用。
○泳道图：可以根据时序对流程进行可视化，可以很好的传达职能部门或是角色之间的交互过程，也可以细分交互媒介、服务终端等因素之间的关系。
○流程图：主要就是围绕一个事件的开始到结束过程的流程可视化，流程图可以系统化的梳理业务逻辑与交互链路，泳道图也仅是流程图的一种，相信大家都很熟悉了，就不过多赘述了。
○鱼骨图：是一种根因分析工具，有头有尾有分支，像鱼骨，常用于定位问题发生所导致的根因，也可以用来制定任务目标进程的管理。
○状态机：一种针对事件状态扭转关系的流程图，用于描述系统的状态和事件，以及事件引发系统在状态间的转换过程，有点像是一系列的if语句，在中后台的系统设计中常常会有需要梳理状态的情况发生。
○业务框架：业务框架主要是一种将业务过程和活动进行组织和分类的方法，具有较大的颗粒度与较强的全局性，常用于表达业务框架单元之间的组成与活动关系。而业务模型主要是指业务概念关系的可视化简图，前文的流程图、泳道图、状态机等等都可以是业务模型。
○交互自检：主要用于交互设计的查缺补漏跟避错，同时在交互链路自检的过程中是可以主动发现问题，并验证优化是否可行或合理。
○使用性测试：也叫做可用性测试，是对优化结果或Demo进行测试检验的过程，通过模拟真实的任务操作过程以达到洞察、探索、比较、效果验证等目的。
○A/B测试：常用于方案之间的效果比较或验证，通常都是借助工具引流获取一批真实用户的测试反馈，是一款真实有效的验证手段，不过方案之间的差异不宜过于悬殊。
○数据漏斗：像任务链路这种多线程或是节点较多的事件，单薄的点击率或转化率的作用是很有限的，这时候就需要在相关任务节点上布满更多的埋点，将用户流量与数据转化的情况用漏斗视图表现出来，然后就可以针对任务链路进行分析或比较了。
本次的分享更多是从系统设计本身出发，实际上人总是最不可控的因素，在整套任务链路优化的过程中，也可以多考虑人工部分的管理与培训优化，想象一下一家电商店铺，什么都还挺好的，结果你跑去咨询客服的时候，人家爱搭不理，你问一点他答一点，就是不一次说清楚，你能舒服吗？
写到这里已经几千字了，不打算找案例展开讲了，最后再为那些不爱看字的朋友们浓缩式总结一下。
等待少点引导多点，能一次说清楚的就不要云里雾里，能简短操作的就不要搞复杂，能给选项能给规范的就不要让用户瞎填，一次做不完的就分几批做，交互组件要匹配不要生搬硬套，能给自动方案的就不要让用户瞎折腾，能用先进实惠的智能技术就不要技术落伍了。
如果觉得写的还不错，期待点赞收藏或分享，我将再接再厉～
不定期更新，欢迎关注或评论区留言，下期见！
专栏作家
泡泡，人人都是产品经理专栏作家。专注产品交互领域的体验设计师，擅长思考和UI呈现设计，喜爱交流探讨～
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Pixabay，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。