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