首页  思维导图  详情

产品方法论

2020-05-21 10:41:14   1  举报





AI智能生成

产品方法论（吐血整理，推荐收藏！）

产品

产品经理

方法论

作者其他创作

大纲/内容

作者：思兼

搬运 by A小蚊子丨ID：xiaowenzileyuan

想了解更多，欢迎关注公众号“A小蚊子（xiaowenzileyuan）”，更多精彩内容、知识大礼包等你发现。

欢迎将此文分享给更多朋友，大家共同精进

理论体系

什么是方法论

方法论的必要性

方法论的积累方法

通过定向学习积累

工作技能的重复锻炼

通过职位级别的经验积累

学习积累与工作技能超过前职位级别一个层次，可以适当的扩宽视野

专业知识

以用户为中心

自己是核心用户

大量的重复的研究竞品

深入一线了解其他用户的需求，实际体验相应业务，交流沟通用户

不要为了1%的用户去影响99%的用户体验

质量比数量重要

对活跃用户的关注远大于对新增用户的关注

生于拉新，死于留存

关注长期利益

更多的是不同部门之间的博弈

不要为了眼前的利益而牺牲长久的规划

拼死维护用户的利益，不要干损坏用户利益的事情

产品的用户分析

用户反馈

通过用户反馈发现问题

发现产品自身的问题

发现竞品的问题

发现可能的机会点

通过哪些渠道发现问题

公开渠道

应用商店／微博／贴吧等

应用商店监控什么

以下包含主要竞品和自己的产品

重点关注低分差评

关注有效的高质量评论

异常行为，刷单或者恶意评价

竞品的变化，竞品的版本更新以及对应的用户评价

主流社交平台关注什么

以下包含主要竞品和自己的产品

微博关键词监控（可以使用微博企业版）

百度和百度贴吧的产品关键词监控

在百度搜索的时候用“site:tieba.baidu.com”将关键词范围控制在贴吧范围内

勤搜索／关键词订阅／使用监测工具等

半公开渠道

朋友圈／微信群

定期搜索关键词／定期分析用户评论

对于用户的点评主要关注什么

差评：差评的原因是什么？能否改进？如何改进？

描述：重点看有使用场景描述的反馈

其他用户的异常行为

内部渠道

用户投诉／电话录音／客户记录

整合反馈渠道，定期与一线同事沟通

用户调研

用户调研五部曲

明确调研目的

本次调研的背景，在什么情况下发起的调研？是否已定是必须的？

本次调研的目的，通过本次调研想要的结果？一定是具体的内容

选择目标用户

典型用户—目标用户—邀约用户—控制调研用户的数量

挑选典型用户可以用用户画像做基础匹配

从典型用户中缩小范围，选定目标用户，可以预留备选名单

一定要告诉目标用户本次调研的时间／地点／目的等内容

控制调研用户的数量以保障调研的质量

分析用户问题，准备调研内容

事先猜测用户可能会问的或者出现的问题

针对这些问题事先给出解决方案

确定用户调研的提纲和问题

控制好问题的数量，不宜过多

问题有两个维度：本品／竞品，已知问题／未知问题

问题重要性排序：本品已知，本品未知，竞品已知，竞品未知

针对已知问题，重点追问产生此问题的原因

针对未知问题，尝试给出解决方案并看用户反馈

开始调研

了解用户使用过程，观察用户的行为

提问提前准备好的问题，全程记录

无法现场回答或反馈的重点记下

有效问题进行深入探讨和了解

输出调研反馈

以单个用户的调研结果为单位输出内容

将所有用户调研结果以问题维度进行汇总并整体分析和输出结论

制定行动计划，确定要做什么，不做什么

用户画像

产品生命周期

探索期

迅速寻找产品的种子用户并完成用户调研与产品需求

快速开发MVP，核心功能迅速体现

将MVP投放种子用户进行试用并收集反馈

围绕核心功能快速迭代，验证需求的正确性

成长期

需求通过验证，核心功能与产品形态基本固定

将带有成熟核心功能的产品投放市场

为产品引流，导入更多的新用户，用户数量迅速积累

成熟期

产品用户的增长速度逐步放缓

开始拓展产品的其他附属功能

衰退期

产品用户开始逐步流失

产品设计功能转移用户的注意力，尽量延长此阶段的时间

正常的产品一般都会符合这个发展趋势，但是也会有各种各样的变形形态

产品线规划

接手已有产品

基础了解

融入进度

工具

JARA

流程

问升晃

部门规划和资料

白皮书

基础数据

统一语言

实际演练

两周后对外输出想法和计划

工作范围

内部配合

干系部门

行业情况

近年行业头部公司上市招股书

公司内共享资料

向业务同学了解

行业报告库查询

项目背景

项目最初创建的原因

项目目的和目标

项目开展过程中的变化

产品定位

解决哪部分用户在什么场景下的什么问题

定位是否有变化，定位的变化过程

产品现状

直接负责产品和干系产品，包括用户端、商户端和核心系统

用户端

业务逻辑

页面

功能

流程

场景

商户端

核心系统

商品信息

电商类产品特有，指电商平台售卖的商品信息

售卖的商品也会体现出产品的定位

从商品信息推断目标用户的部分画像

电商需要实现产品-商品-用户匹配，也就是PMUF，在此基础上需要实现市场-产品匹配，也就是PMF

用户画像

用户来源渠道

用户和流量从哪些渠道进入产品

例如通过搜索/社交广告/付费投放等

不同渠道来源的用户，进入产品的心态和目的不同，因此需要在落地页进行区分

目标用户画像

产品在初期定位时，会定义目标用户画像，是期望产品能够沉淀的用户类型

为吸引和沉淀目标用户，需要匹配相应的推广渠道、产品人格气质和运营方式

实际用户画像

在产品发展过程中，产品实际沉淀的用户类型

用户画像偏差

在产品发展过程中，目标用户和实际用户可能会存在一定的偏差

导致偏差的影响因素可能是定位偏差、推广渠道偏差、某类型用户口碑传播导致等

用户偏差可能会反向影响产品定位，甚至会修正产品定位以匹配实际用户

用户触达渠道

可以通过哪些渠道直接触达到用户，例如短信/EDM等

需求情况

负责需求的情况

未开始的需求

需要了解需求的背景、目的和需求干系人

需求内容的设计，需要在掌握干系产品的功能、页面和流程的基础上进行规划

需求进度的设计，需要在掌握研发流程、干系人和研发资源的基础上进行规划

进行中的需求

需要了解需求的背景、目的、内容、进度和需求干系人

进行中的需求，尽量交给最初规划人跟进上线。如果不能，应在需求进行过程中以了解为主，按照既定流程完成上线，尽量在此过程中避免需求变动

干系需求的情况

需要了解与自己负责的需求有干系的需求的情况，主要指干系需求的内容和进度

所谓的有干系，主要是指在页面、流程和功能上，可能会有耦合导致的相互影响，应当在需求规划过程中一并考虑，并给到解决方案

需求管理

研发流程

流程

流程的核心点是识别干系人，确保信息统一

在相应的环节，需要识别干系人，保证干系人的参与

在核心交付件上，需要保证上下游环节的信息统一，不出现信息偏差

需求内容

解决方案

设计稿

线上产品

需求部门的需求确认节点

需要在提出需求部门的内部进信息拉通，避免重复提出需求或需求冲突

产品部门的需求确认节点

产品接到需求后，需要在产品部门内部同步消息，以识别出干系需求

所谓的干系需求，就是在页面、功能和流程上可能会有相互影响的需求

如果有发现干系需求，需要将干系需求的影响一并考虑

解决方案在产品部门确认节点

产品规划解决方案，并在产品部门对解决方案进行评审，确定并统一解决方案

如有需要，进行调整

解决方案在需求部门确认节点

解决方案确定后，需要与需求提出部门确定解决方案，确定并统一解决方案

如有需要，在不影响功能的基础上进行调整

需求预研评审节点

如果需求较大，涉及功能较多，可以增加预研评审环节

评审解决方案中的核心的流程和功能，以便让研发评估可行性和困难点

预研评审核心干系人是开发和测试

需求调整、确定与信息同步

预研评审后，如果有需要调整的，对解决方案进行调整

并将调整信息同步到需求方，并说明调整原因

确定最终的解决方案

需求正式评审节点

解决方案最终确定后，完善解决方案的细节，进行正式的研发评审

正式评审环节干系人是运营、产品、设计、开发和测试

确定开发计划和预估发布时间

评审最后，确定预估的开发计划和发布时间

开发计划涉及到设计时间、前端后分离开发时间、前后端联调时间、测试时间、最终发布时间

转设计——设计中

设计根据原型进行设计

此时后端开发可以同步开始做服务端和接口

此时测试可以同步设计测试用例

设计稿评审节点

设计完成后，进行设计稿评审，干系人是设计、产品和需求方

设计稿调整、确定与信息同步

根据设计稿评审结果进行调整，并二次确认

最终定稿

转开发——开发中

设计定稿后，转前端开发

前端后分离开发完成后，约定时间进行联调

转测试——测试中

联调完毕且开发自测通过后，转测试

流程功能测试+界面视觉还原

测试根据测试用例完成功能测试

设计根据设计稿完成视觉还原

测试和设计将问题反馈给开发，开发进行处理

测试完成，转产品体验

测试完成且BUG均关闭后，转产品体验

产品和需求方对产品进行体验

体验过程中，非BUG类的，尽量避免功能类型的调整

产品体验通过，发布上线，线上验收

产品体验通过后，可安排发布上线

具体的发布顺序由开发自行决定

发布上线后，在线上进行验收，确定没有问题后，此需求可关闭

工具

运营逻辑

运营思路

转化目标

转化方式

业务逻辑

业务思路

业务目标

实现方式

核心数据

行为数据

业务数据

未来规划

短期

中期

远期

创造新的产品

产品核心定位

某个用户在某个场景下，遇到了某个问题

已有场景

X坐标：用户

Y坐标：场景

Z坐标：问题

核心定位开始的时候是一个点，但随着产品的成熟，甚至产品生态或矩阵的形成，XYZ坐标会不断变化，因此产品的定位会从点变为线面体

