存档

文章标签 ‘需求采集’

产品设计体会(1015)用户访谈的常见问题与对策

2010年2月3日

新书剧透,哈哈。第2.2.1节里的一段,章节导航一把:

一个需求的奋斗史 –> 需求采集的大生产运动 –> 定性的说:用户访谈 –> 用户访谈的常见问题与对策

用户访谈经常出现如下问题:

第一,“怎么说”和“怎么做”不一致的问题。

用户经常会骗我们,先看一个经典的索尼游戏机的故事。

  • 索尼找了一些用户来,问他们喜欢白色的还是黑色的游戏机,结果发现说喜欢白色的用户比较多。之后,索尼告知用户为了感谢他们的配合,将送他们一台游戏机,颜色可以任意挑选,而同样一批用户选择黑色的游戏机带回家的更多。很明显,有部分用户说喜欢白色却带走了黑色的游戏机。

用户倒不是故意想欺骗我们,而可能是:他们被问了自己也没仔细想过的问题,又不想回答不知道,就在现场编造了一个看似有理有据的理由;或者他们有讨好访谈者的心理,会回答他们觉得你希望听到的答案,而不是自己真正的想法……这些原因都很有意思,想深入研究的同学可以去看社会心理学里有详细的里的相关论述。

对我们来说,防止被骗的方法恐怕是像索尼一样,尽量在用户可以和产品发生交互的场合下进行,让用户在“说”的同时也“做”,只不过,这样访谈的成本会明显高于电话访谈或邀请用户来公司的会议室访谈。另外,我们也可以注意区分用户说的事实与观点,一般来说,诸如“我做了什么,步骤如何,碰到了什么问题”这类事实的可信度更高一些,而“我觉得、我认为”这类的观点,则需要带着大大的问号去听。

第二,样本少,以偏概全的问题。

选择样本的时候需要多加注意,尽量做到随机,举几个常见的“不随机”的例子。

  • 比如为了成本考虑,我们上门访谈的时候只找了本市的用户,这样很可能得出一些与地域有关的错误推论;又如电话访谈时,为了提高联系成功率,我们优先拨打留了手机的用户,而留手机很可能代表这批用户忠诚度已经比较高;再如邀约用户来公司访谈,“愿意来的用户”,就已经和全体用户有差异了……

对于这个问题,我常用的几个对策如下。首先,我们应该尽量识别出各种可能引起偏差的因素,在访谈的报告里标明,让读者了解。然后,为了用尽可能少的样本得到尽可能正确的结论,我会以增量的方式做访谈。举个例子,我会先访谈5个用户,得出基本结论,然后再访谈5个,观察结论是否有改变,如果有改变,就继续加大样本量,或者思考问题是否合适?样本集是否合适?如果没有改变,就停止继续访谈,节省成本。

样本的选取,其实属于概率与数理统计的范畴,想深入的同学可以自行研究。

第三,用户过于强势,把我们往沟里带。

我在2006年底做网店版的用户访谈的时候,就经常犯这个错误:

  • 当时我们找来了很多淘宝的大卖家,问了几个问题以后,那些卖家的情绪就被调动起来了,似乎好不容易有个倾诉者来听他们创业过程中的成就与艰辛,然后就开始讲故事,比如卖水货手机的帅哥给你讲中国整个水货手机市场,第一级只有深圳的几个人在卖,每天凌晨两点开始在某个秘密地点出货给第二级,都是以“百台”为单位叫价,和古老的证券交易所一样,然后四点左右第二级就会把当天的价格传真给他……改天又来一位卖钻石的少妇给你讲他老公多有钱多有钱,就是没空陪她,给她在上海最繁华的地段买了个门店卖钻石,她经常去南非采购,一次买好多,轮着带,不喜欢的就折价卖掉,不为赚钱就是找点事情做……真假不论,反正都是无比精彩,我们又不够老道,完全被忽悠得入神了,原本一个小时的访谈变成三个小时,最后送走用户,一看访谈记录,一片空白。

要解决这个问题,需要时刻牢记访谈的目的。如果发现话题不对,就赶紧往正道上扳,多次发现扳不过来,就可以考虑尽快结束了,用户很多,不要在一个不合适的对象上花费太多时间。当然,有时候用户侃得十分精彩,如果你不是很忙的话,听听长长见识也可以,这个就自行把握吧。

第四,我们过于强势,把用户往沟里带。

原来我们团队有一位做销售出身的女生,改行做产品,新产品中负责了几个模块的设计,设计好了邀请用户来做访谈,她的故事很有趣。

  • 开始挺好的,她慢慢深入地问着,用户小心翼翼地答着。随着访谈的进行,用户渐渐地放开了,开始对产品提出自己的看法,于是砖头一块一块的向那位女生的头上抛去,只见她的脸越来越苦,然后终于忍不住了,心说“老娘当年可是做销售的,看我怎么收拾你”……接下来只见风云突转,她给用户晓之以理动之以情,指出了用户的理解有哪些不对的地方,她的产品确实很好,很值得买,几十分钟过去,不得不赞叹她的销售功底就是扎实,用户完全被说动,就差道歉了,觉得这确实是一款好产品,并且承诺说上市以后一定买。用户走后,她心满意足,回来大家一讨论这个过程,都傻了。

