|
该图片由Public Co在Pixabay上发布 这是一篇比较形而上学的总结，来源于我曾就职的一家公司内部的分享，分享的原主题是“设计分析与实现的思想框架”。由于我个人的能力以及实践经历无法就这个主题做出足够客观与丰富的总结，于是我根据这些年来自身的工作经历结合这个分享会的一些记录重新思考做了整理。 一、本质不论是互联网软件、硬件或是日常生活遇到的各种问题，都是为了人实现某一目标而产生的。所以在设计功能、解决方案之时，我们聚焦的都是人。 多数人为了逃避真正的思考，可以做任何事。 这句话是用户在使用各类产品以及执行各种解决方案时的行为总结，其核心在于用户在使用产品时不愿意做过多的思考，所以产品的功能流程需要简单到无需思考的程度。这更多是一种理想化的目标，实际上在实践过程中我们要做的是尽可能了解需要解决的问题核心，然后根据使用者的预期来尽可能地将解决方案设计得简单。 为了帮助用户“逃避真正的思考”，我们需要探寻问题的本质。第一性原理表达了追求事物的本质这个思想，思考本质有助于我们了解问题的核心，真正的了解了问题，才能更有效的帮助用户“逃避真正的思考”。 二、探寻本质之前的描述比较抽象，但是核心在于“知己知彼，百战不殆”。只有对问题了解到核心本质的程度，才能客观有效的指导我们的行为，但是谈何容易。 西蒙斯涅克先生发表过一个黄金思维圈的概念备受各界推崇，这的确是一个非常有用且实用的思考方法。这也正是帮助我们探寻问题本质的重要方法。 那么，先让我们看一个故事。老板对我说，我们的平台有设计账号与登录系统，一个合作方的游戏想要接入我们的服务，但是他们也有自己的账号与登录系统，现在双方冲突了，要解决这个问题。 甲说，可否劝他们放弃自己的系统，接入我们的登录流程。 乙说，可否我们针对他的游戏，屏蔽我们的登录流程，供他们接入。 丙说，为什么他们不能放弃自己的登录流程，转而接入我们的系统。 这三个人的发问，代表了两种思考方式。甲乙想的是针对遇到的问题开始摸索解决方案，丙从问题开始思考为什么会存在这种情况。于是讨论开始聚焦到先解答丙提出的为什么。 因为对方的账号系统与我方的虽然相似，但是数据结构不同，如果他们的游戏刚开发可以接入我们的服务，但是他们已上线很久，此时修改代价太大，所以问题的核心就是要解决，不使用我们的登录服务，我方是否还能给对方提供完整的服务，如果不行我们要如何配合对方。 接下去就是针对这个新的问题开始讨论，从而得出解决方案的思路，即我们提供无需接入我方登录流程，但需要对方返回用户ID等重要信息的方式，供对方接入，同时我们需要针对这个常见问题提供一套无需强制接入我方登录流程的备用方案。 其实这个讨论的流程就是黄金思维圈所介绍的思路，从WHY到HOW，再到WHAT，即从为什么开始提问，通过不同的为什么来不断探寻问题和核心，用发散的为什么来探寻问题是否接近核心。当把发散的为什么整理出脉络后，开始讨论怎么做，从而确认我们要做什么，进而确认我们是否解决了这个问题。 从这个问题的讨论可以看到，问题的本质是我方的服务不够灵活，过度依赖合作方的配合，在配合合作方的方面不够周到。少了探寻为什么的这个步骤，也许也可以解决问题，但是建立在些许运气之上。如果一个问题有更好的解决方案，或是问题本身就不是核心所在，需要解决是更为深层次的方面，这次方案仅仅是一次脚痛医脚的行为。
这里使用的黄金思维圈图示与常见的顺序不相同，原因在于从问题的思考流程中从问为什么起步，逐步从发散到聚焦到要做什么，进而确认问题是什么从而确认结果，从行为模式而言是一个思维聚焦的过程。 这个思考过程最核心的地方在于提问为什么时，需要足够发散，根据足够丰富的为什么来整理脉络，厘清问题所在，有助于帮助策划者发现问题核心，进而发现本质。 三、问题的分析通过黄金思维圈对问题的分析，我们得到了解决问题的方案思路。在执行方案的过程中，重点在于多问为什么与问题相关的其他信息，尽可能地发现其中的秘密。当我们经过思考得到了解决方案，此时从解决问题的角度而言，并未结束。 如何判断问题是否解决呢？ 就前例配合合作方游戏接入我方服务而言，这个问题的判断依据是对方可以在放弃我方登录流程的基础上使用我方的服务。针对这个预期结果，在执行具体的解决方案前，我们还需要分析几个问题。
现在我们有了解决方案，还需要去评估能力与缺乏感。 能力，即用户付出的成本。如果一个解决方案可以解决问题，但是需要用户付出较大的成本或是比之前更高的成本，此时成本与收益不平衡，收益小于预期时，也许解决方案就依然未触及核心与本质。 缺乏感，即理想与现实的差距。我们的预期与最终结果是否一致，如果不一致这其中的差距能否保证解决方案实施后有效，如果效果不满意则有可能是在问题的分析的某个环节中遗漏了关键信息。 当然以上都还是解决方案实施前的预演，如果预演阶段就能发现明显问题，那么就已经能证明我们对问题的了解还不够。足够的“纸上谈兵”是为了后续的结果尽可能接近预期。 那么我们总结了解决方案，做了能力分析，做了缺乏感的评估。 然后呢？我要怎么做？ 四、验证并分析结果其实以上的分析与思考，就是问题解决方案实施前的准备过程了。那么在此整理一下。 1. 整理好用户故事 用户故事，通过描述一个用户如何使用解决方案来解决问题，阐述了用户与解决方案之间的联系。这里需要明确的是用户是谁，提取出他们的核心信息，归类抽象成一个具体可描述的群体。 一个故事中，除了用户这个主角，还需要明确主角在何地、何时发生了怎样的故事。这时候经典的5W2H法可以很有效的帮助我们整理构建这个故事。通过明确什么事（WHAT），因何产生这件事（WHY），由谁产生或参与（WHO），在何时发生这件事（WHEN）、在何地发生这件事（WHERE）、如何解决（HOW）以及所耗成本（HOW MUCH）几个问题，来预演模拟主角将如何演绎这个故事，发现故事中的疑惑，通过黄金思维圈的思路，从不断地为什么开始发问，逐步明确问题脉络，进而厘清故事，从而构建出一个故事，此时解决方案的思路就显现了。 2. 使用场景 问题的解决方案很多时候并不具有普适性，解决方案只能在问题的限定条件下方可产生效果。明确解决方案的使用场景，帮助我们明确问题与解决方案的限制与范围，避免陷入不断解决衍生问题的问题。 此时在明确了用户故事以及使用场景之时，需要客观的对能力进行分析，如果用户付出的成本过高，需要高度关注，之前的问题分析是不是存在缺陷没有解决。 3. 设计需求 在前两个环节的基础上，对解决方案的内容进行系统的完善，根据背景、目的、使用者、使用者执行解决方案的行为来明确需求满足了解决方案的要求。 4. 设计内容 这里的内容包含了具体的需求方案，对于方案结果的验证评估标准。 很多时候，我们做一件事是很难评估其价值的，这个价值指的是如何通过具体的指标数值来体现。毕竟没有具体的数字来体现，光靠内容交流，难免产生互相的不理解与不信任。没有具体的标准与要求，宽泛的说明难以体现结果的价值。 我所建议的方式是一个思路，当我们执行了解决方案暂时还无法确认结果评估目标时，可以先行执行，此时在问题解决过程中会产生现象，因为现象会导致原有的一些数据发生变化，其中变化显著的指标就可以初步作为本次解决方案或者行为的质量评估指标。 可以通过以上方式多次验证修正。这个思路的原理是当执行了一些行为后，一些被显著性影响的因素会发生变化。我们可以通过不断的找到变化的指标，顺藤摸瓜的找到相关联的重要指标，更深入的确认效果。 以我自身经历为例。曾经我们优化了我们的微信小游戏SDK包大小，供合作方接入，因为包体大小减小以后，我们的预期是会减少用户在冷启动后资源加载阶段的用户流失。如何来定义本次行为的质量呢？如果仅从减少了启动阶段的用户流失这个概念来评估，就需要更加具体的指标。此时我们观察了用户使用时长分布、新用户留存率以及人均使用时长，其中在使用市场分布中访问10秒内的用户显著减少，留存率变化不大，人均使用时长有提升，此时我们便重点关注使用时长分布，人均使用时长是否有提升，以此来评估本次SDK包体优化的效果。 当然这仅仅是一个提供参考的思路，验证评估标准是作为工作结果的体现供检查的，同时也需要有严格验证标准来检验每次的问题解决是否到位。 五、最后的碎碎念以上是我自己根据分享会的记录结合自己的工作进行了一些实践总结。并没有什么高端的方法，构建这个思考分析的流程也走过弯路，最后还是要感叹一句做好每件小事是很重要的。我一直觉得每个人都应该构建属于自己的思考方式与行为评估标准，同时不断的改进提升方式与标准。文末分享一个我参考上级分享的产品需求文档改进后的模板，借此对本文做一个总结。 模板的思路与本文类似，通过提供给开发者或是解决方案的策划者、执行者以及创造者阅读，帮助他们了解本次要做的事，从使用者到其在何种情况下使用产生怎样的效果进行介绍，让不同角色的人进行思考，收集更多的为什么。 当开发人员获取到这些信息并产生疑问提出为什么时，也许就能帮助你进行完善做得更好。 最后想分享一个我曾经的故事。彼时我接到一个网页设计的任务，我设计完以后就提交到设计与开发部，开发部门的同事看了我的方案以后，问我这个网页是做什么的，主要面向哪些用户，为什么模块如此设计，当我一一回答问题以后对方提出了非常多不错的建议，我深深的感到自己的不足，并在他的建议与协调下暂停了界面设计，重新开始整理完善设计。 这是一次很友好的交流过程，除了自身的思考分析以外，其他人对我的帮助也很有效地提升了项目的完成质量。不论是设计软件还是硬件，除了解决方案的不同，对于问题的思考方式和分析，都来源于分析者自己，所以本文也是我对生活的一次反思。 鉴于本文是对问题分析的总结，心态与态度方面便不多赘述。在此还要感谢当初的分享者，没有你，也就没有我这篇总结了。 祝朋友们生活愉快。 模板如下。 （一）需求背景及价值（描述本次需求为什么要做的原因以及背景） 1. XX在推广中需要区别于市场中且具有两点的特色功能，ABtest是目前小程序平台中暂时没有的功能。 2. 在游戏产品调优的过程中，ABtest可以快速验证帮助策划人员获取反馈。 （二）需求目标（描述要完成的具体目标是什么） 1. 完成ABtest配置后台与数据展示后台 2. 完成ABtest第一版需要开发的指标 （三）关键场景描述（介绍谁做了什么达到了什么效果，并根据重要性分等级供开发人员了解需求开发优先级） 1. 自研团队的策划可以使用ABtest快速验证不同交叉推广的效果，在短时间内迭代上线，实现效益的提升（P0） （四）需求描述（详细描述需要做的事，使用流程图等辅助图介绍功能流程） 详细的需求描述 | 
每日抽签
收藏
转播
淘帖
