产品经理入门攻略(四)

上篇文章里我们一起学习了第三四章节的内容,接下来我们一起来梳理

第五章 产品设计与体验:一切为了用户

1、你写对产品需求文档了吗?

不论是产品新人还是产品老狗,PRD(产品需求文档)都是每位产品经理必须掌握的核心技能。在实际工作中,产品需求文档往往是我们向老板争取资源,推进项目进度等工作的核心基础。

【1】什么是PRD?

PRD(Product Requirements Document)是涵盖了某个产品或服务全部需求的文档。它存在的意义是为了帮助开发团队理解一个产品(服务)应该做什么?为什么做?具体怎么做?

为了解决这个问题,一份合格的PRD至少会包括以下内容:

  • 文档历史
  • 项目说明
  • 项目方案
  • 数据需求
  • 测试需求
  • 非功能性需求

基于什么样的背景,我们要做什么事情?意在满足什么用户的哪些需求?分析完需求,体现在产品上会具有哪些逻辑?交互与设计图什么样?包括哪些功能点和具体细节?如何推进项目,保证在期限内完成等等……

【2】为什么要写PRD?

明确产品需求/明确需求细节/明确任务结果

  • 存档
    规范工作流程,避免一时头脑发热,想出来的需求匆忙上线,避免不必要的损失,让情绪上的不可控,回归到理性测流程。如有新人介入,更需要尽快跟进项目,此时,PRD就有重大的参考意义。

  • 工作输出
    在写出一份完整的PRD之前,需要完成许多前置工作:
    用户:完成用户调研,用户分析,需求分析的工作
    流程:完成业务流程,信息架构,页面流程的梳理
    原型:完成需求评审前所需的基本原型,交互与UI设计图
    需求:详细的描述本次迭代中每项功能设计的工作需求
    项目:完成对项目关键目标,指标,进度的初步规划

【3】如何写好PRD

写的方面,我们需要从关联,整体,动态的角度去分析产品并输出PRD.

  • 关联,是指产品功能直接的相关性。当我们添加或改动某个功能时,要考虑该需求会对与之相关的功能点或产品模块造成怎样的影响?会产生怎样的问题?要怎么解决?
  • 整体,是指PRD的整体性,我们需要思考PRD中的每个章节与整个文档的关系。如果增加某个功能,对整体的项目目标是否有影响?对应的数据指标是否要调整?项目排期是否会产生较大变动?整体的项目流程图都需要做哪些调整?
  • 动态,是指PRD的灵活变动,随着时间的发展,PRD一定是不断变化的。产品经理需要在变动的过程中把控文档内容,根据实际情况反复优化文档的结构等等,让 PRD在产品的整个生命流程中都能高效的发挥作用。

【4】一个典型的PRD

(1)项目背景&需求分析

项目需求不是调个研,开个会,投个票就能搞出来的

  • 用户需求:哪类用户在什么场景中遇到了什么问题?体现了什么需求?我们怎样去解决?解决后具有怎样的实际意义?

  • 市场竞争:同类市场中出现了什么新的变化?为了保持现有优势需要做怎样的改变?做了有什么好处?不做会吃什么亏?

  • 技术革新:有什么新技术可以应用在产品上,让产品解决问题的效率更高?速度更快?效果更好?

如:产品当前注册流程过于繁琐,导致用户注册成功率仅为10%,本项目主要是优化注册流程,以提升用户注册的成功率。

(2)项目目标(SMART)

由项目背景推导出的具体目标,需符合SMART原则:

  • S-具体(Specific):指要用具体的描述来说明工作目标和行为标准,不能笼统

  • M-可度量(Measurable):指目标是可量化或行为化的,且验证这些目标的数据和信息是可获得的

  • A-可实现(Attainable):指目标是现实的,可行的,避免设立过高或过低的目标

  • R-相关性(Relevant):指该目标与其他目标的相关性

  • T-有时限(Time bound):目标的完成需求有时间限制,项目目标一般通过数据衡量。整个需求都应该围绕目标进行,包括优先级的排列,也需要综合考虑某需求在重要性,紧迫性,成本控制等各方面因素的限制下,能在多大程度上完成目标。

如:2017年1月1日前完成注册流程的优化,提升20%注册成功率,从原有的10%提升到30%

