文章采集平台( 这是关于B端产品设计体系化设计的第二篇文章(组图))
优采云 发布时间: 2021-09-08 18:03文章采集平台(
这是关于B端产品设计体系化设计的第二篇文章(组图))
这是B端产品设计系统设计的第二篇文章
全文也是9000字左右,阅读时间约20分钟
阅读前了解:
1.文章在设计主题的研究范畴有点学术,所以读起来可能有点晦涩。
2.关于这个设计主题(B端产品用户反馈系统的建立),文章的内容主要来源于公司内部的一个项目级用户调查相关的设计主题研究,试图将相关分散的设计点进行系统化和结构化。
3. 从宏观上来说,反馈系统也是一个很大的设计命题。毕竟,当用户在产品中进行一些业务操作时,他们总是与系统进行双向反馈,形成一个封闭的沟通回路。同一篇文章“B端用户反馈系统”的核心论证做了必要的约束和权衡,重点关注双方明确产生反馈的机制。
4.文章中涉及的一些点可能可以写成独立的文章,所以有些点可能涉及的不深,看以后有没有机会再深入补充。
5. B端用户反馈系统的用户研究部分,对专业的用户研究技术有深刻的理解。作为设计师,不需要追求极致的专业,可以整合广义的用户研究思维。当然在产品设计的过程中,接一些订单还是可以独立写文章的。
6. 与上一篇文章不同,B端用户帮助系统的建立,对于B端用户反馈系统,采用的设计方法会和C端有很大的不同,而且最终反馈的信息维度比C端少,但背后的设计模式大致相似。
7.文章 一定有不足和未考虑的地方,还望指正。同时,感兴趣的朋友可以一起讨论这个设计话题。
8.最后希望有缘看到这个文章了解这方面产品设计知识的朋友有一定的启示和帮助。
9.有意转载请直接加作者微信
对于 B 端产品来说,闭门造车是一件可怕的事情。直接拍头打屁股的做法,会让产品在竞品相近的B端市场难以生存。
在实际的产品体验中,用户和系统通过界面的交互操作和视觉呈现不断进行交流。作为系统背后的产品设计师,如何与用户保持有效的双向反馈,以及如何对用户反馈做出系统的回应,是本次文章讨论的重点。
01 文章结构
文章结构按照以下结构详细描述【用户反馈的采集方法-B端用户&平台反馈系统-平台内的用户反馈机制-用户反馈的设计形式-用户反馈机制平台外]。
首先要清楚:
反馈的前提是沟通,沟通是一个双向的过程。为了通过沟通得到有效的反馈,产品设计师的核心力量需要在两个方面,如何采集用户反馈和如何回应用户。及时响应反馈,如何使用有效的设计方法让用户-设计师形成机制闭环,并有动力让这个机制持续运行,文章基于这些点,从产品设计的角度,讨论系统化如何构建B端产品的用户(和设计者)相互反馈的机制,间接解决如何有效衡量设计变更对产品和用户的影响的问题。
如果您作为设计师声称对用户使用产品的体验负责,那么采集用户对产品体验的反馈并积极优化体验是设计师的责任。
面向用户的产品不是一个自我修复系统。只有用户参与其中,将体验反馈给产品设计师,同时产品设计师依靠用户反馈不断改进产品,才能体现产品设计的价值。
用户反馈系统的建立可以理解为采用利益相关者共同参与的共建模式,寻求用户和产品所有相关人员的参与,让产品在话语权中健康成长批评和表扬。
如今,设计的量化标准越来越受到重视。无论是过程导向还是结果导向,商业层面的设计方案审核,其实就是跟踪一些可量化的用户行为数据指标,建立B端用户反馈系统的目的也是为了尝试通过一个相对完整的闭环来衡量整个产品的可用性和易用性。
按照分类的第一维度,B端产品的用户反馈系统可以分为实时反馈和非实时反馈。
实时反馈一般涉及用户帮助系统中的客服支持系统。它采用问答(会话式)的形式来获取并帮助解决用户遇到的问题。通常这种类型的沟通大部分时间都花在处理用户琐碎的需求层面,很难沉淀出可以应用到产品功能层面的用户需求。
非实时反馈通常具有显着的时差。通常体现在产品层面的设计形式作为桥梁连接。它主要接收用户的反馈。来自产品设计师的反馈通常是在信息过滤中,优先考虑给用户端。这种反馈模式对于系统地采集用户侧需求,提取更好的解决方案具有较大的参考价值。非实时反馈的设计模式也是此次文章讨论的重点。
02 采集用户反馈的方法
对于B端产品,一般有两种方式采集用户反馈:
这两种形式是B端用户通信系统的核心组成部分。前者广泛采集现象,后者寻找具体原因,从现象(如何)到原因(为什么)相辅相成。
03 B端用户&平台反馈系统
用户通过平台内的用户反馈机制向平台传达自己的感受和建议。同时,平台有及时的假反馈机制,由平台采集,产品设计师处理,再通过平台将处理结果传递给用户(真反馈机制)。为了采集深入的用户反馈,产品设计师通过平台外的用户反馈机制进行用户研究。整理分析后,通过平台或第三方工具将处理结果传达给用户。
对于设计师来说,对于用户反馈系统的建立,经过验证和理想的设计研究流程如下:
第一步是确定你要采集的反馈,即研究目标是什么,是否需要通过用户反馈、定期用户满意度调查、补救问题解决研究来验证设计方案的合理性,或前瞻性的性问题挖掘等
第二步是构建合适的用户反馈机制,即研究方法是什么,是使用平台上的用户反馈机制,还是平台外的用户反馈机制,还是两者结合。需要说明的是,在整个设计和研究过程中,用户反馈机制不是一成不变的,可以随着整个研究的进展而进行调整。
第三步是进行反馈采集阶段,即研究和实施。
第四步,在有用户反馈数据后,对数据进行整理筛选分析,筛选出对产品功能体验提升有参考意义的信息。
第五步,将现有的反馈范围与原研究目标设定的范围进行比较,考虑是否增加新的交流形式,深化现有用户的反馈,直到得到想要的甚至超出原计划预期结果。
04 平台内用户反馈机制
平台用户触发的反馈机制:
用户主动触发的反馈机制会在用户使用产品的整个过程中持续存在,通常表现为一个不干扰用户当前业务流程的永久性小入口。通常这种机制需要有比较成熟的用户激励机制来实现,否则很难带动用户自发反馈。
平台系统主动激活的反馈机制:
平台主动激活的反馈机制通常以产品设计师的目标为目标,主动接近用户,在用户功能生命周期的各个阶段及时获取用户的反馈。一般来说,其背后有一个相对完整的预设计研究策略。 (细分用户群体和用户行为)作为支撑,这种反馈机制由平台根据已经设置的后台判断来激活。一旦激活,用户的行为过程就有被打断的风险,所以在前端设计中体现出来的表单应该收录忽略和删除的选项。
用户对产品的瞬间态度是转瞬即逝的,平台发起的反馈机制的适当应用(包括合适的场景、合适的时机、合适的设计形式)可以很好的表达出平台想要解决用户在同时,通过用户反馈——发现问题——排查问题——解决问题——平台反馈的良性闭环,实现用户与产品设计师的有效沟通。
当然,两者有效运作的核心还需要产品设计师提供引导和鼓励用户反馈的设计模式。
平台系统主动激活的反馈机制:
和C端产品有区别。将B端产品引入平台,由用户反馈机制自发激活的系统是直接获取终端用户实时态度和情绪的唯一途径。
B端产品大多是基于管理平台的系统,管理只是反自然、反人类。如何在使用产品时直接获取用户的“情感快照”,是B端设计师需要时刻关注的问题,但常规的调研方式,如用户访谈、用户调查等,其实效果并不好。
平台中的反馈采集场景实际上伴随着整个用户功能生命周期,也就是说,很有可能是当用户在某个工作流中,有明确的用户目标时,平台会要求用户提供一些反馈,过程中难免会被打断,产生或多或少的负面情绪。如何让用户保持相对积极的产品体验,并提供一些真实的反馈,也是产品体验设计师需要思考的问题。
平台中反馈机制的使用场景可以针对特定功能、特定流程、特定用户或整体产品评价,例如新功能的初始体验反馈、现有功能的整体体验反馈等,或对于首次使用本功能的用户,对于使用本产品三个月的用户等,具体应用场景可以结合之前的研究目标,以及想要获取的用户数据的具体范围。
平台内反馈机制的具体设计形式:
对于平台内反馈机制的建立,设计形式具体表现为在UI层面对各种用户反馈组件的单独或组合使用。
常见的形式有:选择类型:二元选择类型、等级量表类型(打分)、选择题类型、输入类型:富文本类型、多信息载体类型、授权类型:同意解释类型。
选择性反馈:
说明:选择性反馈表由系统实现,并安排了多个选项供用户选择。它通常出现在函数或操作过程的最后一个节点或使用结束之后
双选:
是最简单的定性用户评价形式,提供双重选择(通常是正面情绪和负面情绪两个对立的选项),就像投票、赞同或不赞同可以直接表达用户当时的情况体验情绪。
级别比例:
一般用星级来展示,或者为了突出产品与用户之间的情感联系,可以采用更图形化的展示形式,比如引入emoji或者结合IP的展示形式图片。或者采用一种简单粗暴的纯数字评级形式,具有更大的数字灵活性。
这里需要注意的一点是,反馈机制中的评分量表与 NPS(净推荐值)之间存在差异。前者一般以非零数字开头,而NPS收录0的选项。
当您需要了解用户的满意度、易用性、好感度、流畅度、有用性等可以衡量产品在产品体验中表现的指标时,可以使用评分量表的设计形式。
选择题类型:
系统预先提供了一个问题列表,用户可以自由选择。用户可根据实际遇到的问题进行选择。问题需要基于用户当前的用户流程和功能操作,不要提供太多选项。
输入类型反馈:
注意:输入反馈表要求用户主动输入信息,通常是在一个功能流程明确结束后
富文本样式:
由于要求用户主动输入当前情况下遇到的问题的一些详细信息,这种形式的反馈对用户来说具有挑战性。当然,你可以尝试结合一些形式的视觉用户激励。 (如指导性的视觉表达形式)
多信息载体类型:
也可以是一种视觉反馈的形式,用更直观的多媒体形式,如截图、视频等,来反映用户在产品体验中遇到的问题。通常这种类型的反馈会改进错误、系统错误和接口。布局的优化帮助很大。
授权反馈:
注意:授权反馈表通常涉及用户数据和用户隐私相关信息的显示,通常出现在用户第一次进入特定功能界面或驻留在系统配置中。
同意描述:
授权同意解释型需要详细解释系统与用户的数据交互和权利义务说明,以便用户选择是否参与系统体验提升计划,让用户了解他们自己的反馈(主动)将用于什么反馈以及系统主动采集的内容。
平台中反馈机制的一般设计模式:
结合具体的使用场景,从组件到设计模式,下面会讲几个具体的设计模式的应用。
有针对性的反馈:
我们希望有针对性地采集用户对特定功能或特定流程的反馈,通常采用内置模块的形式。
主要目的是获取用户与特定功能交互后的瞬时姿态。这种用户反馈的设计模式需要出现在这个功能模块的相邻区域(同时,布局通常采用卡片模块布局的形式)。更常见的是调查当前页面上提供的信息是否有助于用户在这方面的行为目标。一旦用户完成了平台希望采集到达的用户反馈,可立即关闭当前的反馈机制,平台也应及时发送感谢用户留言。
总体反馈:
我们希望采集用户对产品某个整体功能或流程体验的反馈。通常有三种形式:侧面板形式、全局弹出形式、新建页面形式。
主要目的是获取用户对完成的功能流程的整体态度和感受,为用户提供一个自由发表意见的入口。处理完成后,此类用户反馈设计模式将出现在当前页面上。通常,将提供有关用户体验的更详细的问题列表。同时,一旦用户完成反馈,可立即关闭反馈机制,平台也会及时传达感谢用户或鼓励用户的信息。
综合反馈:
希望能从用户端采集对产品的综合评价(如NPS),其设计模式也可以采用:侧面板形式、全局弹出形式、新页面形式
目的是获取用户对平台提供的服务的综合态度。它通常是一个综合的问题评分表。同时,它会通过一个可视化的设计形式来吸引用户的注意力,所以需要注意的是,这种类型的设计模式通常需要在一个明确完成的流程之后出现,以确保用户已经离开了之前的任务流程。用户反馈所需的详细程度取决于设计者想要获取的信息的粒度。
当然,由于以上三种模式都是平台发起的用户反馈机制,肯定会干扰用户的正常使用过程,所以一定要针对一些高设计研究价值(高重要性和高影响)功能/模块/流程进行放置,同时选择合适的时间,通常是用户完成一个任务或最后一个任务节点,或者预测再次启动流程的起点。
如何在平台内建立有效的用户反馈机制?
从设计目标出发,选择合适的用户反馈组件,并以合适的设计模式进行展示。同时,具体的反馈内容需要经过深思熟虑的设计策略来支持。比如用户群划分策略、内容编写策略、采集周期策略等(所以这里定义的设计策略其实已经涉及到设计的具体细节,请先点击这里)
05 反馈用户的设计风格
在平台上采集用户反馈后,通过排序、归类、过滤等一系列操作,通常会得到一些对现象的局部评价式描述。这时候就需要借助平台外的用户反馈机制,探寻现象背后的原因了。
同时,对于一些可以通过一些沟通渠道直接定性反馈给用户端的结论,平台内反馈用户或者平台外反馈用户,目的是为了增加用户的产品参与感并鼓励用户再次反馈。打造健康可持续的用户闭环平台沟通。
反馈平台用户:
对平台内用户的反馈,感谢用户在使用产品时的参与和反馈。
常用的形式,如内置邮件系统、消息通知系统等,可以作为用户通信系统的分支系统——在平台内建立消息通知系统,以达到更好的效果经验,通常需要一个比较完整的设计策略,就是反馈强度和提醒分类的合理设置。 (详情会在另一个系列文章中解释)。
同时涉及到伪反馈机制和真反馈机制的设置。前者会通过通用的设计模式及时通知用户,感谢用户的反馈,后者一般都有时差,会结合具体的反馈来表达对用户的反馈。向用户提供其产品的后续操作。
平台外用户反馈:
向平台外用户反馈,通过邮件、短信通知、电话回访等沟通渠道表达对用户的感谢。
当然,如果产品是外部SaaS平台,为了表明产品设计团队对用户反馈的高度重视,甚至可以在产品或官网开设专门的用户反馈版块,这样用户可以更强烈地感知到他们的共同点。在产品层面建立一种参与感。
通过平台内的用户反馈,可以采集用户对当前产品现象的态度和情感反馈,但这些数据会比较粗粒度。如果要深入挖掘这些现象背后的原因,B端用户交流系统中的大头对于搭建平台外的用户研究机制,确保有效运行起到了非常关键的作用。
06 平台外用户反馈机制
以下将重点介绍平台外的用户反馈,即常规意义上的B端用户研究方法。这些用户研究方法就像深入的用户反馈机制。对于B端产品,研究通常是明确目的,产品体验有问题想改进,产品体验也可以想探索新的机会,等等。特别是对于大中型的B端复杂业务系统,功能模块和分支流程的调查是很常见的。
相比C端丰富的研究方法,在实际的企业环境中,最适合B端产品的设计研究方法其实集中在几个定性研究方法上:用户访谈和可用性测试、情境调查( contextual Observation and communication),当然不限于此,也可以使用一些辅助的定量用户研究方法,对结果进行一些验证性调查。
设计师发起的用户研究:
虽然设计师发起的用户研究和产品发起的用户研究有一定的区别,但核心点是指导产品设计的过程。设计师与用户直接交流,可以获得更丰富的第一手资料。而不是一些经过处理的二手或三手数据。
对于 B 端设计师来说,用户研究过程类似于传统的非敏捷设计过程:
B端用户研究的过程可以总结如下:
研究目的 → 选择合适的研究方法 → 进行研究 → 信息汇总寻找解决方案 → 报告输出 → 结果陈述 → 选择计划并实施
B端产品设计(设计师端)的流程也可以总结如下:
设计目标 → 选择合适的设计方法 → 设计性能执行 → 多个方案比较以找到最优方案 → 设计输出 → 方案展示与审核 → 优化方案并实施
如何做 B 端用户研究:
总结为四点:听他说的,他想的,看他做的,以及他的感受。
TA的想法和TA的感受,这两点可以通过平台内的用户反馈机制来采集。转瞬即逝的情感和用户对产品的情感最有价值,直接感受比回想更有价值。有参考价值。
以之前比较完整的B端用户调查实践(企业项目级)为例说明整个流程:
大纲设计-面试策划-面试前-确定大纲-面试实施-补充面试-补充问卷验证-输出报告-信息同步-实施实施-跟踪反馈。
反馈采集:
通过这样一套用户研究流程的推广,根据实际实施经验,一般可以发现两类问题:一类是老问题(VoC),另一类是新问题。
解释VoC(客户之声)的概念。 VoC对于推动B端产品的小步快速迭代和优化有着非常重要的作用。一些SaaS产品会配备专门的客户服务部门。跟踪用户对产品的实时体验反馈并解决客户问题。
对于B端用户来说,他们的行动动机通常由两部分组成:
第一部分是组织的运作目标,它关系到整个组织的结构,业务部门的具体运作形式(通俗地说,业务部门如何获得商业利益),各种组织中的角色和个人进行与协作办公室的合作,以及组织的业务目标和拆分为个人的目标。第二部分是角色的工作心智模型(指角色在受管环境中的心智模型),与角色的工作目标、具体的工作流程、日常工作模块以及所承载的KPI相关。
从产品设计师的角度来说,需要对多角色的业务流程进行抽象和重组,考虑角色信息在系统中是如何流动的,以及在产品界面中体现的业务关键决策点应该在哪里即,为了实现用户目标,系统应该向用户提供哪些有效且关键的信息?
以上都可以作为确定在B端用户通信系统中要采集的用户反馈阶段的基本内容框架。
ps:用户研究的详细介绍将是一个比较设计命题。由于本文文章的重点还是在B端用户通信系统的搭建上,不再涉及更详细的用户调研技术说明。当然既然应用研究的方法论其实是一样的,感兴趣的朋友可以自行查查相关资料。对于平台外用户反馈机制的运作,实际操作重于理论,在没有一定用户专业知识的情况下直接调查得到的结果也不会太差。采取行动是第一步,也是最重要的一步。很重要。
反馈分析:
通过各种调研技术获得用户的第一手反馈数据后,在对各种数据进行整理过滤后,通常的数据处理标准是根据反馈的合理性对反馈进行优先排序。其合理性可从以下几个方面进行评价:
实际场景中问题的范围,即反馈同一问题的用户数和问题再次发生的概率。
商业使用中的用户情绪范围,即用户在实际产品使用中的感受和情绪,这里可以结合平台中用户反馈机制采集到的一些有效的用户数据。
产品功能组织的范围,即问题对平台的影响,是仅针对功能、模块还是流程,无论是针对视觉展示层面、交互流程、系统性能级别,或业务逻辑级别。
团队成员所涉及的范围,即解决问题的难度和实现的价值。
通过以上三个方面对用户反馈进行综合评估,同时根据优先级进行跟进,推动问题的解决。
PS:此链接的重点是用户反馈的管理。事实上,它不仅仅针对产品本身。也可以包括设计师自己设计过程中的用户反馈管理。例如,在设计原型审查阶段,各个利益相关者的团队成员和参考管理方面。
面向用户的反馈表:
至此,产品设计师基本完成了平台用户反馈的采集整理工作。 For the entire user feedback system, the user’s side feedback to the product designer has been completed, in order to ensure that the system can continue to operate , The user-facing feedback from product designers can also not be ignored.
Remember that the feedback defined in this article is the two-way interaction between users and the platform. After collecting user feedback through various means (feedback mechanism within the platform + feedback mechanism outside the platform), how to solve the flow of follow-up tasks and problem solving The transparent announcement of scheduling, the maintenance and opening of communication channels, and the continuous follow-up of product designers are the keys to creating a closed loop of the entire B-side product user feedback system.
Disclose and communicate key node information to users in various ways in a timely manner to ensure users' sense of participation in the process of product co-construction. Generally speaking, it’s more common for the information that needs to be fed back to users to be fed back to user research. It’s more common to use a design pattern of feedback to users outside the platform. Through more formal communication channels, such as email communication, SMS notification, telephone communication, etc., the purpose is to make Users have the motivation to continue feedback.
07 to sum it up
The user feedback system of the B-side products can be connected and integrated by building a combination of the feedback mechanism within the platform and the feedback mechanism outside the platform. Collect coarse-grained user feedback through the feedback mechanism spontaneously initiated by the platform, and then supplement user research methods to mine fine-grained feedback, transform the feedback into effective real needs, and ensure that the entire mechanism can form a closed loop through timely feedback to users , And sustainable operation.
The premise of feedback is communication. Communication is always two-way. Build a timely and complete feedback interaction environment to ensure smooth communication and timely feedback between users, platforms, and designers.
Remember, investigating users’ real product experience, collecting user feedback and responding to users’ feedback in a timely manner is the only way to ensure a positive upgrade of the product experience.
This article was published by @稻草小八 原创 in Renren is a product manager, reprinting without permission is prohibited
标题图片来自Unsplash,基于CC0协议
奖励作者,鼓励他努力!
欣赏