前段时间我们基于CVM（腾讯云服务器）产品控制台，进行了一轮针对中长尾用户的用户访谈，是一次比较完整的的访谈流程，有一些心得体会，积累了一些实用经验，虽然对于我们来说有一定的挑战，但是通过这种方式直接与用户对话，给我们带来了很有用意义的信息，我把这次访谈中积累的经验记录下来，希望能给对用户访谈感兴趣的同学一些帮助。
用户访谈作为设计师日常需求中经常会用到的用户研究方法，是一种定性的研究方式。通过用户访谈，我们可以了解一些特定问题、更加了解用户，增加我们作为设计者对于使用者的同理心，避免片面、刻板的认知，尤其是toB产品，用户访谈是了解用户诉求的最直接方式。
用户访谈的价值
对于产品设计来说，不同的产品阶段，进行用户访谈都能够带来很多价值。
在产品初期
通过用户访谈可以帮助我们了解用户的实际需求，发现市场机会；或者通过访谈了解用户对产品初期的设计是不是认可，以及如何优化；
产品的上升期
产品成熟期
可以了解用户对产品的开发和建议，不断优化产品体验；假如产品遇到问题，通过用户访谈，可以帮我们找到一些具体问题的答案；
产品衰退期
可以帮助我们从用户视角了解产品衰退的原因，找到二次增长的转机，或新的突破口。
用户访谈在产品周期中的价值
如果你的团队有用户研究同学的资源支持，那么很幸运，你可以有机会在实践过程中学习专业的访谈方法，如果没有，作为设计师也可以试着拓展技能边界，从实践中积累经验。今天就基于我们作为交互设计师，通过执行一次相对完整的用户访谈，谈一谈我们的经验，希望可以给大家带来一些启发。
toB管理端的访谈流程
在我的工作经验中，通过半结构式的访谈是比较常见的方式，通常来说，半结构式用户访谈的完整流程包括：
确定访谈目标-选择合适的访谈方法-找到合适的访谈对象-根据目标准备访谈大纲-提前了解用户并预约时间、地点-访谈实施-访谈复盘-最终整理及梳理洞察-通过访谈获得的产品优化方案并实施推进；
toB管理端用户访谈的基本流程
访谈前
访谈前的准备非常重要，访谈是否顺利、能否得到有效信息以及是否能得出有价值的结论都是由访谈准备的质量决定的。
明确访谈目标
访谈目标决定了我们选择什么样的访谈方式及后续的计划。以本次CVM中长尾用户调研为例，我们本次访谈的背景是：
前期完成了通过工单解决了控制台可用性问题，从工单问题中能够看到用户遇到的很多问题，但是面对复杂的高门槛业务产品，CVM中长尾用户的实际场景和实际困惑是什么呢？用户通过工单寻求帮助多数是实在用不下去了，所以体现的更多是可用性的问题，如果想要在此基础上更好地为用户提供服务，就需要更加贴近真实用户，倾听他们的声音。
产品问题分布关系
在此之前我们并没有十分了解中长尾用户的实际使用情况，要了解实际的体验问题，我认为不通过用户访谈、只靠定量分析是无法得到准确答案的，因为我们希望通过用户访谈，对用户使用产品的动机、使用控制台的场景有更深的了解。
选择访谈方式
根据访谈目标，选择合适的访谈方法。
因为前期我们通过体验走查和竞品分析，已经对腾讯云服务器用户的典型使用路径和基本问题已经有了一些了解，希望相对比较有针对性地了解用户体验问题，我们选择了半结构式的用户访谈，按照用户使用服务器的典型路径进行了访谈大纲的设计，并实施了访谈。
用户访谈的方式
召集访谈对象
找到对的人是成功的一半！合适的访谈对象能让我们的访谈事半功倍，我们需要根据产品特性来选择满足条件的访谈对象。
以腾讯云服务器中长尾用户为例，我们并不关心用户的性别、年龄、婚姻状况这样的人口统计学条件，而更关心用户是以什么样的身份使用服务器、用户的知识背景等职业特性相关的影响因素；
通常在召集用户的时候，应根据用户画像或者产品对用户的粗分进行召集，同时还应注意用户量的平衡，因为B端产品，尤其是腾讯云服务器的中长尾用户光谱分布比较宽，类别较多，我们关注的标签分类比较多，因此在找用户的阶段，要把标签属性和用户数量分布列清楚，真正做到找到对的人。
本次访谈的用户分布
与toC用户召集不同的是，toB用户的信息资料更加难获得，虽然有后台系统，但是出于对用户隐私的保护，我们是没有办法，也不会轻易拿到用户的联系方式，因此我们首先通过在产品后台投放调查问卷，首先保证是产品的真实用户，通过调查问卷了解用户的联系方式及被访谈的意愿，通过这种登门槛效应，圈到可以被筛选的访谈对象池。
⚠️这里要特别提一下，在投放调查问卷之前，要针对访谈目的结合访谈所需条件，进行调查问题的设计。
B端产品，尤其是控制台产品要找到有意愿接受访谈的用户是有一定难度的，所以可能需要依靠一定金额的礼金来支付用户付出的时间，有条件的话，可以请第三方公司帮忙甄别，节约时间。当然如果有足够的人脉，也可以动员起来，访谈起来也更容易一些。
根据访谈目的和对象设计访谈大纲
访谈大纲是非常重要的一步，访谈大纲的设计，决定了我们能不能问到正确的问题、获得有用的信息，还可以起到提示的作用，在访谈大纲上可以写清楚每个问题需要关注的信息和提问的目的，防止信息遗漏，因为一旦谈话展开，由于访谈者的认知资源被占用，极有可能会有漏掉的问题，提前做好准备可以让我们的访谈更加顺利，所谓有备无患。
而且在远程访谈的情况下，在线大纲、文档可以帮助访谈员和记录员之间通过文字沟通，提示问题；
访谈大纲可以由以下几个基本部分组成
- 破冰：自我介绍、情况说明、活络气氛，为接下来的的访谈做好铺垫；
- 信息确认：了解用户的基本信息，产品体验历史和大概经历；
- 逐渐深入：开始进行较深度、详细的提问，了解用户使用体验的真实情况和体验细节；
- 回顾与补充：结合前面访谈过程中的对话内容，可能需要一些补充的问题，在这里可以跟用户展开开放式的对话，了解用户对产品的整体态度、建议、对竞品的态度等。
访谈大纲设计
访谈大纲由访谈目的决定，很多用户访谈中间也会穿插可用性测试等方式与用户互动，这个大家可以根据实际情况安排，但是基本原则是由浅入深，层层递进。
访谈大纲设计完成后，可以找团队小伙伴帮忙内测一下，确认这样的访谈大纲是否顺畅，是否能通过访谈大纲问出我们需要的信息。
访谈安排-时间、地点、人物、手段
在访谈展开之前需提前了解用户并预约时间、地点
由于B端产品的特性，很多用户在使用云服务器的场景是工作场景，所以在时间选择上，可以考虑安排在周一到周五，我认为这个是一个与toC产品微妙的差别，c端产品的使用场景通常比较轻松，周末是更好的选择。但是B端产品用户，尤其是对于CVM服务器控制台来说，用户在使用产品时，通常是工作状态，因此用户方便的话，最好是工作时间进行访谈，可能会得到更加真实的信息。
理想情况下，最好的访谈方式当然是到用户真实的工作环境中去，了解用户的真实使用环境，用什么电脑、如何与同事互动等等，但B端用户相对较少，能在本地进行访谈的用户更加凤毛麟角；次之是邀请用户用户通过腾讯会议进行访谈，好处是我们可以看到用户的实际操作，了解用户潜意识里的操作习惯，而不是听用户转述。但是，CVM服务器用户的账户及控制台所呈现的信息可能会触及用户商业信息或隐私，因此只有少数个人用户愿意通过腾讯会议进行操作演示，所以我们最终选择了通过电话进行访谈，只有个别愿意通过会议展示的用户配合了腾讯会议进行了简单的演示。
访谈途径选择
访谈中
访谈实施
在访谈正式开始前，最好提前做好设备调试的准备，可以的话可以先找同事帮忙，试一下声音是否足够清晰，会不会有延迟等情况在选择远程访谈的方式时，这个步骤尤其重要。实际测试会发现，公司会议室的电话如果使用外放，声音可能会有些浑浊不清，可能需要大家实际测试一下，谨慎使用（没有说公司电话不好的意思）。
访谈大纲帮我们梳理好访谈流程，且我们也提前了解到的用户基本信息，因此在访谈开始的时候可以抛一些已经知道答案的信息来热场。
- 破冰：自我介绍、情况说明、活络气氛，为接下来的的访谈做好铺垫；通常我会选择把自己介绍为产品邀请的访谈员，与产品本身没有直接关系，这样可以避免用户因为考虑到访谈者与产品的关系而有所保留；
您好我是腾讯云服务器产品的访谈员，我叫xxx… …
由于访谈是通过电话进行，在正式开始访谈之前需要对用户信息进行确认和甄别；
- 信息确认：了解用户的基本信息，产品体验历史和大概经历；
在询问基本信息的时候，问答题为主，而不是判断题或选择题，这样一方面可以确认前期用户甄别是否属实，另一方面也许可以在用户回答问题的内容中获得一些额外的信息。
更开放的问题举例
- 逐渐深入：开始进行较深度、详细的提问，了解用户使用体验的真实情况和体验概况，沿着这些问题逐渐深入、延展，同时访谈大纲可以帮我们主导访谈进程，控制时间；
一定要会追问用户表达的真实含义，要明确用户话中提到的比较模糊的词汇明确的意思是什么；
尽量引导用户讲更多有用的信息：用户有时候会用概括的描述回应我们提出的问题，但我们需要的是更具体、实际的情境和表达，这时候可以通过换个问法、具象化问题来引导用户将更多信息；
深入问题探究举例
大家在用户对某个点进行了评价反馈后，可以把你理解的用户的话表达的意思再复述一遍给用户，得到进一步确认。在我们的访谈过程中，确实发生过几次由于对一些词汇的理解不同造成理解有偏差的情况，这些误会都是通过复述和确认用户意图发现的。
- 回顾与补充：结合前面访谈过程中的对话内容，可能需要一些补充的问题，在这里可以跟用户展开开放式的对话，补充了解用户对产品的整体态度、建议、对竞品的态度等，很多问题可能是在补充的问题中发现的，同时在继续聊补充内容的同时，也给用户一个缓冲思考的时间，可能会等到一些用户想到的其他信息。
⚠️访谈中难免会遇到沟通不够顺畅或者态度不是那么随和的用户，访谈员必须保持冷静、客观，B端产品与工作效率和舒适度强相关，难免会有用户想要多吐槽，甚至是发泄一下的情况，我个人认为这种情况并不是坏事，反而可以引导用户讲更多问题，这也是为什么在这次访谈中我们并没有讲我们是业务相关的设计师或产品的原因。
过程中用户也可能会提出一些问题，遇到这种情况，可以尝试探测用户认为的答案，来了解用户的心智和预期，而不是回答用户的问题。
通过反问获得信息
在访谈过程中，尤其是排在前面的一两位用户的访谈，可能会帮我们发现一些之前没有想到的问题，或者是在访谈过程中发现可以展开聊聊的点，这些如果在过程中没有涉及到，可以在结束前再进行补充。在访谈结束前，可以再问一下用户有没有想要补充的，或者跟你一起做记录的小伙伴有没有想要补充的问题。
最后要记得感谢被访用户，优质的用户可以考虑是否可以留下联系方式，后续也许会成为我们产品的成长伙伴。
访谈现场复盘
每次访谈结束，尽量现场进行复盘，也就是结束访谈后第一时间进行复盘整理。这次访谈我们的配置是一位访谈员加一位记录员，结束后，一起复盘谈谈感受和发现是很重要的一件事，尤其是访谈员在访谈过程也会有一些想法和发现，但不能在访谈中随时记录下来，这时候尽早记录可以避免一些想法的遗漏。
访谈后的复盘
整个访谈征得用户同意进行了录音，在做访谈内容整理的时候，可以通过再次听录音保证记录的完整性。当然记录不是事无巨细地把所有内容记下来，只需要mark下需要关注的信息。
访谈后
整理及洞察
所有的访谈进行完后，需要对访谈内容进行整理，实际找出能够帮助我们解决问题、优化产品的点才是访谈的价值所在。我通常整理的思路一般会分成以个人维度的、类似画像的描述整理；以及纵向，类似体验地图式的纵向分析。
以单个用户的维度，关注访谈的对象是否能进行归类，归类以后的角色可以代表一群人的使用特点，访谈可以帮我们完善和细化用户画像。CVM服务器的用户类型差别很大，即便是中长尾用户，也包含了完全不同的使用方式和使用角色，因此归纳典型用户类别，描绘用户在使用服务器的场景、形象对于后续产品精细化产品设计具有很重要的意义，同时也能够作为我们推进产品进行用户标签系统搭建的重要理由。
依照用户典型的产品路径，把所有被访用户针对路径的反馈和想法展示在同一个表格中，通过纵向对比，可能的得出一些有价值的结论。
横纵向分析对比
还有很多对于分结构化信息的分析方法，可以在实际实践中结合使用；
问题清点法：清点发可以通过统计次数，比如有多少用户多少次提出关于某个问题的反馈，这可以反应问题的严重性或普遍性。
但有一点，因为用户访谈的样本量比较小，很容易出现偏差，那么没有提到的问题，并不能得出没有需求的结论。也就是说，当这个问题出现，或频繁被提到的时候，应引起我们的关注，但相反，我们假设的问题没有被提到时，仍不应轻易忽略。
原因归纳法：即出现问题的原因都有哪些，帮我们找到解决问题的路径和方法。
同步信息及推行实施
具体每个产品或业务可能会略有不同，通过访谈到的结论和洞察可以根据自己的产品情况具体展开和整理。
用户的反馈信息可以按照用户的肯定、问题和建议，将用户访谈内容提炼出最有用的信息。与产品优化相关的问题和建议可以按照问题类型或模块分类进行归类。
按类型归类问题
访谈整理及梳理洞察-通过访谈获得的产品优化方案并实施推进，基于对用户深度访谈的结果，可以组织业务方一起，把这些洞察转化成可以具体实施的方案。
通过访谈获得的想法
有的结论可能无法马上转化成具体产品方案，但是对团队内部对产品方向的认知是有帮助的，也应该记录下来，作为未来团队内部发展方向的可借鉴的信息。
小结
以上就是我们通过一整套完整的用户访谈总结的经验和流程，最核心的点就是前期准备要充分，访谈实施要细心，访谈整理有逻辑；牢记这三点，按照这个流程去实施访谈，就是一场完整、有效的用户访谈了。
用户访谈的基本流程
最后值得一提的是，在做B端产品的用户研究时，由于用户的工作环境不同等原因，用户的很多行为特性是由其所在的公司、组织等团体特征决定的，因此通过了解一个不同的团体特征也可能会给我们带来新的认识。比如同样属于拥有少台服务器的企业，这在我们之前讨论的认知中都属于中长尾用户，但有的属于比较大公司的一个部门，有的是小型创业公司，组织架构类型的不同也会对用户使用产品的习惯造成影响，后续会针对这一点进一步研究。后续再跟大家交流分享。
若有收获，就点个赞吧
0 人点赞