可以给用户提供什么服务，不取决于企业能够提供什么服务，而是企业的用户需要哪些服务，从获取增量用户演变为存量用户需求的深入挖掘

企业之间已经进入无边界战争，企业定位和边界不断模糊，也就是定位的XYZ坐标不断变化，从之前的定位点演变成了定位线面体

即使定位是线面体，也需要有一个更高维度的定位点，可参考美团的定位演变

创造场景

用户有时候不知道自己想要什么

需要将产品呈现给用户，用户才能知道

提供解决方案，解决以上问题

产品或功能的本质就是解决方案，解决方案已经限定了用户、场景和问题，也就是产品的核心定位

不从竞品中寻找需求，但可以从竞品中寻找解决方案

问题是相对固定的，而解决方案是多样化的

产品提供的价值

主价值：能够解决问题本身就是主价值

辅价值：提升效率？提升愉悦性？或者其他

目标用户画像

产品人格和气质

设计产品生命周期

探索期

成长期

成熟期

衰退期

需求获取

需求=现实情况-理想情况

需求分为刚需和非刚需

用思维导图／头脑风暴梳理用户的所有需求，然后再进行删减

以用户／场景／需求三个维度进行梳理

这三个也是产品设计的核心三要素

将梳理出来的用户需求进行排序

以需求影响的用户量，需求的使用频率两个维度进行排序

高用户量高频率-首先满足大部分用户的基础体验，也是基础稳定性

低用户量高频率-满足良好的体验

高用户量低频率-建议好的产品口碑

低用户量低频率-产生超预期的体验

以需求的开发难度，需求实现之后的效果两个维度进行排序

开发难度低实现效果好

开发难度高实现效果好-优先考虑的是实现之后的效果，此维度与用户体验直接挂钩

开发难度低实现效果差

开发难度高实现效果差

以对此需求的付费意愿，需求开发迫切程度两个维度进行排序

付费意愿高迫切程度高-迫切程度指的是用户对此需求需要的迫切程度

付费意愿低迫切程度高

付费意愿高迫切程度低

付费意愿低迫切程度低

两个维度确定需求优先级的时候，与用户利益挂钩的维度永远放在第一位

从数据分析中挖掘需求

利用互联网产品给用户带来微笑价值，在这个过程中产生商业价值，同时也产生产品数据和商业数据

商业数据模型（收入模型）

收入=用户数*付费率*arpu值（单个付费用户产生的价值）

arpu值=平均客单价*单位日期内平均购买次数

产品数据模型

产品指标：流程／页面（衡量产品质量）

转化指标：复合指标，与产品和用户的质量都有关

用户指标：行为／动作（衡量用户质量）

用户流程=数据建立的模型

利用用户使用产品的操作流程来建立数据分析模型（例如转化率漏斗模型）

用户流程指的是用户使用流程和用户操作流程

数据分析的作用

明确分析的目的，建立思路和方法

围绕核心业务流程与重要结论完成分析

将用户核心流程转化成数据分析模型，并将此模型唯一化和细致化

业务反馈或老板提出

需求管理

需求管理的一个表单——需求池

需求池分为两个表格，一个是待开发需求，一个是已经纳入开发计划的需求

待评审需求包括的字段

需求所在产品

需求标题

需求内容

需求提出人

需求提出时间

需求优先级（1-5来进行表示，必要时用需求截止时间来代替优先级）

备注信息

纳入开发计划的需求字段包括

需求所在产品

需求标题

需求内容

需求状态（包括规划中、实现中、以实现、已暂停和已关闭）

需求归属版本

备注信息

需求沟通会

需求沟通会一定是围绕需求而展开，需要避开其他话题

不在需求沟通会上讨论并确定具体的实现方式

常规情况下，需求沟通会分为两个部分

同步需求池的当前状态

当前待开发的需求X个。已纳入开发的需求X个，其中已实现X个，实现中X个，分别是XXXX，规划中需求X个，暂停和关闭的需求X个

针对状态需要变更为暂停和关闭的需求，将相关信息同步到需求方，并说明原因

从需求方收集新需求，讨论通过后纳入需求池

需求方提出新需求，并陈述此需求出现的场景，以及为什么要满足这个需求

针对需求进行讨论，主要集中在此需求是否合理，以及是否需要纳入需求池。对于纳入需求池的需求，需要定义需求的优先级排序

给出最终结论：本次需求沟通会收纳新需求X个，分别是XXXXXX

需求文档与原型

需求文档与原型尽量统一为一份文件，在表述清楚诉求的前提下，提升设计和开发的阅读和理解的效率。因此可以用原型工具完成原型的制作和文档的撰写，图文并茂的展示方式与图文分开的展示方式相比，更容易被设计开发接受，阅读和理解原型文档的效率也更高

原型文档包含的内容

基础信息

项目背景：项目产生的原因，是在什么情况下，出现了什么问题，而这个问题有需要以什么方式被解决，所以才有这个项目的成立

立项时间：项目正式立项的时间，一般以项目立项会和立项通知时间为准

项目人员：参与此项目的人员名单，包括需求方/业务方/产品/设计/开发/测试/运营等人员，并需要确定各模块的leader，以便后期做决策支持

项目目的：做这个项目是为了达到什么目的

项目目标：目的的可量化指标，如果不能量化，先保留相应内容

项目范围：定义项目组所做事情的范围，避免有项目范围外的需求掺杂进来

重要里程碑：项目的重要时间节点和重要完成事项

修订记录

时间：原型文档出现修订的时间

修订内容：原型文档出现修订的大致内容

修行人：提出问题或需求导致原型文档修订的人员

产品规划

功能结构：产品的功能结构图，以较为抽象的金字塔状进行表达。主要是说明白产品包含的具体功能点有哪些，以及这些功能点在产品结构中所处层级的位置，以便初步预估功能点开发的工作量，功能开发的先后顺序，以及功能之间的耦合关系

页面结构：产品的页面结构图，以树状图平铺的方式表述产品包含哪些页面，以及这些页面之间的层级与跳转关系，另外也可以标注哪些页面是有可能有流量的初始进入

版本规划：产品迭代版本的记录，每个版本迭代的时间以及版本所包含的内容。一般用V X.X.X进行表示，第一个X表示的是大版本的概念，第二个X表示的是中版本的概念，而中版本是归属于相应的大版本，第三个X表示的是小版本的概念，归属于中版本，大部分是做的一些小的优化调整

主要流程：产品内部设计到的较为复杂的流程和判定，用流程图来进行表示，方便开发人员理解

原型文档

原型

原型的保真程度，由原型的使用场景来确定

如果原型的主要作用是给到业务方或需求方进行详细的演示或汇报，则尽量使用高保真原型

如果原型主要用户设计研发测试的内部评审，中低保真即可，高保真原型反而会对设计造成干扰

原型的保真程度，需要与设计共同来定义，因为原型大部分是给到设计做参考而使用。前端开发多依赖设计稿，而后端开发大多会抛开原型图而注重文档

原型上需要表明的页面的结构以及逻辑，页面的信息点和元素。页面各模块的具体布局，视觉颜色，信息点和元素的具体排列则不用原型表示，更多依靠设计稿呈现

原型上元素信息的视觉和交互的优先级需要体现出来，或者单独标注出来，以便设计师根据优先级进行页面的设计，优先级可以用以下方式表示

颜色差异，颜色深浅，饱和度高低，冷暖色系等

大小差异，包括元素大小和字体大小

字体是否加粗

元素信息的排列，呈现F形

元素和信息是否增加动效

文档

文档描述的内容以

数据需求

需求分析

业务与运营需求

确定目标，以及目标的关联指标

将关联指标拆解为质数指标

质数指标是指无法再拆分的指标

质数指标最好是用户的可触发行为指标

确定质数指标的目标调整方向

罗列可改变质数指标的用户场景，也就是用户在什么场景下会做出这些行为

脑暴法

象限法

分类法

对场景进行分析，评估场景的发生的可能性、成本和预期收益

根据场景，确定方案思路和框架

根据方案思路和框架，确定方案的干系功能、页面和流程，并进行补充完善

用户需求

产品调研

如何做具体功能点的调研

最重要的是明确功能调研的具体目的

找出功能调研的核心问题

此功能的使用者有谁（用户）

用户为什么要用此功能（需求与场景）

此功能如何使用（具体流程）

找出能够体现调研功能质量的数据表现

找出代表性数据

查看历史数据的具体表现

调研的功能对自己产品的参考性如何

要不要抄，用户群是否符合

能不能抄，有无技术壁垒

最终的结论是什么，是否跟进

功能调研的误区

调研之后没有结论

不愿意做功能调研

调研的内容太杂乱，不够聚焦

非要给调研产品提出改进意见

只从产品的视角看产品，而不从用户的视角看产品

如何做独立产品的调研

找出调研产品的核心功能以及核心满足的需求

一个产品永远只有一个最核心的功能，其他功能都是附属

研究用户，场景，需求是如何被这个产品满足的

有哪些类型的用户

在什么场景下使用

满足了哪些需求

调研产品的整体逻辑

用户流向

在这个产品中有几个类型的用户，他们如何在这个产品中发生关联

数据流向

各种类型的用户和操作带来的数据如何产生，流转，储存

用户与数据的汇合点

用户与数据（广义数据，非数字类数据，可以理解为信息）在哪些点汇合以及如何汇合的

核心功能使用的关键路径（最短路径）

调研产品最核心功能的不可删减的使用流程

调研产品迭代的路径

历史功能迭代的过程

调研产品的表现如何

数据表现：评分，排名，专业数据

用户表现：用户点评，评论，传播口碑

调研产品的运营路径与方法

待定需补充？？？

产品调研的误区

产品调研不是行业调研，不需要分析行业大背景

产品调研有具体的目的，提前规划调研需要给出的结论性质

产品调研大／全／空（行业调研／产品调研／功能调研区分明确）

带有强烈的个人倾向，需要以客观实际情况为基础

二三手数据一般不能够证明结论的正确性

多个同类产品如何调研

找相同，找不同，各三点

关键核心功能存在的差异性

给出结论

同类产品对比之后的优缺点

如果要抄，抄哪个，怎么抄？

如何调研第三方产品是否可以被我采用

明确想要采用产品之前的根本目的，这个比功能全面更重要