(3) 项目概述
这部分描述是需求的目的及功能列表,我们可以将需求设计的几方面做个表格,帮助评估设计,开发需求所耗费的时间

(4) 项目排期
项目进度时间表,又称甘特图。需要PM不断的推动,修订。PM要协调各方资源,尽力给出靠谱的时间进度,并推动按期完成需求。

一般包括字段:项目名称/项目内容/负责人/开始日期/完成日期。

(5) 业务流程图
站在产品的角度,描述产品内各类用户,任务之间的业务关系,操作顺序,具体行为,以及对应信息流向的图表。我们从定义中提炼几个关键词:角色,任务,行为,顺序

  • 明确用户和任务
  • 定义流程的起点和终点
  • 明确任务及其操作顺序
  • 描述异常情况及处理方式
  • 优化整体结构
  • 定义各步骤的输入和输出

(6) 体验流程图
是在业务流程的基础上,从用户的角度,模拟用户在产品内解决具体任务时的操作过程。

  • 基于业务流程明确任务主线
  • 明确主线中的具体面
  • 明确面中的关键元素
  • 持续优化整体结构

(7) 其他流程图
除了业务流程图和页面流程图,PM的实际工作中还会画更多的流程图,如信息架构图,泳道图,UML类图等等,都要视具体的工作场景和需求来决定是否加入到PRD中,此外,任何设计到流程的需求,PM也必须给出流程图

(8) 功能,特性简述列表

产品需求的核心部分,列表要尽量详细,每个功能点都可以单独一项,需给出优先级。

  • 功能列表:简介的描述要实现的功能点,就是用户要做什么,可按照用户场景和产品流程进行描述,如第一步,第二步…

  • 具体描述:描述某特定场景下,用户操作的具体实现过程,如随着用户的角色变化,对应表现出不同产品形态,用户每一步操作需要对应的产品功能,产品的数值变化,数值极端情况,正确和失败操作对应的结果。要尽可能考虑全面,具体,精细,可操作,易于理解。

  • 优先级:最高级,本期必须实现,中优先级,可顺延至下一期,视第一期产品表现后决定做哪些优化,低优先级,本期可以不实现或延后实现。

(9) 原型,交互视觉稿
文档中的图片和描述,应和最终开发出的界面一致。修订文档时,要上传对应的原型或交互/视觉设计稿,便于其他阅览者清晰还原需求所在的用户场景。

(10) 需求详细描述

每个产品功能,特性的详细描述,用注册功能举例

  • 功能或特性名称:用户注册流程(易于理解的)

  • 需求描述:简化原有注册流程(一句话描述)

  • 使用者:从APP Store 下载过APP的用户(什么样的用户会使用这个功能)

  • 前置需求:用户成功下载了APP,并连接了网络(这个需求的前置条件是什么?说明前一个需求对该需求的影响或者创造的条件)

  • 后置需求:该需求完成后,会对哪些需求产生影响?如 用户注册后成功后的用户引导页面,用户行为数据的检测,上报等等

  • 主流程描述与业务规则:用户主要的操作流程,及其每个步骤的规则说明。例如对Banner展示的内容进行描述,如果可以滑动操作,需要单独列出,操作前后的状态,操作后的反馈,点击图片后链接到的具体位置等。

  • 性能需求:能达到一定的性能指标,比如启动速度,产品稳定性,支持8亿用户并发使用等。

  • 其他需求

    • 安全需求:防范DDOS,拖库,撞库,SQL注入等网络攻击的措施,及应对方案
    • 风险把控:详细描述产品可能遇到的一些风险,将风险分级并制定应急方案
    • 财务需求:需要钱时,提前找财务批复产品流水与财务部分的清算及审核流程等
    • 法务需求:需要法律上的协助时,如申请知识产权,软件著作权,合成审核,永固协议等

(11) 数据需求
项目考核指标是评估项目目标完成度的重要标准,在项目策划的前期就必须制定:

  • 访问量
  • 转化率
  • 留存率
  • 日/周/月活跃用户
  • 产品订单收入

这里必须说明每个数据指标的含义是什么,通过公式告诉大家具体是如何计算的
PM要与工程师沟通明确具体要上报哪些数据字段,有报表需求的,也要用excel画出需要查看的报表,需要统计图的,说明需要什么类型的图形,柱状图,折线图,饼图等等。

