您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
从需求分析到产品设计
 
作者:呆木子程 来源:简书 发布于: 2017-6-26
来自于要资料   132 次浏览     评价:      
 

从需求分析到产品设计

需求是产品创造或是迭代的重要根据,没有真实且详细的需求,就很难开展后续的工作;但如何让需求从无到有?如何判断已有需求的真实性和可行性?如何让众多需求有条不紊的落地执行?这一期我就结合自己的工作经验,尽量总结一些接地气的解决方案。由于行业经验并不多,有对工作处理不当的问题还请老师多多指点。

另外,我在这里举的实际例子基本都没有呈现最终的效果,最终的效果希望读者多思考或者欢迎找我交流。

第一部分主要讲我需求搜集过程中遇到问题以及处理方法。

一.需求搜集

工作中我貌似遇到过这样的问题:当产品新版本已完成了迭代,但是一段时间过去了,还没有收到用户的任何反馈,我进入了需求空白期。那我是怎么度过这段尴尬的时期的呢?我总结有四点:

1.深入用户内部:

这一点比较容易实现,你需要的只是和用户深入交流。交流的方式有很多,我常用的方法之一是在QQ群或是微信群里以聊天的方式和用户交流(当然,选择这种方式的前提一是我有多余的时间;二是和用户混的熟)。通过这种方式很快能得到反馈,而且还能够立即验证,对我来说很实用。用户关系维护起来也很方便,成本低效用大(有机会再单独总结下我对用户运营的认识)。但这种方法的缺点是用户受客观因素影响比较大,产品经理在判断这是否是用户的真实核心需求有一定的难度,所以这就要求产品经理得根据产品方向,建立自己独立的需求分析能力,不被用户牵着鼻子走。

和用户聊产品改进

我喜欢而且常用的第二种方法是焦点小组。但受限于地理位置,所以我们也都是线上交流。具体方法是找一个运营伙伴召集4-5个忠实用户成立讨论小组,晚上抽一个半小时的时间单就某一个功能分享使用体验和改进建议。集中精力头脑风暴,不要贪多,一次只做一件事,做到极致。这种方式的代入感很强,能让大家积极参与。8月份到现在我有了3个固定的讨论小组(都是我号召同学朋友组建的,不单单讨论我们自身的产品,还有其他类型的产品)。至于对小组的回馈也很简单,有条件的一起聚餐K歌爬山郊游看电影等都是可以的,没条件的就红包感谢一下。当然,这种小组讨论要注意几点:

a.有专人进行话题引导,节奏把控,不乱扯不跑题;

b.有专人记录,记录要准确完整清晰;

c.有人活跃气氛;

d.总结。

对于产品功能体验改进这块一直都是我在负责,所以abd都是我自己在做,至于c可做可不做,混熟了自然就不用活跃气氛了,如果不熟,那就先斗图吧。最后关键的半小时用来总结,总结一定得到位,主要是大家拿到记录后再次讨论延伸分析,再去判断可用性与可行性;小讨论需要给出结果,大讨论需要给出方向。

这种方式的缺点是久而久之,用户的产品理解能力增强了,他们不再是简单的用户,甚至成了专家,这样一来,你搜集的需求就有些局限了。

除此之外,调查问卷也是我们常用到需求搜集方法;鉴于效果欠佳、时间和成本压力,用户访谈则很少用。从用户那里搜集需求的方式太多了,重要的是要学会融会贯通,具体问题具体分析。

2.细分产品计划:

很多人跟我说这一点很难做,细分产品计划到什么程度?怎么从计划中提取到具体的需求呢?其实这一点做起来很简单,主要是理解计划。比如我在8月份接到大领导的计划:“建立用户互动关系,提升用户存在感设计。”

看到了吧,重点就这一句话,非常的不详细,但是计划就长这个样子的,大领导只会给你建立目标,具体要怎么实现那是你的事。再次了解平台现状后,我大致写到这一步:

建立用户互动关系

用户存在感设计

当然,这并不是最细致的,但鉴于一些因素,我就到此为止,不往下具体写了。

3.尊重数据:

这是最科学的一点。不管是问卷调查获得的数据,还是通过后台监测到用户的行为数据,都是对用户的想法和操作最直观的展现。关键数据还是这几个:日活、月活、跳出率、增长率、留存率、转化率;我在后台随便截取了几篇文章的浏览数据:

文章浏览数据监控

