如何玩转B端产品设计的“参与感”
“参与感”一词常常出现在C端产品的用户运营领域,主要指围绕用户思维来设计一系列互动行为,实现以用户增长为主的目标。与其相比,这个重要的关键词在B端产品领域内的出现频率却是寥寥。
为什么认为它重要呢?实质上,“参与感”是人(用户和研发者)与产品的一种情感的连结,它往往也决定了一个人的问题思考视角。加强参与感,即由原本第三人称视角转换为第一人称视角,更好的实现个人价值在项目中的最大化。接下来,笔者将结合自身项目经验分别从三个方面阐述参与感的重要性,以及它缺失时会导致的问题,希望能提供各位设计师一些新的思考切入角度。
✨
用户的参与感
“如果不换工作,这些工具我应该会一直用下去吧。”这句话来自某大厂的用研记录,也是反映了目前许多B端产品的用户现状。在企业中,用户已经习惯于被动的去学习既有工作流程和需要使用的工具,难以主动的去反馈和发现问题。作为B端设计师,对于提升用户参与感的本质更多的是指通过加强互动去洞察用户行为背后的心理活动,替沉默的用户发声。
让用户介入更多的研发环节
在产品研发流程中接触用户最多的环节集中在用户研究与测试上,通常适用的场景包括了:新的产品领域、复杂流程功能、重大升级改版、设计方案有争议等;用户测试的类型和手法多样,从覆盖面和周期来看特性各不相同。如果将覆盖面较广的数据埋点与季度性的用户访谈与可用性测试、大版本的bugbash结合起来,可以为产品构建一个比较完善的用户研究体系。
另外,从整个研发的流程来看,让用户参与可以形成一个良好的上升螺旋。比如前置的用户研究环节能够帮助检验业务需求/逻辑的真伪性,设计阶段的用研能为设计环节提供良性依据,产品上线后的用研通过数据的收集检验目标是否达标,为后续优化提供方向指导和经验沉淀。
让用户介入参与决策与反馈
✨
设计师的参与感
通常来说,设计都处于项目流程中的需求下游环节,属于辅助求概念方案落地的执行层面。但如果设计师在团队中角色的仅仅只是被看成“资源”,缺乏参与感,会带来很多的问题。
对功能点的影响面进行系统性检查,查漏补缺; 考虑边缘场景,完善覆盖范围; 结合功能点的上下游,查看是否形成了业务闭环;
有明确的数据指标的好处在于,结果导向性明确,不被业务需求牵着鼻子走。这些都能够帮助设计师在团队内建立起信任感,慢慢扩大设计的话语权和影响力。
✨
团队成员的参与感
任何一款好的产品背后必定离不开一个优秀的团队,除了用户的体验外,研发团队的协作效率和成员状态也需要获得关注。组成团队的成员往往职能多样、诉求不一,看似简单完美的设计方案与优秀的技术方案并不能完全相等。对于一头扎入业务的工作日常,也会导致成员对交付物为产品带去的价值知之甚少的不良现象。
一方面,设计师可以协助团队建立一致性的目标,加强团队凝聚力。多尝试组织和邀请团队参与产品目标共建的活动,可以帮助他们跨出个人的任务外,站在全局的高度看到产品的方向。其中,采用解决方案启发式的沟通方式、前置考虑技术投入产出比,能更好的权衡用户、体验与技术间的关系。
另一方面,尝试让他们变成使用者,降低沟通成本。与前文所述的“同理心”一样,若能协助团队成员尝试扮演为(或转化为)自身产品的使用者可以很大程度的加强共情感。这意味着更加直接的审视产品,调动个人积极性,让他们主动参与进来去推动一些有价值的尝试。
当然,为了让这件事更顺畅,我们也需要降低沟通协作上的门槛。例如,观察分析目前团队研发环节是否有评审、走查环节的缺失,信息沟通不畅等问题的出现。
推动流程的合理性,沉淀工具去提升工作效率,如业务组件库搭建、design token的使用、需求/用研模板制作等,用设计的思维去提升团队成员的合作体验。
✨
后言
虽然不像C端产品那样直接面向消费者,但企业类产品的宗旨仍旧为了能够更好的服务于“人”。作为设计师而言,与人的沟通占据了日常工作中很大部分的时间,更好调动个人、团队主观能动性,推动资源去做正确的事这个能力显得尤其重要。除了对日常工作的复盘外,也需要抽出时间来思考优化做事的方式。希望本文关于怎样多维提升“参与感”的视角能够给大家一些灵感,用设计思维让B端产品更有活力。
撰文 ✎ 冯韵
图片 ✎ 自绘
未 经 允 许 请 勿 转 载 到 其 他 公 众 号
在 首 页 输 入 关 键 词 转 载 获 得 授 权
···········································