这个问题的对策,同样是牢记访谈的目的,并且管好自己的嘴。

我在看《软件观念革命:交互设计精髓》的时候,发现里面也讲了不少关于用户访谈的注意点,在本节最后分享给大家。

  • 避免一组固定的问题:固定的问题会让被访者产生被审问的感觉,我们应该准备好问题清单,但清单只是一个引导作用,并不用照着读。
  • 首先关注目标,任务其次:比用户行为更重要的是行为背后的原因,多问问用户为什么这么做。
  • 避免让用户成为设计师:听用户说,但不要照着做,用户的解决方案通常短浅、片面。
  • 避免讨论技术:特别是碰到一些略懂技术的用户,不要与其纠缠产品的实现方式。
  • 鼓励讲故事:故事是最好的帮助设计师理解用户的方法。
  • 避免诱导性的问题:典型的诱导问题是“如果有某某功能,你会使用么?”一般来说用户会给出毫无意义的肯定答复。
VN:F [1.2.0_562]
Rating: 5.0/5 (7 votes cast)

产品设计体会(1012)单项需求卡片

2009年2月19日

先说说理念:产品需求不止是需求分析人员的事,而是产品涉及的每个干系人的义务,至少得参与“采集”的过程,理想的状态是产品的所有干系人都参加过“需求采集”的培训,然后在日常工作中养成主动提交需求给产品人员的习惯。

“单项需求卡片”就是一种很实用的需求采集工具,一张卡片相当于需求列表中的一行,讲一个用户需求到底包含哪些内容。明确一下,需求列表一般是指未经加工的用户需求,重点是需求的各种属性;功能列表Feature List)通常是分析过的产品需求,重点是实现它的性价比。下面用一张“单项需求卡片”的实例来介绍一下(表格有点变形,凑合看哦),蓝色内容为重点,我自己也在团队里推行过这玩意。

需求编号:

包含“采集时刻 + 采集者”信息

需求类型:(在进行评审时填写)

功能需求、非功能需求……

来源(Who):(方便追根溯源)

公司提供者:需求提供者的部门、联系方式

产生需求的客户:用户需求的公司、部门、联系方式

客户背景资料:受教育程度、岗位经验、其他与本单项需求相关经验

场景(WhereWhen):

产生该需求的用户活动特定的时间、地理、环境

描述(What):

用(主语+谓语+宾语)的语法结构,禁止使用修饰语句

原因(Why):(保持怀疑的心,很多时候理由是假想出来的)

验收标准(How):

1. 用量化的语言

2. 无法量化寻找标竿

需求重要性权重(How much):

满足后(1一般~5非常高兴)

未实现(1略感遗憾~5非常懊恼)

需求生命特征(When):

1. 需求的紧急度

2. 时间持续性

需求关联(Which):

1. 人:需求关联的用户影响人物

2. 事:需求关联的用户业务与关联需求编号

3. 物:需求关联的客户系统、设备;需求关联的公司产品及版本

参考材料:

在需求采集活动中的输入材料,仅仅输入援用的条目、章节

竞争者对比:(按照1分差~10分好进行评估)

1. 竞争者对该需求的满足方式

2. 用户、客户对竞争者及公司在该需求的评价

说明:需求特征的描述,通常有如下几个维度:重要性(细分为“满足后、未实现”,或者说“基本、扩展、增值”,参见KANO模型)、紧急度、持续时间(生命周期)。实用主义的考虑,可以综合抽象为一个指标:商业价值(或者叫商业优先级)。然后除以开发量就得到了“性价比”,我们先做性价比高的需求。

VN:F [1.2.0_562]
Rating: 4.7/5 (10 votes cast)

产品设计体会(1005)用户大会

2009年1月17日

用户大会是一种常用的需求采集方法,可以短时间内从多人处收集大量信息,本篇回忆一下2007年夏天组织过的一次阿里软件网店版用户交流会。这种会耗费资源较多,一般机会不多,所以要充分利用。会议虽小但需要注意的东西都一样,按时间上分几步重点摘录如下:

会前最重要的是明确这次用户大会的目的和意义,这在争取资源的时候会更有说服力,比如:产品二期卖点确认,辅助运营决策;三期需求收集(用户怎么说);现有产品用户体验改进(通过可用性测试,用户怎么做)。

之后就是资源确定:

Ø   时间:日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段。另外注意整个活动各项准备的时间点要掐准,留余量。

Ø    地点:场地;宣传用品;IT设备;礼物食品;桌椅。

Ø   人物:工作人员(分组分工,注意PD、运营、开发的搭配,要有冗余);用户(确定目标用户、数据提取、预约,要充分考虑人数弹性);嘉宾邀请。

Ø    材料:用户数据;问卷;产品介绍材料(测试环境确保当时可用, Demo备用);可用性测试材料。

Ø   各项备用方案,定一个合适的“确认会”时间。

