如何玩转B端产品设计的“参与感”.docx

第PAGE\*MERGEFORMAT5页共NUMPAGES\*MERGEFORMAT5页

如何玩转B端产品设计的“参与感”

“参与感”一词常常出现在C端产品的用户运营领域，主要指围绕用户思维来设计一系列互动行为，实现以用户增长为主的目标。与其相比，这个重要的关键词在B端产品领域内的出现频率却是寥寥。为什么认为它重要呢？实质上，“参与感”是人（用户和研发者）与产品的一种情感的连结，它往往也决定了一个人的问题思考视角。加强参与感，即由原本第三人称视角转换为第一人称视角，更好的实现个人价值在项目中的最大化。接下来，笔者将结合自身项目经验分别从三个方面阐述参与感的重要性，以及它缺失时会导致的问题，希望能提供各位设计师一些新的思考切入角度。用户的参与感“如果不换工作，这些工具我应该会一直用下去吧。”这句话来自某大厂的用研记录，也是反映了目前许多B端产品的用户现状。在企业中，用户已经习惯于被动的去学习既有工作流程和需要使用的工具，难以主动的去反馈和发现问题。作为B端设计师，对于提升用户参与感的本质更多的是指通过加强互动去洞察用户行为背后的心理活动，替沉默的用户发声。让用户介入更多的研发环节在产品研发流程中接触用户最多的环节集中在用户研究与测试上，通常适用的场景包括了：新的产品领域、复杂流程功能、重大升级改版、设计方案有争议等；用户测试的类型和手法多样，从覆盖面和周期来看特性各不相同。如果将覆盖面较广的数据埋点与季度性的用户访谈与可用性测试、大版本的bugbash结合起来，可以为产品构建一个比较完善的用户研究体系。另外，从整个研发的流程来看，让用户参与可以形成一个良好的上升螺旋。比如前置的用户研究环节能够帮助检验业务需求/逻辑的真伪性，设计阶段的用研能为设计环节提供良性依据，产品上线后的用研通过数据的收集检验目标是否达标，为后续优化提供方向指导和经验沉淀。让用户介入参与决策与反馈让用户参与到产品的发展计划中有个很容易犯的错误：用户会直接告诉你需要的功能或者提出一个解决方案。这不但不会帮助我们从根本上做出创新，还会阻挡发现用户真正想要的是什么。例如，笔者参与研发的平台用户曾基于已有的发布模式提出了便捷创建关联信息功能，但实际上深层原因源于当前的发布模式已不适应于团队当下状态，平台需要去探索新的发布模式来进行优化和匹配。因此在收集用户需求反馈时，正确的描述应该需要包含的因素有：场景描述+期望目标，如此可以由表入里了解用户核心诉求，衍生出更多样、覆盖面更广的设计方案。另外，在进行需求优先级评估时，除了“决定是否使用”性质的功能外，需要从产品设计的角度思考评估：当前用户所提需求是否存在通用解决方案，如果只是非常深的业务场景，那可复用性就很低，相应的要考虑是否能够通过设计方案降低开发的成本。如果这个解决方案的提供对产品来说只是功能的堆砌而非能力的增益，最好再多思考一下是否值得投入资源去做。设计师的参与感通常来说，设计都处于项目流程中的需求下游环节，属于辅助求概念方案落地的执行层面。但如果设计师在团队中角色的仅仅只是被看成“资源”，缺乏参与感，会带来很多的问题。首先，产品的用户体验问题优先级低，没有话语权。尤其对于拥有付费用户的企业产品来说，面对不断的要求新增功能，设计师很难说服决策人投入资源来提升用户体验，开发计划的重心通常会与功能优化偏离。其次，被动接受沟通，影响设计方案有效性。当需求来源是非一线用户提出或未经过专业产品逻辑梳理的“一句话需求”，设计师通常需要对概念进行再加工。无论是理解上的偏差还是因变更、滞后发生信息失真的情况，都会影响输出的方案的质量与进度。怎样才能改善这个现状呢？贴近用户，在与用户的切磋中共同成长。对许多B端产品而言，“从业务需求走向真实产品”这件说起来简单的事情，实际上是业务功能简单堆砌到用产品化思维寻找通用化解决方案的思维转变。在这个过程中对设计师有个比较大的挑战：如何与职业属性相距甚远的用户建立同理心？虽然说我们都知道在为企业员工做设计时，宗旨围绕“帮助用户专注于更好的完成工作”，关注他们的角色权限、工作流程，但也需要跳出产品的框架去多了解用户的职业价值诉求。现状的症结点在哪？是否存在更大的优化或创新空间？反而是一些隐型的、间接性的收益可以帮助他们跳跃性的快速发展。加强沟通理解能力。在需求沟通到方案产出阶段，对设计师来说需要不断深入业务、梳理其中错综复杂的关系。需要考虑的因素包括：对功能点的影响面进行系统性检查，查漏补缺；考虑边缘场景，完善覆盖范围；结合功能点的上下游，查看是否形成了业务闭环；增强设计影响力。不定期的在项目团队内开展用户体验相关主题分享，帮助他们树立“好的用户体验”不仅仅是设计团队任务的思维，定期清理体验优化池的机制；建立可量化的指标，在可控的时间段开始做优化，并使用指标来检测优化取得