目标—这个产品拿来是做什么的？

成本—如何自己重新开发，能用和好用付出的成本如何？

关联性—第三方产品与待完成的目标有多大的关联？

其他—价格／服务等是否靠谱

功能调研与产品调研的区别

功能调研的重点

具体功能的业务逻辑

具体功能的交互体验

突出具体功能的亮点

产品调研的重点

注重产品历史功能的迭代过程

注重产品的整体结构

注重产品的运营逻辑

产品或者功能调研的意义

照妖镜—通过对产品核心功能德调研，看产品整体的表现

透视镜—通过观察功能迭代的过程，看产品实现的逻辑

放大镜—透视一个产品，看穿一个行业

产品设计

三个核心

产品设计的三个核心内容

用户

什么样子的用户，最好能够描述用户的画像

场景

在什么样的场景下，也就是故事产生的背景

利用记叙文四要素，时间／地点／人物／事件

需求

遇到了什么样的问题，为了解决这个问题，需要什么样的解决方案

满足什么用户在什么场景下的什么需求，以满足此需求产生的解决方案叫做功能

一个功能封闭或者多个功能组合就是产品

功能设计

功能优化与功能设计的区别

反应速度不同：优化的反应速度快于设计的反应速度，优化的见效速度更快

开发难度不同：一般情况下，优化的开发难度低于设计的开发难度

评判标准不同：

已有功能的优化

分析已有功能的现状与逻辑

用户：使用这个功能的的用户是哪些人

流程：功能的主要流程是什么

逻辑：功能实现的底层逻辑是什么

分析已有功能存在什么问题

现象：哪些用户在什么样的情况出现了什么样的问题

原因：出现这些问题的原因分别是什么

影响面：这些问题出现的频率与受影响的用户面多大

如何解决已有功能存在的问题

找出关键点：已有功能出现的问题中，最关键的点是什么

罗列多种方案：围绕这个关键点，罗列所有可能的解决方案

开发难度评估：评估各种方案的开发难度与预期收益

确定最终方案：综合评估，确定最终的解决方案

功能优化的效果如何评定

确定考核指标：确定功能优化对应的考核指标

做出数据对比：功能优化前后的数据对比差异

其他补充内容

功能点优化是最基础，最频繁，最有效的工作

不要期望用新增功能来解决老功能的问题，更多依靠功能的优化来解决问题

针对功能点的不断优化就是对产品的迭代，就是对用户体验的负责

完整功能的设计

所有产品都是由一个个的小功能构成

产品经理需要做好功能

产品早期，以功能为主，产品成熟后，以迭代为主

完整的功能，是经过简单评审之后提交给研发

如何做一个功能点

明确功能的目的

对用户：这个功能对哪些用户有好处，会影响到哪些用户

对内部：对内部数据，操作人员是否提升效率

对商业：提升收入还是提升转化率

对内讲效率——对外讲体验——对商业讲转化

明确功能的基本流程

确定功能的基本逻辑

用户操作流程

数据流向过程

实现此功能的难点可能是什么

调研相关的产品功能

明确调研的目的

观察调研产品的功能是否满足“用户，需求，场景”

制定功能方案

罗列所有可行的解决方案

梳理每个方案简要的业务流程

针对性分析，选择最合适的方案

评估开发难度，实现效果，使用场景符合程度

方案细化

原型设计与文档撰写

开发上线

运营推广方案

找位置：用户关键路径在那里

定内容：拼配用户与场景，将内容加入此场景

要效率：运营转化效率如何，后续的计划是什么

业务流程的设计

业务流程图是什么

产品设计的过程文件，类似于建筑图纸

产品设计，其实就是流程设计

凡是产品设计，必须有流程图

做产品就是做流程

流程图方便做交接

可以快速了解业务是如何运作

明确产品的优化与收益，设置考核指标更合理

产品设计中，业务流程的作用

业务流程是功能优化的基础

独立功能设计的基础

独立产品设计的基础

产品原型交互设计的基础

基本业务流程包含什么

事项：完成的事项是什么

用户：有哪些人参与进来

信息：流程中会产生哪些数据，数据如何流转

异常：出现的异常问题如何处理

如何画流程图

明确用户与任务

明确流程的开始与结束

明确事项发生的先后顺序

设置异常情况病给出异常处理流程

优化调整

最终输出

制作流程图的技巧

主线清晰

先主后次

优化调整

先繁后简：先把最长的路径确定，之后再考虑合并

多想，多看，多画，多交流

流程设计

流程设计相关总述

流程设计相关的内容包含页面结构图／信息结构图／操作流程图

什么是页面结构图

是交互设计／原型设计的基础依据

突出页面的重点内容与页面之间的逻辑关系

什么是信息结构图

突出产品包含的所有信息之前的逻辑关系，包括但不仅限于包含／上下级／并列等关系

什么是操作流程图

突出用户操作时的交互信息／逻辑判定／页面跳转之间的相互关系

页面结构图／信息结构图／操作流程图的区别

页面结构图重点页面之间的逻辑关系，信息结构图重点是信息之前的逻辑关系，操作流程图重点是用户操作前后的判定逻辑关系

操作流程图是用户视角看流程运转，页面结构图和信息结构图是以产品视角看相应的页面和信息

什么是页面流程图

将页面结构图与操作流程图合并之后成为页面流程图

既包含页面之间的逻辑关系，也包含用户操作引导下的流程运作和页面跳转

用页面流程图即可表达最重要的页面逻辑关系和用户操作流程

页面流程图如何设计

梳理业务流程，明确主线，以此为依据设计页面流程

页面流程来源于业务流程，是业务流程的具体化和细致化，因此梳理产品的业务流程十分重要

页面流程一般是业务流程中的方形（代表事件和页面）部分

异常流程一般是弹层或者弹窗

业务流程梳理的好，页面流程相对简单

明确页面中的重点元素

明确有哪些元素需要在页面中重点表现并最终在页面上给予表现

增加异常流程的处理逻辑与相应的页面

增加辅助说明的页面

考虑下游的触发点

沟通与优化调整

穷举页面，再做减法

手绘原型草图，优化调整

利用草图与UI/UE/前端开发多沟通

原型设计

什么是产品原型

简易的手绘线框图

虚拟需求的概念到实际可接触的界面

UI/UE/RD参考的重要资料

可视化的产品解决方案

制作原型的工具

纸和笔

纸和笔（表达迅速／直观／成本低，可淘宝购买带有手机界面的白纸用于原型绘制）

具体工具例如Axure/墨刀等

什么是好的原型

整体

页面结构清晰

跳转关系明确

与业务流程表达一致

完整的表达用户需求

独立页面

功能元素明确有序

元素位置关系清晰

不同状态变化清晰

如何进行原型设计

需求文档+流程+手绘草图确认，这三项完成之前不动Axure

认真研究流程图

确定页面流程图与页面结构

确定单独页面的交互细节和元素关联

确定单独页面的所有显示状态

讨论迭代，细节修正

原型设计的好习惯

原型进行修改是因为需求未完全封闭

可以先进行手绘，确定之后再上软件

用真实的比例和真实的文案

原型不要上颜色

原型目录树清晰，阅读流畅，勤于编号

有原型修改的log，重新保存新的版本

紧扣需求主题，不横生枝节

增加新功能，先考虑后端的数据来源

文档撰写

需求文档是什么

产品与技术和设计沟通需求的重要工具

说明需求的背景，包括为什么做这个功能，如何做这个功能，功能做成什么样

主要的内容包含需求说明，流程说明，交互原型等

需求文档的作用

团队内部沟通

让需求的描述和功能的设计更加完整清晰有逻辑

存档，方便产品的交接（新接手一个产品最重要的是阅读需求文档）

需求文档用什么写

WORD为主，AXURE为辅

需求文档如何写

需求更改的log

说明产品和需求的背景

说明功能列表

说明功能流程和所处的产品模块

详细功能的介绍

简要测试用例介绍

功能的考核指标与计算方法

高颜值需求文档的特点

逻辑清晰，层次分明，团队标准化

描述需求的背景

业务流程+页面流程

目标清晰，算法清楚

文档变更过程清楚

项目管理

产品保证做正确的事情，而项目保证正确的做事

产品需求评审

什么是需求评审

由项目组所有成员参与，将产品原型与需求文档拉通评审，提出各部分意见并修改，之后确认开发功能的需求和原型

项目组内部统一思想并明确需求与原型

一般情况下需要几次评审方能通过

为什么一定要做需求评审

所有人明确需求的背景和目的

统一思想与实现的过程和方法

参与者明确知道工作内容和交付时间

评审开发周期并进行评估

如何组织成功的需求评审

确认需求／文档／原型是否完成且无误

提前小范围沟通，消灭大问题

确认所有人的可出席时间

提前发出会议通知，并附上原型和文档

勤于表达练习

评审现场的控场

抓大放小，有节奏和条理，记录重要争论点

需求背景——用户与需求——功能模块——讲流程——说明原型与交互——说明数据考核指标——说明需要的支持——预估上线时间

评审会后的总结

整理遗留问题

发出会议记录，包含问题的行动计划

发出修改之后的文档，并更新到内部的系统中

约定下次评审的时间

上线邮件撰写

什么是上线邮件

描述产品研发过程，上线结果，经验总结的通件

为什么要写上线邮件

对产品研发的过程做记录，并总结本次研发的经验，用一封长邮件编写

对项目在上线之后的工作做推动，主要是推动其他部门准备做上线之后的相关工作

团队的润滑剂，对项目团队的相关人员进行感谢，给项目参与者给予正面回应

好的上线邮件的特点

标题

标题直接与直白，简单明了

模版：（上线通知）：xx产品+xx版+xx版本上线通知（时间）

在标题中可以大致描述此版本更新的卖点和相关的变动

内容

描述此版本开发的背景，可以包含用户／需求／场景，和需求的由来

描述此版本研发的过程，提前or延迟上线

列出此版本更新的功能清单

数据对比，如果意境运行一段时间，最好给出关键指标在上线前后的对比

版本上线之后的后续计划，包括自己负责模块的后续计划和他人负责模块的后续计划

感谢其他同事的支持

上线前后工作

上线前的准备工作

查：是否满足上线所需的条件