会议当天:

Ø   辅助工作:场地布置(轻松一点,不要像开会);引导/拍照/服务/机动;进场签到(给礼品、发问卷);全程主持(进度控制);送客/收拾残局。

Ø   主流程:产品介绍(重卖点,观察用户更care哪些);“焦点小组(需求收集) + 可用性测试”并行;合影留念。

后续:

Ø   资料整理:问卷报告;需求收集报告;可用性测试报告。

Ø   运营:活动的淘宝帖子;内部邮件。

Ø   整个活动资料的整理归档,包括照片、问卷、各项材料/报告信息、用户数据等

iamsujie补:其实很多市场活动,也就是这种会的放大版)

VN:F [1.2.0_562]
Rating: 4.2/5 (6 votes cast)

产品设计体会(1004)需求探针

2009年1月17日

需求探针实际上是一种需求采集方法,之所以写这个话题,一是因为我在做网店版的时候,有一周的的工作比较特别,就是在做需求探针

需求探针说简单一点就是打入“敌人”内部,和客户一起工作一段时间,深度了解需求。比如一个大公司要定制一套软件,软件公司就很可能派一个人去大公司那里常驻几个月,把自己当作客户公司的一员,了解一切和要做的软件可能有关的业务,这样做的目的是可以对用户需求有切身体会,看到用户平时是怎么做的,甚至自己就变成一个客户代表,而不像简单的访谈只能听到用户是怎么说的。

2007年夏天,网店版做了半年,感觉在功能设计上遇到了瓶颈。多次各种形式的客户访谈后我们发现很难再听到什么新的东西,用户说的都是我们已经知道的事情,能做的似乎都已经做了,实现不了的短期内也没有办法。所以我们决定去用户那里,自己cosplay一次淘宝卖家。

但摆在我们面前的还有一大难点,不同于大客户订制软件,我们客户有几十万,核心用户也有几万,所以存在的另一个问题就是要哪里,如果找错了方向那就会导致负面的效果了。所以之前的选客户的过程也是经历了好几次的讨论。说到这里我们发现,需求探针的成本是很高的,而且我们的产品特点决定了风险也很高,但有个哲学道理告诉我们:高风险高收益,舍不得孩子套不着狼,所以这次我们真的下了狠心,好好的研究几个礼拜,希望接下来的几个月,网店版能推出一些杀手级的功能。

(批:几个月后,因为公司战略的调整,网店版已经成功完成使命,我也转去做其他产品了,而这一周的工作,也变成一段快乐时光,哈哈)

最后说说那周的具体见闻把,我是在一个杭州的淘宝四钻卖家(现在快皇冠了吧)家里做的探针,他是卖玩具的,要做这么久接触,破冰很重要,所以之前就和对方在网上聊了很多,探的几天也算顺利,可以帮着做一些打包的工作。因为他只是一个人全职做的,所以也帮不上聊天、处理交易等事情,倒是有一个三岁不到的小男孩很闹,帮他跟孩子玩估计省了他一点心……

VN:F [1.2.0_562]
Rating: 4.0/5 (4 votes cast)

产品设计体会(1002)初探数据分析

2009年1月17日

只要你做的是一个大用户量的产品,互联网的产品往往都有这个特点,那么我们能听到都只能是少部分用户的声音,他们是否代表大多数用户是无从判断的。虽然绝大多数情况下的经验证明,只要在用户的选择上没犯什么低级失误,他们是具有代表性(接受这种假设是一种性价比很高的廉价解决方案),而还有一招就是让数据来说话,看看用户到底是怎么做的,所谓according to the data是最难被驳倒的。

其实原来读研的时候,我做的就是统计分析、数据挖掘相关的课题,但工作以来,深深的体会到,实际的生产和科研是有很大不同的。科学研究很注重“性价比”的性,只要结果好,往往不在乎投入,因为科研的结果不是为了应用(相对而言),而是为了证明实力,同理,很多公司的高端产品也是为了证明实力,并不是为了挣钱或者市场占有率。

而实际生产环境更注重综合的性价比了,所以我们不再需要用独立分量去分析每次运营、每个功能改进所带来的流量变化,不再需要用人工神经网络预测产品将来的用户数,甚至给出A>B结论的时候也不需要做显著性检验,一切的一切需要的只是一种sense,一种对数据的敏感,最商业的敏感。

要意识到,用户怎么说怎么做是不同的,其实用户的语言不如行为更能反应出他的真实需求,比如用户说在搜索客户的时候应该加一个按交易额搜索,也许只是他某次特殊的需要使然,但我们通过用户行为的数据分析可以发现,这个功能上了之后只有1/10000的人用,这就是我们被用户的说法骗了,但数据永远不会骗我们。

问题在于,手头经常是有枪没子弹的状况,其实数据分析的方法很多,但很多时候苦于拿不到数据,这是我们需要考虑的,在产品设计的时候就要把用户数据提取的需求加进去,这也是一类非功能需求,这样才能做到产品的可持续发展。

VN:F [1.2.0_562]
Rating: 4.0/5 (3 votes cast)