(12) 测试需求
PM需要在PRD里描述各个具体场景下的一些需要关注的主要测试点,以保证产品质量。如果有专业的测试(QA),PM只需要给出一些方向即可,如没有,则需要撰写更为详细的测试用例。

(13) 非功能性需求
非功能性需求,主要指产品功能之外的运营需求,客服需求,财务需求等等。也要根据不同公司的具体业务量,业务场景,业务需求等具体情况来判定。

一般的运营,都会考虑:拉新,留存,活跃,回流等运营策略,对于一些小的功能优化,可以在 PRD中省略。客服方面,用户的直接反馈对产品的迭代也非常有价值,可做参考,优化产品。

(14) 附录
对于十分复杂的项目,PM可以把PRD中引用的相关文档统一整理在附录中,进行统一的注释。一份优秀的PRD,结构上有清楚的逻辑,层次分明,背景描述的清晰详尽,流程图一目了然,明确定义工作目标,并讲清楚具体要怎样达成。另外文档的维护上,每次变更内容时,都要有一个SOP(标准工流程),确保PRD在整个产品生命周期中可以连贯的承接。

(15) 争取资源
这个资源,是指公司或团队内部的资源,争取一定的人力资源或者财务预算。让项目能够立项。此时的PRD,相当于你给老板的一个初步规划,目的是获取资源上的支持,文档的内容会更侧重于项目说明中的背景和可行性分析,具体的项目目标,项目能给公司带来的收益或潜在收益,项目所需的人力和财务成本等等…

(16) 需求评审
需求评审,可以是所有项目关系人聚在一起开会评审,也可以是PM和程序员两个人坐在一起沟通需求。

(17) 项目推进
如果你成功争取到了需要的资源,通过了评审,这里PRD所解决的问题,主要在需求的沟通和变更两个方面。

推动项目,需要及时跟进工程师,设计师等成员的工作进度,期间所有重要的进度变动,都需要整理到PRD中,并用邮件或其它工具周知相关人员,保证项目能按时完成。

(18) 小结

What:涵盖了某个产品或服务全部需求的文档,帮助人们理解一个产品(服务),应该做什么?为什么做?具体怎么做?
Why:解决团队写作和管理中的需求,沟通,存档问题。同时也是PM个人的工作总结输出。
How:从关联,整体,动态的角度去分析产品并输出PRD.

2、没有技术背景,怎样写好PRD

【1】写PRD的大体思路是怎样的?

  • 不忘初心
    无论提交一个新的产品方案,还是思考页面上一个按钮的位置,你都要时刻提醒自己在做这件事的目的是什么,是增加活跃,提高停留时长还是增加购买的转化率?很多情况下,不同的方案都是隐藏着不同的前提假设,很多无效的争论,原因就是只纠结于方案的细节,却忘记了这两种方案基于是不同场景假设和用户假设的。

在前提假设没有统一的情况下,争论的唯一作用就只是练口才而已。

  • 调查 PRD的用户需求
    PRD的用户就是看文档的人,所以我们应该去问技术,去问测试人员,去问设计师,他们在看PRD时的需求点在哪里?他们更看重什么?更喜欢什么样的表达方式?他觉得哪些地方要改进?

  • 重视PRD迭代升级
    和产品一样,PRD也是有迭代的。
    迭代时,多听大家反馈,比如大家都讨厌大段大段的文字,所以可以拆成小功能点来描述,并用序号标出,这样更加清晰一点。某个功能点和其它模块有关联时,一定要标明。

【2】写PRD时,怎样考虑的更加全面一点?