核对上线清单

回归测试，核心功能与流程是否可用

bug list是否清空，一二级bug是否处理完毕

上线时间是否准备完毕（提前选择合理的上线时间）

产品的冷启动工作是否准备完毕，主要是内容是否填充完毕

产品文案是否明确无异议

运营上线物料是否准备完毕

使用文档／帮助文档是否准备完毕

应用商店的描述图片／更新描述文案是否准备完毕

产品帮助中心的文案是否更新

推广物料

渠道是否确定以及是否正确

推荐

推荐为独立的系统，大多是结合运营需求、当前用户历史数据和所有用户历史数据，综合后进行推荐相应内容

推荐的场景和内容较为多元化，可以是产品、广告、关键词等，涉及的页面可以遍布全站

如首页推荐，用户这次购物流程还没有任何行为，所以一般都是通过该用户的历史行为向用户进行推荐

如详情页推荐，用户则已经表现出对于这个商品的较强的需求，推荐和该商品类似的商品或可以和该商品进行组合的商品

行为记录分析

独立的大型系统，记录和收集用户在网站的各种行为数据，包括浏览、输入和点击，进行计算分析后给出相应的结果

对于已登录用户，将行为数据与此用户的帐号关联。对于未登录用户，将行为数据与当前的Cookies关联

搜索组成模块

搜索系统的各模块，最好实现架构上的分离，减少系统模块间的耦合，方便对各个模块进行单独的优化和改造

搜索的使用场景

用户使用搜索的目的

计划搜索

精准搜索

这种场景下用户目标清晰明确，通过各种功能直奔主题，快速找到目标，完成本次搜索的任务

粗略搜索

没有精准的目标，只有粗略的范围，根据搜索结果的反馈，逐步缩小范围，最终找到目标，完成本次搜索任务

无目的搜索

用户不知道自己想要什么，通过 “搜索” 启发自己灵感，很多搜索页面中有 “精心安排” 的信息

为迎合这类用户需求，搜索页面一般有热门搜索的关键词、搜索类目、记录

临时搜索

在用户浏览某些内容的同时，受到内容的激发，临时“迸发” 出的念头，于是使用搜索来完成本次搜索任务

临时搜索中也包含精准搜索、粗略搜索和无目的搜索三种方式

精准搜索和粗略搜索用户以快速找到目标为目的，而无目的搜索用户则以消费内容为目的

搜索前-搜索功能的入口

是否需要搜索功能

数据较少，不建议使用搜索模块，搜索召回的商品数量和内容少是搜索的噩梦

数据较少，利用预分类和条件筛选，提升用户的寻找商品和内容的效率

不要轻易给到用户搜索功能，一旦给到，就不要期望用户不使用

搜索入口的位置

放置在页面的左上角、右上角、侧栏边，最好能与业内大部分产品保持位置的一致，有时做前置处理

与大多产品的搜索功能入口保持一致，减少用户的理解成本，想要使用时，可以快速找到搜索入口

做前置处理，是为了满足用户在浏览页面时随时会发起临时搜索的需求

如果搜索在用户场景和业务需求中位置十分重要，可以将其单独呈现，作P0级处理

在移动端底部的Tabbar会有单独的搜索入口和搜索页面

产品默认的落地页第一屏是大幅的搜索入口，甚至是单独的搜索页面

有时候搜索入口会与其他功能入口排列在一起

搜索入口的排序就需要根据用户场景和业务需求来定

搜索入口的样式

常见的搜索入口的样式是搜索ICON或搜索栏，需要综合用户场景和业务需求来判定使用哪种

也有做交互，默认展示ICON，点击ICON后变为搜索栏

搜索入口的模式

普通型

搜索是对所有商品进行搜索，也就是综合搜索，不区分类别

如果商品数量较多，品类综合，流量大，用户意向分散，使用普通型搜索模块即可

指定型

只针对指定的类别进行搜索，也就是在某个类别下进行搜索

商品数量较多且品类单一，采用指定型搜索模块，例如图书馆，也就是说用户在图书馆里面的任何搜索，结果都应该是书籍相关

搜索时-搜索功能的使用

高级搜索

用户在搜索前已经有非常明确的目标，在搜索前就快速的缩小搜索范围，减少搜索结果的数量，提升搜索的效率以便快速完成目标

辅助输入功能

语音搜索，主要适用于在移动端，当用户的输入不方便时，可以通过语音输入搜索的内容

图片搜索，主要适用于当用户有产品的图片，但是不知道或者不方便用文字描述产品时，可以根据产品的图片来搜索，且搜索的准确性相对较高

单独的搜索页面

比较常见的是在移动端

当前页面空间不足，不能在当前页面展示更多内容时，会采用单独的搜索页面，能够呈现更多的内容和信息

分类搜索

当网站产品类别较多时，提供此功能，可以让用户选择自己要搜索的产品类型，缩小搜索结果的数量，提升搜索效率

关键词提示

作为一种运营资源位，可以根据运营的需求或者用户历史数据，展示一些关键词

对应运营来说，可以给重点推广的活动引入更多的流量

对于用户来说，根据用户的历史数据推送关键词，期望能够提前预判用户期望，以提升寻找产品的效率

默认填充关键词

应用的场景与关键词提示基本一致，以满足运营需求，或者对用户需求的预判以提升寻找产品的效率

展示的视觉优先级和专注度优于关键词提示

历史搜索记录

记录用户的历史搜索记录，当用户要搜索时，优先展示给用户，期望能够命中用户的需求，以提升用户寻找产品的效率

提供搜索记录删除功能，主要是为了方便用户清楚记录，不被其他人看到自己的搜索记录

关键词预测

当用户输入部分关键词时，能够给用户一些关键词的预测，期望能够命中用户的需求，以提升用户寻找产品的效率

当用户只能记住要搜索产品的部分名称，输入这部分内容，可以预测出来全称，期望命中用户的需求，提升寻找产品的效率

关键词改写

搜索后-搜索结果的呈现

有两种信息的呈现形式

当前页面展示

在当前页面展示搜索结果的页面，内容较简单，主要目的是为了让用户进一步点击选择，使得搜索的结果可控

这种情况下常以列表形式平铺地展现信息，相关地二级标题或按钮会结合搜索结果同步露出

这种情况下，很多时候键盘地 “搜索” 按钮是禁用的或者键盘的设计无搜索按钮

新开页面展示

当需要展示的内容有不同属性，如列表、图、图文结合或更多的其他形式，则一般采用新开页面的方式，信息的展示也需要做分层处理

信息的分层包括每个单元内信息之间的对比、强调和弱化

不同单元和属性的信息间优先级展示以及展示方式的区分

当搜索无内容时，我们给用户什么？

用户分为主动和被动

主动的用户这时候会做什么？或许会重新发起一次搜索，输入更加精确的关键词、提交报错或反馈，这类用户总会找到他想做的事情

而对于被动的用户，我们就应该去了解他，投其所好。如相似度和关联性推荐、热门推荐、可能喜欢、搜索历史等形式

有时候用户对于搜索结果并不满意，我们可以在页面上做结果页展示的补偿方案

如让用户进一步明确搜索词，缩小搜索范围，如通过分类和筛选功能

引导用户在应用可支持的范围内进行搜索

用户寻找信息依赖的路径

中心路径

在消费者有充分的动机、能力和机会时，才会使用中央路径

边陲路径

通过此路径的态度转变和思考无关

用户购买决策评估

补偿性评估

浏览一个商品，再看下一个商品，对每个商品建立一个大致的心理打分，意味着商品的属性优势劣势可以相互补偿

非补偿性评估

先找到想要的属性（如手机的价格），然后拿属性去筛选商品

连接性捷思法：为不同属性选择一个最低标准，所有属性都通过这个最低标准为第一选择

词典捷思法：选择最重要的属性得分最高的

搜索的关键指标

搜索功能使用率

搜索页UV（搜索点击UV）/DAU

搜索页转化率

搜索结果页UV/搜索页UV

搜索结果点击率

单品点击UV/搜索结果页UV

没有永恒的固定答案，而相对正确的答案都在每一次的具体业务中

搜索功能使用率越高，说明健康程度越高，一般电商的搜索功能使用率可以超过50%

随着消费升级和内容电商的崛起，这个定律也在变化，因为用户的行为慢慢的产生了分离。原来用户访问电商的意愿更加倾向于buying，也就是单纯的消费商品。现在用户的buying和shoping的目的分离，用户访问目的不再仅仅是消费商品，也消费内容

订单系统

订单系统的模块

设计产品架构时，应充分考虑到业务发展需要，尽量将各模块隔离

由于商业性质决定了电商业务支撑系统必须具备稳定性、可扩展、安全性强等特点

在产品设计上有模块化思想，具有前瞻性，技术在开发时才会考虑业务隔离。当业务调整、功能新增时，开发可迅速进行，避免牵一发而动全身

最核心最难做的三部分：商品、订单、库存。商品与店铺、营销、评价等相关，订单与会员、营销、支付、库存、物流等相关，库存与订单、采购、WMS、营销等相关，系统之间业务逻辑和交互异常复杂，规则多样

商品中心（强关联）

主要管理SKU(最小库存单位)、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据

订单中心（强关联）

管理订单类型、订单状态，存储关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作

支付中心（强关联）

调用第三方支付平台接口，记录支付信息（对应订单号、支付金额等）

会员中心（强关联）

主要管理用户等级、用户权益、积分、卡券等会员相关信息；

调度中心

将订单信息转化为发货通知单，调度仓库和物流进行发货

客服中心

主要管理退货退款、售后服务等操作，包括呼叫中心、在线客服等，与之对应的是工单系统，将客服任务进行队列管理，分配给相应的客服

营销中心（强关联）

管理活动相关，优惠券、满减、专场活动、促销专区等，营销工具的开发对电商尤其重要

运营中心

是对用户端进行页面配置（Banner、ICON、TAB）一般会营销中心并入运营，作为其一部分

评价中心

管理商品评价和用户反馈，这并没有想象的那么简单，涉及到一些敏感词和敏感图片的筛选，以及回复内容管理

店铺管理

功能庞杂，相当于提供给B端用户一个Saas管理后台，提供管理商品、营销、订单一系列功能，主要针对一些有to B业务的电商开放平台

