明确目标、选择采集方法、制定采集计划、执行采集、资料整理,然后进入下一步的需求分析阶段。
2.2.1 定性地说:用户访谈
用户访谈通常采用访谈者和被访谈者一对一聊天的形式,访谈的样本较少,一般几个到几十个,但在每个用户身上花的时间比较多,通常十几分钟到几小时,围绕几个特定的话题,我没问、用户答,我没说、用户听,这是一种典型的定性研究。
一般用在新产品方向的预研工作中,或者通过数据分析发现现象以后,去探索现象背后的原因。
用户访谈的常见问题与对策:
第一,“说”和“做”不一致
诸如“我做了什么,步骤如何,碰到了什么问题”这类事实可信度高一些,而“我觉得、我认为”这类观点,则需要大打问号去听,并且机智地去探究支撑观点的事实。
第二,样本少,以偏概全
第三,用户过于强势,把我们往沟里带
第四,我们过于强势,把用户往沟里带
应对:
1、 避免一组固定的问题
2、 先关注目标,任务其次:比用户行为更重要的是行为背后的原因,多问问用户为什么这么做。
3、 避免让用户成为设计师:听用户说,但不要照着做
4、 避免讨论技术
5、 鼓励讲故事
6、 避免诱导性问题
2.2.2 定量地说:调查问卷
用户访谈的提纲是开放式问题,适用于我们心里比较疑惑的时候去寻找产品的方向,适合与较少的访谈对象进行交流。
调查问卷通常封闭式的问题较多,适合大用户量的信息搜集,但不够深入,一般只能获得某些明确问题的答案。
作答时间最好不超过5分钟,开篇放一些简单不需要思考的问题,敏感问题放在中间,个人信息题目放在最后。
调查问卷的产检问题与对策
第一:样本的偏差,即样本与想了解的目标用户群体出现偏差。
尽可能的覆盖目标用户群体中各种类型的用户。
第二,样本过少
第三,问卷内容细节问题
问题表述应无引导性
2.2.3 定性地做:可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中可用性的问题,通常只能做少数几个用户的测试,看他们怎么做,属于典型的定性研究。
可用性测试的基本过程就是用户通过使用产品来完成所要求的任务,同时组织在一旁观察用户操作的全过程,并把发现的问题记录下来。
可用性测试的常见问题与对策:
第一, 如果可用性测试做的太晚(往往在产品将要上线的时候),这时发现问题也于事无补了。
第二, 总觉得可用性测试很专业,所以干脆不做。(通常来说做5个用户才可以发现大部分的共性问题。)
第三, 明确是测试产品,而不是测试用户。
这个测试的目的是发现产品中的问题,而非用户是否有能力使用软件。
第四, 测试过程中,组织者该做和不该做的:
开始时,告知用户要做哪些事,大概持续的时间;
测试中,鼓励用户用“发声思维”的发放,即在使用产品的过程中说出自己的思考过程。
不要有任何引导和按时,只是观察和记录。
对于“改版”的可用性测试:
1、“可用性测试”要在足够早的时候做;
2、先从部分次级页面改起;
3、新旧版本并存一段时间,允许用户自由选择,此时可以加入问卷调查;
4、小面积实验,选择一小批测试用户开放新版本,检测效果,做用户调研。
2.2.4 定量地做:数据分析
常见数据分析的方法:用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。
数据分析最关键的是对结果的解读,通常数据分析只能发现一些现象和问题,并不能了解原因,所以分析完成后通常会伴随着一些用户访谈,听听用户怎么解释。
我们应该在产品设计时把数据分析的需求加进去(数据埋点),比如记录每个按钮的点击次数、统计每个用户的登陆频率等,这也算是一种典型的非功能需求,这样做对产品的可持续发展十分必要。
2.2.5 需求采集人人有责
生孩子与养孩子
一手需求:直接从用户那里得到的需求——生孩子
二手需求:老板、销售说的用户需求——养孩子
二手需求,或多或少有扭曲。
单项需求卡
单项需求卡是一种简单的二手需求采集工具。
单项需求卡描述了一个用户的需求到底包含哪些内容,重点是描述用户场景,谁在什么时间、地点产生了何种需求。
尽可能多地采集
现场调查——定性分析,要特别小心不要被“非典型”用户带到沟里。
AB测试——基于大用户量比较合适,比如让用户参与测试,被称作土豪的游戏,只有大公司玩得起。
日志研究——用户的日志、博客等。
卡片分类法——把产品的各种需求写在便利贴上,让用户一起讨论并完成分类。卡片分类法能让最终的产品更加符合用户的心理模型。
自己提需求——