用户访谈—几个细枝末节的问题.pdfVIP

用户访谈—几个细枝末节的问题 提到用户访谈 ，根本上说就是我们提出问题 ，用户回答问题。如果稍稍 行细化 ，访谈又可以分为 两个阶段 ，即访谈阶段和体验阶段。访谈阶段主要目的是从用户的经验和认知中获得有价值的问题 ，而体验阶段是让用户在体验我们给予的部分设计 ，激发他们的评价 ，观察他们的体验 ，从中寻找 问题。 让我们假设一次最理想的用户访谈 ，如果用图表示出来应该是这样 ： 主持人负责控场 ，将大量的谈话空间留给用户 ，并且用户紧扣主题 ，每一句都直接映射出需求。 可是现实是残酷的 ，用户并不会与我们这么合拍 ，很多时候由于我们自己的问题 ，访谈的效果会大 打折扣。经验丰富的人可能会用自己强大的驾驭能力牢牢把控整个访谈 ，但是对于经验不丰富的大 多数访谈者 ，便会遇到以下的一些问题。 一、热身的尴尬 大多数访谈计划中 ，热身的任务就是套出用户背景信息。我们通常也很忠实地履行着向用户套取背 景信息的职责。实际上热身本意是让用户打开话匣子 ，让用户 入状态。这是整个访谈的开端 ，确 定了整个访谈的基调和气氛 ，很多时候用户将访谈误认为是考察 ，或者以为这是满意度调查 ，甚至 以为是总部派来解决用户困惑的特派员……这跟谈话技巧很有关系 ，不过有几个点一定要涵盖到 ： 自己的身份 ，自己在团队中的位置 ，采访的目的 ，我们希望用户扮演的角色 ，以及一些背景的问题 。让用户在一个确定的话题范围内开始对话 ，即可以提供思路让用户打开话题 ，也可以避免后期 跑题。 二、太过冗长的问题 在理想状态下 ，我们的问题当然不可能很长。不过当用户对我们的问题不理解的时候 ，我们就不得 不开始漫长的解释。 太长的问题容易让用户走神 ，甚至让自己走神 ，用户在尝试理解不了之后便会放弃倾听 ，而访谈者 在组织语言帮助用户解释问题之后 ，通常也没有办法快速回到问题本身上来。 所以在问题的设置上 ，我们必须要注意问题本身是否易于理解 ，如果这个问题太过复杂 ，就要考虑 将其分解。 三、引导用户得出答案 •只接受自己倾向的答案 ： 很多问题我们初听觉得“毫无价值” ，对于这些问题我们会跳过或者不认真记录。有的时候 ，用户表 现出的问题与我们预期相反 ，我们很快会为之找到理由 ：用户并不是非常理解我们的产品。我们需 要注意的是 ，用户的回答并不等于用户的需求 ，很多看似无用或者不符合“常识”的回答中蕴含了很 重要的信息 ，而在短暂的访谈中 ，我们并不会立即发现。甚至 ，这可能表现出我们最初分类的目标 用户并没有把眼前的用户涵盖 去。 • 做“鼓励” ： 对用户做鼓励要慎重 ，虽然用户在受到鼓励的时候会被激发谈性 ，但是鼓励本身也是一个倾向性的 引导。比如用户在小心翼翼提出一个问题 ，我们点头表示赞许 ，这本身暗示着他需要通过我们“ 表态”来回答问题 ，这很容易造成用户顺着我们意愿答题的结果。我们可以表现出对用户的问题点表 现的很有兴趣 ，希望他说下去 ，这种鼓励的方式比带有认同性的鼓励要中性很多。 •向用户“推销” ： 有的时候用户由于不理解等原因对我们的产品颇有微辞 ，作为设计师的我们会积累很多很多委屈 ， 很多用户提出的点我们已经做到了 ，而我们却要忍受用户大量的“无用抱怨”。所以在这种时候 ，我 们就会忍不住要开始对用户 行教导了。心虚的用户立即道歉 ，瑟瑟发抖。牛气的用户拉开战线 ， 和我们再战五百年。不论如何 ，这都会让问题脱离问题本身 ，用户会根据我们的态度 行措辞 ，而 不是思考自身的问题了。 •曲解用户的回答 ： 用户很多问题都会含糊不清 ，此时主持人应该复述用户的问题以确认 ，或者干脆表示并没有很清楚 用户的问题。我们很容易将用户的话作自己理解后抛给记录者 ，或者反问回用户。通过主持人理解 后的答案很可能不是用户本来要表达的意思 ，但是用户本身可能也并不是很清楚自己的答案 ，在主 持人“帮助理解”后 ，会直接附和。这样问题本身就会被造成偏差。 •被强势用户带着跑 ： 我们会遇上很多喜欢占据对话主导权的用户 ，他们经常会把访谈拉离主线。我们应该借着谈话的 空隙 ，也就是他们喘气的档口 ，把话题拉回主线。如果徒劳 ，我们应该评估一下用户是否真正了解 我们讨论的话题。通过旁敲侧击将话题带回主线 ，如果他们离我们的目标用户定位相差太远 ，尽早 放弃 ，节省时间成本 ， 行下一家访谈。 •把用户当作设计师 ，希望他们提供有效的建议 ： 精确并不等于准确。我们通常喜欢问您对我们的XXX有什么建议没有 ？或者如果你来设计XXX你会 怎么做…… 用户并不具备专业技能 ，他们即便对产品很有研究 ，能够提供的解决方案也十分片面。正如我们某