采购中心

管理SKU，当库存预警时，及时生成采购单进行入库，有供应商管理模块，主要进行供应商管理评级，发展新供应商等功能

财务中心

主要和订单、采购系统相关，数据准确性要求较高

WMS系统

主要是入库、出库、盘点等模块，WMS主要和调度中心进行数据交互，反馈出入库状态和库存变动

物流中心

主要进行运费模板、运费管理（前端订单、真实物流成本）、物流状态保存查询（快递100、菜鸟等关联），如果是跨境电商，还涉及到和海关总署的对接，进行报关操作

风控中心

主要利用大数据进行用户信用建设、反欺诈，避免恶意评价、刷单退款等操作，构建安全的电商购物环境

订单系统的体系

用户层

用户日常会使用的与订单相关的功能和展示

页面展示例如订单列表和订单详情

功能则是指用户可以对订单进行的任何操作，例如取消订单、申请退款等

系统层

核心的是支付系统和订单系统

支付系统主要是完成用户对订单的支付操作并将支付信息传给订单系统

支付系统一般为独立的系统，与订单系统不存在耦合关系，通过接口进行数据交互

底层模块

主要包括商品、支付、用户、营销、订单和消息等模块，这些模块共同组成了对上层业务、系统的支持

一般情况下将各个模块独立系统化，之间通过接口进行数据交互，方便后期维护

订单系统的字段

其实呈现在界面上的订单信息，都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整

商品信息

店铺信息

商品名称

商品规格

其他信息（不同行业有所不同）

商品数量

商品单价

商品标签

订单信息

订单状态

订单的前后端状态可进行分离，在后台显示的状态并不一定是用户在前端页面看到的状态，但是需要有对应关系

订单状态分类型，每个类型都有自己相应的状态列表，因此一个订单会存在多个类型的状态，但一般在用户端统一展示一个，需要提前定义好

在电商中，无论是买家端还是卖家端，都会将交易主状态分为待付款、待发货、待确认收货、交易完成，但是买家端与买家端的展示逻辑稍有不同

买家关心的状态无非就那么几个，即待付款、待发货、待收货和待评价，所以淘宝并未像商家端那样将全部的状态一一罗列出，而是保留了买家最关心的状态，保持整个买家端的简洁性

买家端，主要解决的是商家效率的问题，所以在订单列表中会将所有的状态（即待付款、待发货、已发货、退款中、需要评价、交易完成、交易关闭）的订单全部列出

订单主状态

新建

新建已取消

待确认（有些订单自动确认）

预订成功

预订失败

已取消

支付状态

未支付

部分支付

已支付

支付超时

退款状态

申请退款中

同意退款

拒绝退款

已退款

退款失败

取消状态

申请取消中

同意取消

拒绝取消

物流状态

待出库

已发货

运输中

配送中

已签收

评价状态

未评价

已评价

审核状态

待审核

审核中

审核通过

审核失败

状态机

状态机的概念是用来表示按照一定的方向通过触发不同节点产生数据流转的过程

在订单中通过情景触发订单状态的变化来表达订单流转的过程就是订单状态机

状态机原则上使用结果值而不使用过程值，比如使用支付成功作为节点而不使用支付中作为节点

需要设计好各种订单状态变化的节点，以及变化前后的状态，组成状态机

节点有用户操作触发、商家操作触发、时间触发等多种触发方式

节点的定义一定要清晰明确完善，不能存在任何不确定因素

不同类型的业务，状态变化节点不一定相同，需要根据具体业务来确定

当状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况

推送对象（用户、物流人员、商家）

推送方式（push，短信）

推送节点（状态机）

订单编号

订单编号的设计原则

不重复

安全性

不使用大规模随机码

防止并发

这条规则主要针对编码中有时间的设定，避免毫秒级订单出现重复

控制位数，满足多方需求下，尽量短

订单号尽量保持为纯数字

如果有字母，尽量放在首位，并且代表特殊的含义

订单号是用来标记/查询订单（查询的时候可能更关注于物流单号）用的，一般会在订单有支付/售后/异常问题的时候会用到，也就是说订单号主要是拿给客服/运营/开发部门用的，用户使用到订单号的时候，也一定是将订单号反馈给这些人

订单号中最好避免数字以外的其它字符类型，订单号尽量短，如果过长，可以进行分段处理，例如银行卡号

可以做的人性化一些，支持WEB上双击复制，或右击选中订单号，或APP上长按复制

订单号尽量能结合当前的业务情况有特定的标识

将重点信息转化为一种数字标识加入订单号中，方便出现问题的时候，可以通过订单号就知道相应的信息

例如下单平台、下单渠道、支付方式、业务类型、下单时间等，具体根据公司业务情况来定

推荐的订单号规则

特定标识+下单日期时间（可到微秒毫秒级别）+流水号（或小范围随机码）+用户ID

时间信息

订单创建时间

订单支付时间

订单确认时间

订单取消时间

等等时间

订单状态机的变化时间

用户信息

用户ID

用户姓名

用户地址

联系方式

电话

邮箱

其他

付款信息

付款方式

付款时间

商品金额

其他金额（例如运费）

优惠金额（可细分）

应付金额

物流信息

承运人

运单号

运费

预期送货时间

发票信息

发票类型

发票抬头

发票开具内容

订单系统的功能

订单拆分

订单拆分的影响因素

店铺不同（不同店铺、自营与非自营等）

仓库

物流公司的相关要求

商品属性（大小、易碎、金额-跨境电商有要求）

商品价值

拆单校验逻辑

子单商品数量，相关金额（平台优惠，商家优惠，商品优惠，订单金额，实付金额）与父单的一致性

拆分订单数量是否符合业务需求（如：拆单数量限制，货到付款订单拆单限制等）

拆分后是否需要再次拆分，如果是，则子单为异常订单，否则拆分完成，同时取消父单，生成子单；校验不符合的，恢复原单

何时拆分订单

如何拆分订单

订单拆分流程

订单金额拆分

订单金额计算公式

订单金额计算流程

先计算商品金额（即：改商品价格）

促销后商品小计金额（即：满减、满折、满赠，优惠券）

促销后订单金额（即：满减、满折、满赠）

后续针对订单的优惠券、优惠码

金额累计叠加后，再判断是否包邮，计算运费

积分抵扣订单金额

其他金额抵扣，如：后台人工修改价格（需要使用独立字段记录，不能直接在原订单金额上直接修改）

订单拆分后的子订单金额（参考优惠分摊案例）

子订单退款时，以子订单实际支付金额为准

子订单退积分时，以子订单实际抵扣的积分为返还数

n个子订单共用的优惠券，若子订单退款数为m小于n，则优惠券不返；若m=n，则可视业务情况考虑是否返优惠券

由于不同商品的毛利率不同，若依然按照商品金额等比率分摊优惠，则对毛利率低的商品的商家是不利的，解决思路

跨店铺促销时，尽可能排除毛利率差异大的商户

对毛利率高的商品设立更高的分摊权重

拆单也有两个层次，第一次是在提交订单后支付之前拆单，这次是拆分的销售单，一次是在下单之后，发货之前，去拆分供货单

第一次拆单是为了区分平台商家、方便财务结算

第二次拆单是为了按照最后的发货包裹进行拆单，如不同仓库、不同运输要求的SKU、包裹重量体积限制等因素

若是跨境商品平台，则需要在支付前完成所有拆单步骤，因为报关需要三单对碰，订单、支付单、运单统一

拆单之后的前端显示

在支付之前的拆单订单，需要即时显示给用户，若用户中断支付，再回到支付环节，就需要分开支付，用户就能知道，是不同的包裹发过来的，分属不同的子订单

在支付之后，系统根据一些影响因素进行拆单，同一个子订单可能会对应多个物流单，在订单显示页面查看物流时，需要展示多个物流信息。但是现在多个平台只能一个订单对应一个物流单。有些订单无法通过一个包裹就能发货，在信息反馈给客户上就会有些瑕疵

最后，关于支付单，基本所有平台都会通过合并支付的方式简化支付环节，但是不同的子订单都是可以拿到不同的支付单号的，这样就有利于售后和财务管理，对于跨境商品，还有报关的作用

订单正向和逆向流程

正向流程

如果选择COD（货到付款）则支付环节相应转移到订单配送之后，而过程中所有与款项相关的逻辑变为只操作金额数字，不对结算和账户进行打退款操作

订单金额需要分摊到产品，为财务结算以及后期可能出现的逆向流程做准备

订单系统审核主要用户对恶意用户或者刷单情况进行处理

系统可根据白名单、黑名单、消费频次、促销品购买量当方面做风控规则

如果后续会进入到人工审核，则规则上可以适当从宽

当触发规则需要进行订单退订的行为

此处设计时要小心对用户体验的损害，往往前台文案上说明当前节点是审核状态或者是等待接单

在O2O领域有催单的概念，而传统电商则是通过关联第三方物流的物流信息进行跟踪

催单触发考虑到实际场景，一般会设定一定的时间间隔，间隔时间内只触发一次催单的请求

预售等货和移仓需要做成SOA服务，以便在交易页面计算预计时间和预计到货时间

移仓处理依赖仓库的情况，也会涉及到后续拆分和合并包裹的逻辑

订单生产时先要判断报缺情况，如果出现报缺问题则要考虑整单报缺、部分报缺、换货或者换转退的情况（库存，仓促调拨和退款）

报缺情况分为系统报缺和实物报缺（虚库存），这是承接但相对独立的两个环节

电商系统要考虑7天无理由退货的情景，即订单状态完成后申请退货

此时主要涉及的是金额上的计算以及一些财务程序（如发票等）问题的处理

逆向流程

订单的逆流程主要分为仅退款和退货退款

待支付

在用户已下单未付款时，若买家主动取消或支付超时自动关闭的，订单状态会变更为交易关闭

待配送

在待发货状态下，买家申请退款的，退款状态会置为退款中，此处的部分退款和全额退款有些差别，若是部分退款，订单状态仍可往下流转，该订单下申请退款的商品会生成一个退款单，走退款流程

待确认收货/交易完成

在待确认收货中申请退款，一般商品已经进入物流配送环节，此时的逆流程分为退款/退货退款，下面分别就两种情况进行说明