对于以内容为主的平台来讲,这几篇文章的PV(访问量)和UV(独立访问)相对来说都是很低的。

下面的截图里展示了这几篇文章的评论、态度、收藏和分享量,也是超级低的。后来我们在平台上选取了更多的数据,转化成百分比,算出了平均每个操作按钮的使用情况,之后又通过观察跳出率和用户在页面上留存的时间,由此推断出导致平台文章浏览数据和操作数据极低的原因一是因为平台内容质量差,二是因为按钮操作不方便。

用户行为数据监控

找到了问题所在,我们就开始着手处理问题,一方面要求编辑提升内容质量;另一方面产品以“提升功能操作便利性”为需求点,简化评论、分享的流程;对操作成功或失败积极给予反馈提示;调整评论列表的排序方式;打通多个分享地址等操作,之后数据才有所提升。

至于具体的数据分析方法,我也正在学习中,希望可以和大家一起交流。

4.自我驱动:

最后一个搜集需求的方法是自我驱动。简单来讲就是要你自己不断学习,不断接触新东西,这里主要有三点:一是行业分析,二是竞品分析,三是自身产品分析。这一部分因为涉及的范围比较广,所以必要情况下需要和领导及其他部门协作交流。

以上是我在工作中用到过的需求搜集的方法,深入用户内部主要是从外部搜集需求,而细分产品计划、尊重数据和自我驱动主要是从内部搜集需求。需求搜集的方法有很多,但哪些方法和公司、和产品是比较对口的,这个还得产品来把握。其中也涉及到很多知识,例如竞品分析、数据分析和用户运营、跨部门沟通等,这就要求产品经理要神通广大,永远保持积极向上不断学习的心态,随时准备好面对各种考验。

二.需求分析和需求评审

第二部分主要讲需求池整理和需求评审。

一般我的需求池是以excel的形式呈现的,偶尔也会在word上直接处理。不管以哪种形式呈现,需求池整理的几个纬度总是不变的。

1.理解需求:

在整理需求之前就得完全理解需求,说白了就是理解这个需求是要在哪种环境下(where),让什么人(who),达成什么目的(what);

2.需求分类:

理解透了需求就给需求分类,一般我的类别就是功能类、优化类和bug,再细致一点就是前端和后台(有的产品经理分的很细致:功能类,数据类,运行类,体验类,设计类,这个根据公司情况而定)。根据实际情况判定出需求的优先级。下面这个用户反馈表是我刚来的时候弄的,现在看来还有很多需要改进的地方。

excel汇总需求(分类、分优先级)

这个是编辑部门直接发word文档给我的前端后台的任务都分的很清楚;然后我在理解了需求之后还是按照我的三个类别进行整理,由于是小需求,所以整理之后我就直接处理了。

用word呈现需求样式

这是处理之后的需求确认表和PRD目录,简单处理了下。

需求处理完毕

3.需求评审办法:

需求评审是确定需求的关键。KANO模型是我们常使用的需求评审的方法:

KANO模型定义了三个层次的用户需求:基本型需求(必须有)、期望型需求(渴望有但并非必须)和兴奋型需求(出乎意料的),可以对应马斯洛需求层次来理解;

KANO模型

在实际的应用中,一些功能是会随着时间的变化而变化的,比如编辑部门提交过来的网站发文的第5条需求,在之前我们可以对文字设置超链接;但是现在我们有了更好的处理方式,即设置按钮点击跳转,这样整个界面看起来会更整洁,所以就没必要为文字单独设置超链接了;再举个形象的例子就是:在几年前翻盖手机很流行,对用户来说几乎是很期望的,而且是很必须的。这就需要我们考虑到每个功能的使用场景以及我们的产品定位,从而对他所属类型进行讨论。最简单的就是问卷调查了,做这个功能和不做这个功能分别会怎样。一般的问卷形式是这样的:

a.我希望这样

b.我预期这样

c没有意见

d.可以忍受这样

e.我不希望这样

或者针对某一种做法,设置问卷选项为12345进行选择;如果问卷验证效果不佳,那就采用A/B test吧。使用A/B test时,需要客观对待测试过程,不要让直觉推翻了你的测试结果,更不要为了测试而测试。限于公司的研发资源,在不得已的情况下,我们才使用A/B test。

还有常用的方法就是专家法和pk法。遇到评审不了的需求,那就找更高级、更权威、更专业的人来拍板决定;或者现场投票表决,少数服从多数。

三.业务逻辑梳理