没有技术背景的PM,需要多总结遇到的坑。

  • (1) 前置条件
    描述页面显示为此种状态的前提条件,比如,QQ的群管理员和普通成员点击同一个按钮,进入的页面就可能是不同的。
    前置条件可以概括为:某种用户角色(要提前准确定义APP中的各种用户角色),在某种情况下,点击某个页面的某个按钮,进入此页面。

  • (2) 退出机制
    如何退出此页面?常见的有:左上角返回按钮,返回上一层。按手机返回键(安卓)也返回上一层

  • (3) 显示机制及排序机制

    • 描述页面上有哪些控件,展示了哪些内容
      想象你和一个陌生人介绍这个页面,选择一个能有逻辑的描述这个页面的方法,比如从上到下,从左到右,从重点到一般,从特殊情况到普通状态等

    • 当页面需要展示很多内容时,就要考虑排序机制了
      按照哪些因素进行排序?是按时间倒序,热度正序,推荐的内容排顶部?还是其它更加复杂的排序方式?还要考虑一页显示多少条信息,以什么方式进行展示?翻页展示还是瀑布流?

  • (4) 刷新机制
    一次刷新多少条信息?如何刷新更多?自动刷新还是手动刷新?当刷不出来新内容时给什么提示?
    常见的手动刷新方式:右上角有刷新按钮,点击手动刷新。
    常见的自动刷新:再次进入此页面时刷新,设定一个时间值,每隔一段时间自动刷新一次。

  • (5)缓存机制
    这个页面要缓存哪些数据?缓存到哪里?清理缓存的时机是什么?定时自动清缓存,还是用户手动清理?

上面的5大机制,可能在一个APP中,很多模块都是一样的,为了避免重复描述,建议在PRD的最开头,用一个单独模块来描述,以后在描述页面时,一笔带过就可以了。

(6) 控件描述
建议用一个单独的模块说明应用内常见的控件类型以及每个控件对应的操作方式,在其它模块设计此控件时,只要简单阐述一下就OK了。

  • 触发源:
    此控件的触发区域是哪一部分?同时思考,需要频繁触发的控件,操作区域是否明确?
  • 触发时:
    触发控件时常见的状态有:加载状态,读取状态,缓冲状态。比如视频播放应用,点击播放按钮。
  • 触发后:
    触发控件后常见的状态有:操作进度显示(例如:点击下载按钮,会显示下载进度条)/按钮发生变化/结果提醒(常见的提示类型:小红点提示,自动消失,文案变化等)
    常见的结果类型有:成功/失败/空值

(7) 异常情况描述

  • 异常操作:比如,连续多次点击,是否给予反馈
  • 网络状况:没有网络时的提醒?是否需要网络超时,网络太慢,从wifi切换到3G/4G提醒?
    *
  • 账号相关:登录和未登录时,对此按钮的操作权限是否有差别?如果必须登录状态下才能操作,就要增加登录提醒,如果同时支持ios和安卓,那账号是否互通?
    *
  • 数据相关:要定义页面的默认状态,默认状态就是进入页面时,如果从服务器获取不到数据时,页面的显示状态,考虑此时,是否要内设置默认图片
    *
  • 版本相关:版本的命名要规范,考虑版本是否强制更新?如果提交市场审核,版本上线时间要把考核时间考虑进去

(8) 其它

  • 是否设置启动页和引导页?
  • 应用内文案是否需要做相应调整?
  • 是否需要进行埋点,以便分析用户行为?
  • 消息推送的策略是什么?调用系统通知还是第三方?
  • 需要硬件交互么?需要请求GPS,相机等的使用权限吗?

3、PM如何深度思考需求?这里有十步法

引用猎豹CEO傅盛的认知三要素:信息的输入,思维模式的训练,最后判断

【1】需求从哪里来?

大的抽象方面:用户研究,定性分析/定量分析

定性分析:用户访谈/焦点小组/实地调查/可用性测试/眼动实验/用户博客/评论等(最后用户博客/评论这种方法来源于腾讯1000/100/10原则)

定量分析:行业调查报告/调查问卷/数据分析/AB测试

竞品分析:有市场分析/用户分析/功能分析/数据分析等方向。真正指导思想可以按《用户体验五要素》那本书的分层方式:战略层/范围层/框架层/结构层/表现层作为分析方法的指导方向。

小的具象方面:
用户A:我希望产品上加上XXX,这样就能解决XXX问题量了…
同事B:我习惯性这样使用产品…
老板C:我觉得他这个产品功能很好,我们能不能做…
业务方D:我要做这个需求,这个功能很棒…

【2】思考需求面对的用户是哪些?

产品成立之初,就是有特定的用户群定位。