退款

买家提交退款申请，如果卖家同意则直接进入退款流程，若为订单全额退款（单商品订单全额退或多商品订单整单退），则订单的状态变更为交易关闭

如果为部分退款，则订单状态仍为待收货或交易完成（待收货会继续流转）

特殊情况，买家和卖家在申请时理论上会出现一方申请，另一方拒绝的循环情况，所以需要有一个申请客服介入的流程来保证交易和售后的正常进行，一般买家发起后被拒绝则可选择客服介入；同样的，在卖家端收到申请的时候，也可以进入客服介入流程

退货退款

在待收货或者交易完成后的退款，流程如下，卖家同意退款前的流程与退款的流程类似

但在同意退款后，买家端会看到卖家的退货信息，包括姓名、地址、电话等退货相关信息，买家在寄出商品后，卖家会进行验收确认，确认无误后会进行退款，如果在验收环节有问题的话，一般会走线下协商，要么将货品发回给买家，要么退部分款项

注意事项

超时时间

超时时间分为订单超时和退款超时，主要是在长时间没有操作的自动触发机制，为了保障订单和退款状态的正常流转

订单超时

支付超时：长时间没有支付，系统会自动关闭订单，支付时间根据不同公司不同业务和场景决定，例如外卖的超时时间一般在15min~30min，而淘宝一般在3天（促销活动等特殊情况除外）

收货超时：用户一般主动确认收货的情况较少，建立这样的机制既能保证商家资金流的正常周转和买家的权益，又能在一定程度上减少用户的操作成本，收货时间也会根据不同公司不同业务和场景决定，例如外卖的收货时间一般骑手送达后的几分钟内，而淘宝一般在10天左右（促销活动等特殊情况除外）

退款超时

退款超时一般发生在等待卖家同意或者等待买家重新发起阶段，如果在机制的时间内没有处理，系统会自动进入下个流程（卖家超时未处理则自动同意，买家超时未处理则撤销退款）

商品系统

促销系统

会员系统

推荐系统

能力模型

其他学习

行业研究框架

行业研究的两个基本逻辑

首先判断研究的目标行业位于整个产业发展阶段的初期还是后期

对于初期行业来说，由于整体行业的市场格局未定，未浮现出行业龙头，同时产业初期的公司数量相对较少，所以采用的逻辑是“由下至上 (Bottom-Up) ”的：首先对市场中的公司进行研究，然后再对整体行业进行归纳总结

对于中后期的行业来说，市场格局逐渐形成，行业标杆已经确定，我们研究中后期行业采用的逻辑是“由上至下 (Top-Down) ”：先对行业基本面进行研究，然后再对标杆企业进行研究

我们的研究逻辑是从具体的产品看起，再对产品的模式进行归纳得出整体的行业格局

行业研究常见的二手信息搜集渠道

行业研究的四个基本流程

资料收集

一手数据/信息收集

采用数据爬虫对前端网页中结构化数据的抓取、编写定量问卷对用户进行调研分析、组织对行业专家的访谈等

二手数据/信息收集

整理和分析第三方机构披露的数据，对所在行业/市场进行分析

结构化分析

所谓结构化分析，指的是通过系统化和标准化的框架/模型，或采用结构化的逻辑思维对我们前面搜集到的信息进行分析，通过结构化分析最终能够帮助我们全面深刻地理解所研究的行业

大量的信息中归纳出核心要素，通过分析这些要素提炼出观点和解决方案

内容呈现

我们通常采用PowerPoint对前面研究的内容进行呈现，但也不排除在需要快速反馈的项目中使用Word或者邮件

另外在报告写作之前，通常会搭建一个逻辑故事线（Storyline），将我们的研究内容按照讲故事的方式有逻辑地写下来，最后给出我们的洞察和结论

盘点

作为产品项目的支持方，战略分析组通常会定期对行业进行盘点，对有重大变化的公司和事件进行分析

行业研究的六大标准框架

PEST类分析

主要用于宏观环境分析阶段，从政策法规、经济环境、社会文化、技术革新等维度分析宏观趋势和环境因素对于行业或者互联网产品规划的影响

核心关注点是与行业相关的某一因素变化带来的机会或者威胁，需要甄别对于产品目标市场/行业的宏观趋势以及导致趋势变化背后的相关因素

政策法规：如产业政策、行业法规、法律风险、国家差异等

经济环境：如宏观经济增长、货币环境、资本市场热度等

社会文化：对用户数量、用户习惯等产生影响的人口统计学特征、生活方式、价值观念、道德风险等因素，例如性别、年龄、用户习惯、宗教信仰等

技术革新：对潜在目标市场/行业的可利用技术产生影响的新技术研发、技术迭代、基础设施等因素，例如新技术研发、技术迭代、基础设施等

市场机会分析

市场总量分析

即分析市场整体规模及增长情况，互联网行业中通常用营收、用户数量等来衡量市场规模

也可以选择该细分市场的主导/领先公司，通过调用内部数据、访谈等方式得到其市场份额，使用营业收入除以其市场份额间接估算细分市场规模

除了了解整体市场规模外，还可以通过分段标注增长率的方式分析市场规模变化趋势，初步判断市场所处的发展阶段

市场细分

市场细分是指通过市场调研，依据用户需求，把某一产品的市场整体划分为若干子市场的分类过程，其核心在于细分维度的选取

细分方案需要满足三个核心条件

首先，需服务于明确的目的：常在产品定位/调研层面，有针对性的细分市场将服务于评估细分市场吸引力、洞察用户需求、协助设计具体产品形态和模式等几个主要需求

其次，需可行且有效：即细分市场间存在明显的差异化，且细分市场可以达到一定体量

最后，还需要考虑操作性选择最优方案：根据目的、时长、数据资源决定细分方法和深度

细分市场方案确定后，将对各细分市场的特征、市场份额、盈利能力等进行分析，作为后续市场评估的依据

一般而言，成长中的细分市场蕴含机会，衰退中的细分市场蕴含威胁

竞争生态分析

行业分析中需重点关注的另外一个因素为行业的竞争生态，包括行业竞争压力、市场集中度、市场所处阶段等，常用的竞争生态结构化分析框架/模型有波特五力分析、市场集中度分析等

波特五力法

潜在竞争者的威胁取决于市场壁垒的高低，市场壁垒越高，潜在进入者的威胁越小

买方议价能力取决于购买端的集中度、购买者收入水平、产品差异性等因素

卖方议价能力取决于供应端的集中度、购买者对于供应商的重要程度等因素

替代品引起的风险主要取决于技术的变动、替代品的性价比等因素

行业内竞争压力主要取决于自身与竞争对手的市场地位、市场占用率等因素

衡量行业竞争状况的常用分析指标为行业/市场集中度 (CR)

市场集中度反映一个行业的竞争程度，具体的计算方式根据不同行业/项目需求而定，比较常用的计算方式为前3/5/10名市场参与者的市场销售额占比

前三名竞争对手的市场份额占比超过75%则说明行业集中度较高，低于30%则说明行业集中度较低，行业集中度越高的市场通常竞争越激烈

市场吸引力分析

常见的市场吸引力评估指标包括市场/用户规模、市场/用户增速、竞争集中度等指标，具体根据不同行业/项目需求确定关键维度及权重，对市场吸引力进行定性或定量评估

矩阵分析

矩阵分析法没有固定的分析维度，具体维度根据不同情况而定。最经典的矩阵分析法为波士顿矩阵法，根据市场吸引力、相对市场份额将市场/业务划分为四种类型：明星、现金牛、瘦狗、问题市场/业务

行业价值链分析

行业价值链分析是将行业价值链各环节展开，了解行业运作流程，并分析各产品链环节的竞争参与者数量、市场规模、盈利能力等状况

重点关注价值链中高利润区以及对整个行业产生重大影响的关键环节即战略控制点，为新业务的上下游延伸或者合作标的的选择提供参考

行业价值链分析案例：商业图像素材产业链

第一性原理

回到事件的原本的出发点，所有参与者，都要围绕出发点去做，过程中的冗余，都可以去掉，即追求事物表面背后那个最本质的道理

提升效率是互金市场主体的核心目标

效率”是一切经济行为最重要的价值判断标准

效率 = 产出与投入的比值最大化 ≈（达成既定目标时）资源浪费最小化≈效率 ≈（同等投入的情况下）把饼做大

在不考虑借贷端的情况下，理财端的市场主体大概包括这五类：监管、资产方、平台方、投资者、羊毛党

互金市场各大主体的效率目标分析

最低效率目标：是否满足底线（谈现实）

最高效率目标：是否满足顶线（谈理想）

平台投资回报率(ROI) = 转化率*每个用户平均收入(ARPU)/(CAC+COC)

CAC：用户获取成本

COC：用户运营成本

第一性原理成立的两个基本假设

假设一：资源是稀缺的

用户的时间、安全优质的平台、短期高收益产品、友好的全流程用户体验、运营/产品/开发的投入，这些都是资源，资源只有在稀缺时，价格才为正；资源不稀缺，价格等于零

用户的决策和操作时间是有限的

“平台的安全优质”与“产品的短期高收益”，从长期来看，是两个互斥的概念

友好的体验与高效的用户增长并没有直接关系，这是两个维度的东西

基于假设一运营逻辑推演

推演一：人们面临权衡取舍

需要了解用户的取舍，就需要场景化思维，就需要了解用户需要取舍时所面临的场景

典型用户特征是什么

用户如何选择理财平台的

在平台上看到不同的产品时，用户是如何做出交易决策的

面对不同的运营手段，用户是如何思考和选择的

推演二：某种东西的成本，是为了得到它而放弃的东西（机会成本）

对用户的投资行为来说，是放弃了资金的流动性，以及其他的增值机会（房产、股权等等），承受着平台跑路的风险，来进行投资的

用户为什么放弃一定程度的资金流动性，来做投资

用户为什么放弃传统金融机构，来互金平台做理财

用户为什么放弃其他平台，而来你的平台

假设二：用户是理性的

在所控制的范围内，用户总是试图使自己的利益最大化，对于互金用户来说，利益点很清晰：流动性、收益、安全性

流动性：余额宝，申赎T+0，权益类基金T+1到账