需求定了之后,我不会很着急的去画原型。而是去回顾一下这个需求产生的前因后果以及它的使用场景,前端需要突出哪些功能,需要后台怎么去配合响应等。这时候需要流程图和思维导图,不过需求小的话我一般都在草稿上完成了。

比如第二部分的板块2中有提到“新增文章状态提示”的需求,那我就要想一篇文章从发表,到提交至后台审核上线或下线之间,会有哪些状态呢?我就在草稿纸上写写画画。这个是草稿上最初的流程图(草稿比较乱,我就照搬到电脑上了),最初想的也比较复杂,考虑到研发部门的压力比较大,后又经过测试,就和需求方沟通了之后,做一些精简。

简单梳理业务逻辑

即剩下待审核、审核中、已发布和已下线四种状态;那在待审核状态中还会遇到用户再次编辑、再次提交审核的状况……业务如果出现了交叉,思路就会有些混乱,必要的时候还是要画流程图。

业务逻辑梳理清楚之后,再动手去设计产品原型。

四.产品设计

这一部分主要讲产品设计原则。

至于说设计工具,恩…我在工作中常常是根据需求主题的不同,交换使用工具,常用的有Axure,mockplus,和磨刀。工具只是一种表达方式,只要能展现出你想要的需求形态即可,以简单好用就行,不要太沉迷于此。重点是设计原则,以下是我总结的几点:

1.以产品定位为依据

清晰的产品定位是行动的标杆。产品的定位是社区,那就按照社区的属性去设计;产品的定位是商城,那就按照商城的属性去设计;产品的定位是媒体资讯,那就按照媒体资讯的属性去设计…至于说各自的属性是什么,竞品会告诉你的;通过竞品分析,了解竞品的产品设计特点(包括功能设计特点和UI设计特点等),有数据反馈是最好的。并不是说是抄袭,毕竟学习行业里已有相关产品,总比你自己关起门来从新开始要更便捷。

2.理解用户—以用户为中心

a.理解用户的使用场景

产品常说的用户使用场景是什么呢?打个比方,就好比我(23岁,职业女性)每晚20:00下班回家后洗洗刷刷完毕会敷面膜,敷面膜的时候想做点不动脑子的事情。考虑到看视频比较不费脑子,于是我就打开了bilibili看看动漫,打发一下时间。

用户场景里包含了用户基本特征(23岁的职场女性),使用产品的时间(晚上20:00-21:00)、地点(家里,有WiFi)以及使用产品的心理活动(想放松自己,打发时间)。

所以在做产品使用场景描述的时候,需要搞清楚这几件事:

a)目标用户群体(性别,年龄,职业身份,收入等)

b)日常行为习惯和心理特征

c)生活环境

d)如何使用产品及获得的信息

e)完全换位思考

b.理解用户的懒

少让用户猜,少让用户想,少让用户动手。

c.理解用户的好奇心

典型的就是:弹框不要打断用户的其他操作。

3.多想,深入设计

a.宏观层面上多想:多去想想你的产品整体架构,产品的信息传达,产品业务所覆盖的范围;

b.微观层面上多想:主要功能是否足够突出?功能是否过多过杂以至于找不到特色功能?按钮摆放是否合理?界面/功能交互是否恰当?颜色搭配是否合理?…

产品的宏观就好比条条框框,规范着微观层面的设计,免得异想天开。

4.基于常规的设计逻辑,远离反人类

a.推荐尼尔森十大交互设计原则,很实用,大家可以在网上搜一搜,我就不啰嗦了。

b.做产品设计也和ppt设计一样,也需要遵循对齐统一、去繁从简的原则;

c.iOS和andriod的交互设计规范。

5.始终建立业务闭环

产品设计完毕了,就按照业务线跑一遍,有始有终,直至跑通了为止。

尝试建立业务闭环

6.输出便捷的原型文档

这个根据公司相关人员的需求和实际设备而定。但不管输出什么样的原型文档,自己一定要做好备份。

   
 订阅
  捐助
 
相关文章

谈产品运营
产品运营的思路
互联网产品:死于方向,毁于节奏
马化腾:灰度法则的七个维度
 
相关文档

网络游戏产品运营基础介绍
腾讯产品运营思路方案
互联网产品运营PPT(第一课)
产品运营策划书
 
相关课程

产品经理与产品管理(互联网领域)
产品管理与产品研发管理
面向产品的需求分析与管理
产品发布、推广与应用支持
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号