用研项目经验「互联网无本项目干货」
今天给大家普及一下用研项目经验「互联网无本项目干货」相关知识,最近很多在问用研项目经验「互联网无本项目干货」,希望能帮助到您。
编辑导语:用研对于丰富整个项目来说十分重要,本篇文章作者分享了几个适合推动团队去用研的时机和方式,从问卷和访谈两大方面具体展开,讲述了具体的用研方法,能够有效丰富整个项目,一起来学习一下吧,希望对你有帮助。
不知道大家平时会通过什么方式对行业有趋势性的了解,我本人有一个小习惯,就是定期地去看一下岗位招聘信息,倒也不是为了跑路,而是可以从大环境的岗位招聘信息中了解到一些有效信息。
比如这个岗位大多数的工作内容都是什么样的(对比下自己所在的地方,是不是过卷了),岗位要求是什么样的(有没有什么普遍要求的能力,我没有经验需要在下次工作中去补充弥补的),薪资水平如何(需不需要考虑和领导沟通沟通)。
而交互设计中,有一项工作内容/岗位要求常年挂在招聘信息内,却很少能在作品集里有具体的呈现——用户研究。
如果你现在马上拿起手机去看看几个大厂的交互招聘信息,基本上每5条招聘信息里有4条都能找到以下内容/要求:
1)工作内容:
“发起和参与用户研究,根据用研结果对设计方案进行优化;负责产品的可用性测试和评估提出改进方案,持续优化产品的用户体验”。
“参与用户研究,根据用户研究结论对设计方案进行优化,持续改进产品体验”。
2)岗位要求:
“掌握基本的用研方法,具备基本的数据分析,视觉设计判断能力”,“掌握常规用研方法,定期参与或主导用研活动”。
与其等到要应聘了才追悔莫及,不如在日常需求过程中寻找合适的时机熟练地使用起用研这项工具。本篇文章我们就来聊聊,日常需求中如何见缝插针地融入用研,丰富经历。
实际工作中常见的用户研究方法有:用户访谈、问卷、可用性测试。
其中用户访谈还分为线上和线下、深度访谈和拦访,这几种方法的具体释义随便搜一下都有,这里就不赘述了。
简单分享几个适合推动团队去用研的时机和方式,亲测有效!
一、问卷1. 适合用问卷的时机问卷的用法有很多,专业用研人员更多是运用他们去度量产品体验,将定性问题定量化。
例如字节的多数团队每双月都会有问卷调研评估用户对产品的体验评分,通过逐个双月对比来判断哪些功能是本双月应重点优化的,哪些上个双月优化成果不错。
但是这种大体量重复性高的问卷工作对于一个交互打工人来说太难推进了,更多依赖团队意识。这里想分享是一个日常小需求中适合将问卷运用起来的案例。
举个例子,比如你的业务是电商直播,上线购物入口后发现效果没达到预期,因此需要对入口做优化修改。
这种优化需求无非就是在规范内做有限的排列组合,换个位置 x 换个图标(或文案)x 换个颜色,对产品的定位、直播间的布局不会有影响,但是组合方式又较多,每个都做实验会造成资源浪费,每个方案都和产品扯皮一次能扯到地老天荒,这种时候就很适合做问卷,你主动向产运提出,一般都不会受到反对。
2. 简单的问卷方式把你能想到的,符合产品规范和调性的方案设计出来,交给运营让运营在用户群里发放问卷,并问几句为什么。
最后把社区调研的结论输出成一篇文档,包含关键结论、具体的问卷结果饼状图、用户反馈总结与部分原文,以及后续To do。
一份简单又有实际成效的用研就成型了,真实工作场景中用时在1-3个工作日之间,也不会影响需求上线节奏。
二、访谈1. 适合做访谈的时机还是以电商直播为例,如果此时你的设计方案已经是最合理的,比放任何地方、任何样式的数据都要好,但是业务整体指标就是上不去,这个时候已经不是看数据能解决的了,就需要去通过用户访谈来了解背后的原因了。
用户访谈是比较复杂的用研工具,所以一般在产品停滞某个阶段较久,无法单纯地从数据分析和需求臆想解决现阶段问题的时候,团队内会主动发起、使用。如果你发现你的产品正处于这个阶段,适当地推动一下,会比在其他时候更容易申请到资源实施落地。
2. 设计访谈大纲在访谈之前,我们如何准备访谈的问题呢?需要要先明白调研的目的是什么?
如果以电商直播这个例子来说,我们不明白为什么用户不在我们平台直播间购买商品,所以我们需要用户对我们现有产品的使用情况做反馈。
这时候用户旅程地图就起到了作用,我们会把用户在直播间购买商品的行为进行拆分,例如可以分为:浏览直播流——进入直播观看解说——想要购买——完成购买,如下图所示:
在每个阶段我们都可以进行一些假设和提问,来具体化评估产品表现。
例如,我们在浏览直播广场时,我们可能做出如下假设:
推荐的直播间不准确,用户不感兴趣;瀑布流布局虽然效率高,但有效信息过少,不如沉浸式消费体验好;用户购买行为对象是商品而不是直播间,应按商品维度进行推荐。做出了这些假设之后,我们就可以根据这些假设来设计访谈问题,例如“你现在刷一下我们的直播广场,看一下有没有你感兴趣的直播间”。
在这里想强调的是,实际用户访谈的时候我们一定要进行追问,所以在设计访谈问题的时候需要根据用户的几个不同表现设计不同的追问。
例如当用户在访谈过程中有刷到感兴趣的直播间了,你可以追问“你大概刷几个直播间能遇到一个感兴趣的直播间呢”(量化推荐准确度),“你感兴趣的直播间都是哪些,为什么感兴趣”(强化推荐准确性)。
如果访谈过程中没有刷到感兴趣的直播间,那么你可以追问“如果现在出现一个什么样的直播间你会想要点进去呢”(了解产品没满足到用户的地方),然后根据用户的回答进一步追问“为什么”,基本就能得到用户期望补充的推荐维度或产品能力。
以此类推继续对其他阶段做出假设、设计问题与追问,一份用户访谈大纲就可以成型了。我喜欢按如下的表格来输出访谈大纲,可以供大家参考一下:
之所以在访谈大纲里把假设缩略了,是因为工作中大家的假设不一,但关注点是一致的,输出文档的时候可以用更简洁但大家都能看懂的方式来表达,这不代表建立假设这一步可以跳过,建立假设是思考的过程。
写完访谈大纲后我们还需要检查一下问题提纲里有没有什么问题是不合适的,比如以下几点建议大家在设计问题时都要避免:
1)在访谈问题中出现行业专用黑话
例如“转化”、“操作”、“流量”,这些黑话的出现只会让用户紧张自己是不是水平不够不够格被访谈,然后为了避免被看出来一通瞎说,如果希望用户能在一个放松状态里给出真实的反馈,请将这些黑话都改成日常词汇,如“进入到”、“点哪里”。
2)让用户预测未来的行为
例如“假如上线某功能,你会用吗?”,用户的预测不能准确地反映他们未来真实的行为,如果你想验证某些未上线的功能,最好的方法是制作可交互原型做可用性测试结合访谈。
3)让用户脱离场景讨论操作细节
例如“你有什么好建议?你觉得怎么解决比较好”,用户无法准确回忆每个操作步骤,更好的做法是让用户直接演示给你,而不是询问看法。
4)让用户对没见过或没用过的概念进行想象或评价
例如“假如和主播申请连线的时候可以填写连线申请,你觉得怎么样”,用户不是设计师,无法准确表达他们想要什么,而且在这种场景下用户都会给面子地说会用啊,很好啊,这类问题属于无效问题。
3. 寻找访谈对象访谈提纲有了,访谈对象如何寻找?上述我们的例子其实默认了访谈的对象是全体用户,实际访谈时我们可能会对访谈对象有不一样的要求。
例如,如果我们通过对比发现,和竞品相比我们在18~23岁这个年龄段的男性用户有比较大的缺失。
所以我们建立的访谈目标是,了解18~23岁的男性用户为什么不来我们直播间购买商品,那我们就可以确定访谈对象为:
我们需要再定义一下流失用户和围观用户的行为标签,方便测试同学筛选,例如,流失用户可以定义为购买过1次且3个月内再无购买行为的用户、围观用户可以定义为过去3个月看过电商直播但是没有过购买行为的用户。细化下来我们应该给测试同学筛选的用户对象就为:
性别男;年龄18~23;购买过1次且3个月内再无购买行为、过去3个月看过电商直播但是没有过购买行为的用户。如果我们的目标是全体用户,也是需要进行一些筛选的,一般还是需要进行用户分层,然后按照实际使用的用户分布来确定每个分层需要访谈多少对象,例如我们的产品中,0-18岁用户占20%、18-35岁用户占17%,35岁以上用户占63%。
那么如果我们的资金和人力只够访谈10个人,我们就需要找2个0-18岁的用户,2个18-30岁的用户和6个35岁以上的用户(其他维度的筛选方式也是如此)才能得到比较准确的用研结论。
一般我们需要筛选比实际访谈人数要多的用户群,然后通过发放问卷的方式了解访谈意愿。发放的意向问卷里一般包括以下信息:
产品使用情况及态度;性别、年龄、职业等基本信息;是否愿意到线下访谈。回收问卷后筛选合适的访谈对象,就可以联系受访者确定访谈时间了。
4. 访谈现场与访谈记录访谈至少需要2个人进行,一个提问,一个记录,如果有观察室或者线上会议的话,其他团队成员可以通过去观察室或者线上接入来旁听。访谈期间尽量将用户的原话和行为直接记录,不做判断加工,等所有访谈结束后再梳理总结。
通常我们会把访谈记录直接补充到访谈提纲旁,在访谈记录前还需要对受访者的一些基本信息作备注。
实际的访谈可以根据受访者的反馈做一些调整和补充,比如受访者虽然不常使用我们的产品,但使用别的竞品,就可以问为什么更常用别的竞品,是否有什么我们缺失的功能。
访谈前,为了让受访者放松,也为了先拉近距离,可以进行简单的聊天。
然后再以“我们的访谈仅供研究使用,不会侵犯你的个人隐私,访谈过程中遇到什么问题都欢迎随时提出来,不是你的问题是我们产品的问题”开头,然后正式进入访谈。
访谈结束后是需要给予受访者报酬或小礼品的,这一步一般是由用研或运营同学来实际执行,在采访末尾我们也可以顺带提一下,给受访者一个好心情。
5. 输出访谈报告所有访谈结束后要趁着记忆清晰及时梳理输出报告。报告的展现一般以一句话介绍背景,访谈关键结论,关键结论具体阐述(小结),后续Todo,最后再附上访谈大纲与访谈记录就可以了。继续以上述例子示意,文档结构大致如下:
作者:白话说交互;微信公众号:白话说交互;
本文由 @白话说交互 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自unsplash,基于CC0协议。