安全性：宣传安全，是为了提升用户决策效率

收益：包括产品类型配置（定期/活期）、久期配置（不同期限的定期类产品）等。在这里尤其需要注意的是，平台方单方面让利（体验金、加息券、分享加收益）看起来是提升了用户收益，提高了用户效率，但对整个交易链路来说，其实是左口袋换右口袋，对整个市场效率的提升帮助不大。平台想要健康成长，根本上还是要提升获取优质资产的能力，并以此为基础做好用户运营

基于假设二运营逻辑推演

推演一：理性人考虑边际量（边际成本）

个人和企业通过考虑边际量，将会做出更好的决策。而且，只有一种行动的边际利益大于边际成本，一个理性决策者才会采取这项行动

通过交易系统创新、产品运营模式创新、对接场景创新等方式，持续提升用户的边际收益

边际收益提升存在客观上限，这时对于这类用户，意味着无论用什么方法你也留住这部分用户

推演二：用户对激励做出反应

在分析任何一种政策时，我们不仅应该考虑直接影响，而且还应该考虑通过激励发生的间接影响。如果政策改变了激励，那就会使人们改变自己的行为

用户对价格作出反应

用户对竞争作出反应

用户对契约、制度规则作出反应

针对这一条，我们可以得到如下启示

运营的landingpage页，不要有太强的“确认”或“授权”要求，否则可能吓跑用户

用户会钻研平台的各种制度和规则，要确保运营规则的完整性和自洽性

考虑正面反应和负面反应的应用。如果推分享加收益，则用户倾向于进行分享；提示优惠券即将过期，则用户倾向于尽快用掉

五个要点回顾

第一性原理有两个基本原则：以事实和少量假设为基础，一层层向上推演，探究问题的本源；大胆假设，小心求证

互金市场主体的核心目标是提升效率

第一性原理成立的两个基本假设：资源是稀缺的、用户是理性的

基于资源稀缺性假设的运营逻辑推演：人们面临权衡取舍、某种东西的成本，是为了得到它而放弃的东西（机会成本）

基于理性人假设的用户行为逻辑推演：理性人考虑边际量（边际成本）、用户对激励做出反应

梯子理论

什么是梯子理论

从产品到用户的过程，其实是一个从What到Why的过程，What即我给了你什么，而Why则是思考我为什么要个你这些

产品具有属性，用户具有价值观，在两者之前搭建渠道（梯子），让两者之前产生共性和共鸣，这个就是梯子理论

其实是一种营销方法，目的是建立用户与产品的共性，拉进距离

从梯子的角度来讲，越靠近用户，越容易促成动机，所以更注重心理利益或者价值观的层面，从而唤起消费动机，属性部分可以作为支撑点帮助解决理解问题

产品属性——产品属性带来的实际利益——实际利益带来的心理利益——心里利益引发的价值观

洞察消费者痛点的方法

访谈

消费者洞察访谈的自问自答

这个方法一定要在特定的条件下使用，即你所做的产品不是你擅长的领域，是你所不熟悉的产品

针对自己不了解的领域进行自检，尝试揣摩真实用户的需求

根据揣摩的用户需求，尝试建立产品的目标用户画像

访谈产品潜在受众

样本筛选的时候要注意，尽量使你的样本确实是或者是无限接近潜在用户

尽量寻找接近用户画像的真实用户

访谈过程尽量不刻意，假装的像聊天一样，得到的答案可能更真实

访谈结果的提炼过程很复杂，尽量做好记录或者把问题简单化

访谈潜在用户的家属

主要目的是寻找与产品目标用户有关联的用户

从侧面了解用户和关联用户对产品的需求以及差异

将潜在用户的需求和关联用户的需求对比，提炼共性需求

美容仪的属性——价值观梯子如下

心里侧写

首先先定义产品的目标用户，初步建立用户画像

自问自答的方式是合理虚拟用户画像的一个办法

用逻辑推演的方法，合理推测目标用户的与产品有关的心理诉求

总结

消费者洞察的确定一定离不开调查，而调查得出的结论要及时的进行心理侧写，刻画出你的消费者的真实需求，大致分为以下几步：

1. 确定访谈样本，如自己、目标受众、潜在用户亲属等

2. 放松状态下的访谈，目的自己知道即可，访谈过程最好轻松愉悦无刻意引导性话语，顺着访谈者的回答进行会更好

3. 访谈结果分析，消费者心理侧写，挖出消费者的共同点，从而得出自己的消费者洞察

4. 结合消费者洞察和产品属性搭建梯子

5. 梯子未必就只有四层，梯子是一种内在逻辑的连接，当你觉得四层很难打的时候，可以先细分，把你能想到的关联都罗列出来，此时大胆的发散你的思维，然后再整合，得出走的最顺利的梯子图

如何做需求管理

普拉姆方法论

原则：存在即有标识

宗旨：积极主动，知识共享，相互尊重

积极主动：团队中每个工作的角色在变，通过管理需求达成的目标不会变

知识共享：分享不同团队的领域知识，减少沟通的未知区域，减少沟通中的误解

公则生明，即将信息公开透明，可以增加协作团队之间的信任，比如，公开展示各需求的进度

扩大自己的开放区

尽早的把问题暴露，可以最大的降低解决问题的成本，防止问题积累成一个“惊喜”

相互尊重：相互尊重，是指尊重每一个人的人格、劳动及输出成果

需求管理是什么

通过协作，管理需求内容和进程，实现成功发布

需求管理的干系人和角色

什么是干系人

干系人是与需求相关的人或者组织

找到和找对需求的所有干系人，对于需求管理非常重要

每个人都会从自己的立场出发提需求，可能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的角度去思考需求，或者找到那个能从全局思考的干系人去帮助找到需求中的障碍

提一个优化改善的需求，可能会损害其他流程或角色的利益。有时，产品经理要找到需求的受害者，从而更全面的了解需求

需求管理中的各种角色

在需求管理中，产品经理要当成一个桥梁，与不同的角色，进行沟通和协作

需求管理的三个模式与公交模型

需求管理的“公交车模型”

什么是“公交车模型”和“火车模型”

公交车模型

需求从产生到实现经历三个阶段，把这三个阶段看作乘坐三辆公交车，目标是需求从开始乘坐第一辆公交车到最终乘坐第三辆公交车，中间涉及到两次换乘都是无缝衔接，不浪费时间

模型重复运转，多个需求都按照这个流程进行，完成从开始到结束的流程

火车模型

以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法

其余的功能依旧正常发布

是常规的发布模型

在公交模型中，出行路线称为”需求管理流程“，发车间隔称为”需求管理周期“。到站时刻，称为”需求时间“

需求管理流程：包括需求收集、需求设计、需求开发，三个流程依次进行

需求收集（预诊模式）

利用“预诊模式”破解需求收集的“越快越好”局面

对需求提前进行“预检分诊”，从而分流，将有限资源合理利用

流程：需求人提交需求——负责人收集需求并初步评审（业务口需求收集人，非产品经理）——产品经理、研发经理初步评审，并放入待排期列表——根据待排期列表，需求人、负责人、产品经理、研发经理评定待排期列表中的需求，生成待开发列表

在需求收集阶段，执行急诊模式的操作步骤的时间是2周

需求收集开始时间和需求收集结束时间的间隔是2周

需求收集结束就进行需求排期站会

使用的工具

需求收集模版

优先级和重要性：简单地说，优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低，或者用简单的数据代替

优先级：是部门与部门之间的需求比较。

重要性：是对需求打分，对优先级的补充，是部门内部需求的比较

需求涉及部门：此项目的也是为了驱动需求人在提需求时，增加跨部门思考的维度，提升需求的可行性

业务背景：或者叫需求背景，可以想象一下，如果需求是一部电影的话，是不是要介绍这个故事发生的时间、地点、人物等。以此类比，填写相关的需求背景

需求池

需求池是更像是一个游泳池，存储着大量的需求，需求有不同的泳道，而泳道代表着需求的不同状态

需求的状态一般包括：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等

优先级排序

重要性——优先级的辅助排序

优先级和重要性的关系

优先级和重要性是需求池的核心

优先级和重要性一旦确定，将贯穿需求的整个生命周期，所有的资源将根据优先级和重要性来被安排

优先级可以用来比较不同部门之间的需求，因为优先级已经对需求进行了分类，但是并不是用优先级强制对部门进行分级

重要性只用作一个部门内需求的比较，重要性的分数不能跨部门比较

如何给需求划分优先级和重要性：采用项目组合管理的思路

什么是项目组合管理

项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持

项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化

只要关注一个词——“符合企业战略”，划分需求的优先级和重要性，是紧密围绕着企业和组织的战略

如何划分优先级和重要性，可以看做是项目组合管理方法论的范畴，可以使用SWOT分析、KANO模型等

排期站会

为何站着开会：一次性需要沟通的需求较多，让大家站着开会，以一种不太舒服的方式，压缩自己的思路，快速沟通问题

站会流程

发送会议邀请

在规定时间开会，提前公布讨论需求组的顺序

站会中讨论的需求，会来自不同需求组（按照优先级分的组）。每个需求组对应着不同的人，为了避免浪费大家的时间，按照讨论组的顺序，让对应的人按顺序参加会议

制定讨论顺序时，尽量要考虑每个需求组的数量，和需求组的重要性。因为，先行讨论的需求，就会有优先获得需求的优势

按顺序召集大家开会，首先介绍当前需求的开发情况

评审进入下一阶段的需求

主持人可以针对需求池的内容，沟通可以进入到下一阶段的需求

针对会上没有结论的，标注出来，邀请在会后讨论

正式公布下阶段开发的需求

正式公布下阶段开发的需求，有异议及时提出并调整

需求设计（登机模式）

什么是登机模式

进入开发列表中的需求，就是拿到了机票，经历Check-in环节，将机票兑换成登机牌，凭登机牌登上飞机（正式进入开发阶段）

在这里，主要增加的是Check-in环节（需求设计阶段），将需求转化成为可执行的产品解决方案（产品需求文档）

产品需求文档，尽量采用共享文档

需求开发（看板模式）

利用Teambition的看板模式进行管理，管理所有需求的进度