比如小米手机的初期定位用户就是手机发烧友,打的就是性价比,种子用户并不是KOL用户,但是他们的消息可以覆盖你的种子用户,比如美食产品,找一些旅游达人,让他们帮助传播一些美食产品的消息,这样就可以覆盖到我们的种子用户。

思考你面对的用户,就是在对于你的产品用户进行一次初期画像过程,比如你的用户年龄,从事职业,爱好,特征等等,

俞军:用户不是人,是需求整合

【3】思考需求发生的场景

人,行为,场景三者重合的过程。

比如打车软件需要考虑的场景就是:位置,确认,联系

【4】人与场景的需要与需求
关于人性的思考,究竟这个需求发生的需求是什么?生理需求?安全需求?情感归属需求?尊重的需求?自我实现的需求?

比如用户在地铁上看电视剧,经历了几个心理过程。首先,打开手机是为了打发无聊的时间,本质是落在情感归属上的需求,然后其实有看新闻,聊天,看电视剧等多种选择。然后,如果有事情要说,就聊天,但是今天没有想要说的话,恰巧我坐的地铁时间需要1个多小时,那么不如看电视剧吧,打开XX视频。

在这个过程中,第一个情感上归属,第二个是根据心理,时间,空间等多种条件的结果。在这个过程中,其实像微信,新闻类产品,视频类产品都是泛竞品关系,而第三个是需要看电视剧时,视频类产品竞争的关系。

【5】思考需求来源的动机
在人与场景的需要和需求连接过程中,我们需要思考需求来源的动机是什么?需求的本质是什么?

需求的本质是动机,而不是需要。思考用户的动机,而不是他说要什么,因为他想要的可能是伪需求,并不能真正解决他的问题。

上方第一版块讲到需求来源时,提到不同角色的需求,该如何考虑呢?
A类问题的解决方案是:这问题本质是什么?是更快还是更好,或者是解决什么问题。了解用户本质需求点,转化一种交互实现方式。

B类问题则是同事站在他自己的习惯上,所以,解决方案就是多找几个用户或者竞品去分析不同的用户行为,从而找到一个合理的解决方案

C类问题比较棘手,因为竞争对手的功能与我们产品不在一个纬度上,所以别从竞争对手功能出发,而是要理解竞争对手的功能出发点,最后做出决定。因为我们不会比他们想的更深,因为我们是从表层去考虑他们,而不是本质。

D类问题要从自身的产品说,不能从业务方的战略出发,而是要思考具体需求,潮流决定方向,这才是战略,用户决定需求,具体需求要结合场景。

张小龙:潮流是什么?潮流是为了让人不落伍,是比性还重要

【6】要用同理心

试图理解他人,产品经验最重要的是同理心。

【7】用户潜在心理
用户潜在心理,是对于一个事物的认知过程,从时间上,有一个认知过程,就像我们对于AI人工智能认知是不同的,加上我们自身的经验和角度问题,造成认知的不同。我们往往与用户不在一个认知层面上,那就导致需求理解的偏差。

从物理空间上,我们本身能力决定了购买力和生活方式,而这些限制用户心理上的思考程度。所以用户潜在心理并不是简单的无聊这么简单,而是要从时间和空间上理解,这样思考是符合用户心理变化过程。

举例:女生在学生时代可能只能用几十元的化妆品,但是毕业工作后,会用几百上千的化妆品。这些对产品使用人群都是有变化的过程,所以用户潜在心理是在一个变化过程。

【8】产品定位的需求

产品定位的需求要活在未来。基于未来的需求做产品设计,把缺失有趣的东西做出来,这些产品需求才是兴奋型的需求。

在需求池中挑选需求进入决策阶段,考虑可实现性,核心诉求点是什么?是否满足我们的战略目标?

在做移动端产品需求时,一定不是简洁,而是简单。一个界面,一个主题。回归本质:不要让我思考,这是我们做界面简洁的时候一个思考方向。

【9】核心功能的内在联系

解剖一个伟大的产品,做产品正确的思维顺序

骨骼:产品的结构来源于对受众的理解

肌肉:最重要的几个功能分别是什么

血液:其它功能与核心功能的关系如何串联

皮毛:功能和使用流程每一处的细节

产品经理核心价值一定在于产品的抽象能力

简单的秘诀就是抽象分类。找出各个功能的共性,寻找用户的认知痛点,感受用户的文化水平,特别在需求决策阶段我们考虑SMART原则,考虑具体,可度量,可实现性,相关性,有时限。

业内大拿提出的2个公式:

  • X(超预期)>Y1(用户预期)+Y2(转移成本)
  • 做的事情有价值>新版体验-(原用户体验+成本)

【10】产品亮点往往是对于一件事深入思考

紧急重要四象限法则,KANO模型(满意度,具备度):

  • 必备型需求
  • 期望型需求
  • 魅力型需求
  • 无差异型需求
  • 反向型需求
    考虑开发成本时,需要进行需求性价比思考。

可行性的MVP(小而试行型)产品找到PMF(产品和市场)的契合点:商业价值与
用户需求

怎样让用户记住你?有趣!

4、产品设计的原则

做任何事情都存在道和术,对于产品经理而言,道指的是做产品设计的原则,过往的经验提炼及思考问题的方式,术指的是做产品的技巧与规划方法等。

【1】设计的目的性
产品为用户所解决的核心问题是什么。各种业态的产品都会有一定的竞品可以参考,但是同一领域的竞品也会有不同的侧重点,不可一股脑的抄。

【2】心理预期模型
当我们使用手机拍照后马上打开微信对话框的加号时会提示“你可能需要发送的照片”,这是一个非常符合客户心理预期的设计。

【3】产品的边界性
边界是会扩散的,随着产品被赋予不同的使命而向外进行更多的扩张。互联网这个瞬息万变的行业也是一样,我们可以采用控制边界的方式来引导我们产品的发展走向,阶段性的目标要清晰,边界要明确。

【4】情感化设计元素

著名的产品设计师唐纳德.A.诺曼,把情感化设计这个概念具象为本能/行为/反思三个不同水平的设计。

  • 本能:外形的联想,人对外形的观察和理解是出自本能的,如果视觉上设计越符合本能水平的思维就越容易被接受

  • 行为:产品的使用乐趣和效率,对于工具类产品来说讲究效率,用完就走,使用产品是一连串的操作,因此能否有效的完成任务以及过程是否愉悦是行为水平需要解决的问题

  • 反思:表示我们常说的认知和思考,与用户的长期感受有关系。它通过理性的思维和逻辑推导帮助我们建立与用户之间情感的纽带,通过互动影响了自我形象,满意度,记忆等,才能形成对品牌的认知,培养对品牌的忠诚度。

  • 【5】风险控制思维
    遇到一些产品规划上的问题,多思考“这么做有什么风险”,最大化的规避能预知,已经看到的风险。

5、七条产品设计原则

  • 易学性
  • 美学一致性,完整性
  • 输入方式更简单
  • 做好反馈:过程反馈/结果反馈
  • 内容为先
  • 为停止做准备:不要做死胡同
  • 减少用户出错

6、原型设计,你不知道的事儿

【1】原型为谁而画?
原型的本质是用来沟通,如果是给客户或投资人看,越逼真越好,只是给开发小伙伴看,越敏捷越好

【2】原型工具的选择
市面上的原型软件很多:Axure/sketch/mockups/mockpuls/墨刀等。
设计高保真,设计很多复杂的交互逻辑,细化到像素的尺寸设定,Axure比较好
仅仅看效果展示,界面的排版等,墨刀此类工具更高效。

【3】用最快的速度画原型

  • 元件选择(把轮播图,模块框,弹窗等元件组好,直接使用)
  • icon选择(推荐www.iconfont.com)
  • 默认组件自定义(更改为适合自己的)
  • 母版的应用

【4】用原型制作PRD
PRD的优点在于描述更细致,不会遗漏,方便之后的查阅,缺点在于描述过于抽象,传阅也不方便
原型的优点在于演示充分,易理解,备注及时,缺点在于过于分散,不易被发现

PRD来详细描述需求和用例事件,原型更多用来及时说明和效果演示。

【5】原型的版本控制

【6】原型里的技术
前端技术多了解

【7】Axure制作文档备份

7、三种不友好的注册登录设计

  • 注册登录按钮放到一起且权重几乎相同
  • 没有保存用户在输入框的输入数据
  • 使用第三方登录后仍需要用户填写很多个人信息

END =。=