利用燃尽图来管理一个开发周期内，所有需求的进度

需求管理周期

普拉姆方法的需求周期，是80小时，即2个星期

将一个项目中的工作，按照80小时的工作量进行拆分比较合理

需求时间

在需求管理活动中，进行某一项具体活动的时间点，就是需求时间

运转模式

从需求的生命周期来看，公交模型如下，此模型的流程重复运转

从需求管理周期的来看，模型如下

普拉姆理论的缺陷

如何提前评估开发工作量

还是在排期站会的过程总，根据对需求的描述，大致预估开发时间，以人天为单位

如何确定需求完成的deadline

相对准确的评估出来工作量，就可以定义deadline

如何处理长期堆积在需求池中的需求

暂无

模型的具体优化

优化需求管理流程

删除需求设计阶段，缩减为两量公交车（即需求收集、需求研发）

优化需求池

对需求池的信息进行精简，主要是去掉状态信息，让处在研发、测试或者设计状态的需求，全部放在一个列表中，根据优先级和重要性进行排序

如何构建产品结构

将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路

为什么需要产品架构图

梳理自己对产品未来方向的思考和判断

为技术和运营的后续输出提供支撑依据

他人可视化的理解产品内容

何时需要产品架构图

复杂项目开始之前

如何制作产品架构图

列出问题域

自己的产品能够解决的所有问题的集合

从核心需求出发，将所有当前需要解决、未来可能要解决的问题进行罗列

如何列出问题域

将收集到的需求中，与产品目标和产品形态相关的描述进行罗列

围绕完成目标设定一系列如何才能完成目标的问题

逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决/改善

按照层级去罗列出所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”

确定解决方案与产品方向

根据问题域给出相应的解决方案

根据解决方案，得出一个模糊的产品方向和功能范围

将这些问题的答案抽象成一个具体的产品需求

根据具体的产品需求设计业务流程

搭建基础框架

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界

对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑

将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图

将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架

明确架构分层

一个具备前后台关系的产品架构图至少分为三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到何处去）

按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界

处理不同信息层级的边界

其中用户感知层和数据层通常可以简化为一层（用户端的功能表达往往逻辑简单、数据的来源问题则不是自己产品的核心功能）

功能模块层则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级

处理同一层级内子模块的边界

各层次之间虽然相关，但同一层次内的子模块之间一定是互相独立、界限分明的

将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现

最终检查

一张好的产品架构图，应该具备以下特点。

清晰的模块功能边界

功能经过抽象，做到标准化、互相独立

上下游产品功能边界清晰，架构分层明确合理

具备迭代优化的能力

项目管理47个过程

APQP：产品质量先期策划

PM的完成软硬两点

硬：项目完成的原则框架时刻把握

软：协调参与各方面的利益，硬原则无重大变化情况下，让参与者都满意

项目管理的47个过程

启动过程

制定项目章程

诞生项目并未项目经理“正名”

识别项目干系人

搞清楚谁与项目相关

规划过程

制定项目管理计划

编制项目执行的蓝图

规划范围管理

规划如何实施项目管理范围

收集需求

收集要做什么

定义范围

确定要做什么

创建WBS

细化交付成果到可管理的程度

规划进度管理

规划如何实施项目进度管理

定义活动

把工作包分解为可估算、可分工、可控制的活动

估算活动资源

确定需要什么才能完成工作

估算活动持续时间

确定完成工作需要多久时间

制定进度计划

描绘出整个项目的实施进度

规划成本管理

规划如何实施项目成本管理

估算成本

确定完成工作需要付出的代价

制定预算

批准工作完成所需要的代价

规划质量管理

确定合格的标准

规划人力资源管理

需要什么人，需要多少人

规划沟通管理

项目干系人需要什么，如何给到他们

规划风险管理

定义如何对待风险

识别风险

识别风险在哪里可能会出现

实施定性风险分析

解开风险的面纱

实施定量风险分析

解开风险的真相

规划风险应对

定义如何应对风险

规划采购计划

买什么以及如何买

规划干系人管理

规划如何更高的让项目干系人积极参与项目

指导与管理项目工作

按图索骥

实施质量保证

通过过程保证质量

组建项目团队

建设项目团队

管理项目团队

执行过程

沟通管理

按照沟通管理计划把信息传递给需要的人

管理干系人参与

积极协调项目干系人积极参与项目

实施采购

购买要买的东西

监控过程

监控项目工作

盯着以及不停的盯着

实施整体变更控制

让变更在可控范围内

确认范围

让用户接受项目成果

控制范围

让范围在可控之内

控制进度

让项目进度在可控范围内

控制成本

让费用在可控范围内

控制质量

让结果满足既定的合格标准

控制沟通

确保干系人得到且只得到他所需要的信息

控制采购

让本次购买可控

控制干系人参与

影响项目干系人积极参与

结束项目或阶段

给项目或阶段划句号

结束采购

给本次采购划句号

高转化率的着陆页

什么是着陆页（Landing page）

用户被广告（广义广告，包含各渠道，各形式的广告）吸引，采取点击等行为之后的落地页面，是营销漏洞的第一个环节，也是最重要的环节

着陆页的特征

任何一个着陆页一定有一个唯一的目标

着陆页的所有内容和合适都是为了完成这个唯一目标

着陆页的类型（三种）

发展用户：注册／下载／关注／订阅

促成交易：购买

搜集线索：留下联系方式或其他信息

从用户行为看，着陆页的类型又分为两种：引导点击类和引导填写类

高转化率着陆页的通用逻辑（WWWA模型，说服套路）

一个大的原则：用户视角，避免自嗨

WWWA转化逻辑

what do i need（关用户啥事？）

从用户角度出发，考虑用户痛点和需求，把这个重点表达出来，与用户建立联系

what do you have（你有啥本事？）

你的产品或服务的独特卖点，这个独特卖点最好是能满足用户需求

整个转化模型中，最重要的一环

why are you（为什么选择你？）

通过外部背书，增强用户的信任，打消用户的疑虑

可以通过权威人士的站台和背书，或者其他用户的正向评价

可以选择不同领域的人群代表，引发不同细分领域人群的共鸣

action now（立刻行动）

利用限时或者限量优惠的方式推用户一把

限时或者限量礼包

成功的案例表述

人因情感而购买商品，并用逻辑性证明其合理性。因此，需要通过触及人的基本欲望和需求来激发情感反应，并最终达到你的目标——《极金广告》

PC端引导填写类模版

第一屏

用图片来吸引用户眼球，处理图片信息的速度远远快于文字（图片中有人物形象的话，人物面向的方向，用户关注度更高）

有一个与广告页呼应的主标题（主题与用户相关，例如给用户带来什么，或者能帮用户解决问题）

可以尝试主标题为用户痛点，副标题为产品卖点

信息收集表格的要求

简单粗暴的告诉用户，留下信息能给你带来什么好处

语言简洁，设计简单

收集信息最好不超过三个

利用色块或者颜色对比，突出表格填写的区域

突出醒目的行动“提交”按钮

第二屏

结合用户痛点，介绍产品卖点

可以拆分为几个不同的痛点&卖点组合

用场景化／情感化／细节化的方式来描述用户的痛点和产品的卖点

把文案进行处理，显得更有画面感

行动按钮进行前置突出，在用户有感觉的时候，随时可以行动

第三屏

来自外部的声音，来自名人／机构／用户的点评和评价

选择用户评价时候，最好是可以选择不用领域的，增强用户的代入感

行动按钮进行前置突出，在用户有感觉的时候，随时可以行动

第四屏

呼吁用户采取行动，及早加入

提醒用户行动的好处，例如可以给用户带来优惠或者增值服务等，以刺激用户行动

利用限时的倒计时计时器来刺激用户

行动按钮进行前置突出，在用户有感觉的时候，随时可以行动

最后

对于要离开的用户，尽量低成本的与其产生关系，例如关注公众号免费试用等策略

移动端引导点击类模版

移动端的特点

页面较窄，页面能够承载内容的空间较小

用户注意力更短暂，页面停留时间短，浏览速度较快

交互形式更加丰富

第一屏

吸引用户的图片，解答能够给用户带来什么的问题

图片的主标题和副标题也是引导性质的文案

行动按钮永远前置（或滑动2-4秒钟之后出现，避免引起用户的排斥心理），让用户在决策的第一时间就可以触及行动按钮

用浮层或者向下翻动按钮的交互设计，引导用户向下翻页

第二屏

展现用户痛点和相应卖点

主要注意的是这些内容在移动端的展现方式和文案内容，需要控制文案字数

同样，需要有画面感的文案描述，最好是具体场景

第三屏

展现外部背书的内容

除了用流的展现方式之外，也可以考虑使用左右滑动的卡片展现方式

第四屏

煽动力的话术，或者是限时限量的活动和优惠等刺激用户

可以使用一个明确的点击箭头指向行动按钮

页面展现内容多样性的标准

用户行动的成本／理解产品或者服务的难易程度与转换逻辑的复杂性成正比

例子：用户产生行为的成本越低，商家达到目的的难度越低，那么页面展示出来的转化逻辑就越简单，页面内容也就越少

产品的知名度与转换逻辑的复杂性成反比

产品知名度越低，转换逻辑越复杂

转化型文案的拆解

分别从以下三个角度的定位，进行文案的具体描述

定位卖点（需求）

定位人群（用户）

定位场景（场景）

高转化着陆页的特征总结

着陆页有清晰的引导用户的转化逻辑（WWWA）

言之有物的表达方式（文案）

文案场景化

文案贴近用户，便于理解

用户视角，避免自嗨

货真价实的产品服务

AB测试优化着陆页

AB测试的优势

先验性：不用投放全部用户资源，使用部分用户资源即可提前完成测试，之后整体资料释放

并行性：节约整体测试的时间

科学性：依靠数据而非经验，变量更易受到控制

什么条件下使用AB测试

流量情况：日均大于等于1000UV

样本越大，结果相对越精确

人力成本：1-2人使用工具

时间周期：大于等于7天

拉长时间周期，也是为了扩大样本量

用热力图发现着陆页的问题

定量

点击热力图

注意力热力图

触达率

定性

LIFT模型（着陆页影响力测试）

价值主张

第一屏展现活动或品牌的价值主张