首页  思维导图  详情

产品方法论

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是否处理完毕

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

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

产品文案是否明确无异议

核对上线清单

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

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

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

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

推荐

AARRR模型

评估用户价值使用的模型

R：最近一次购买的时间

F：购买频次

M：购买金额

RFM模型

人：用户数、留存率

货：商品数量、商品动销率、商品单价、客单价

场：网站、渠道、点位数、展示位置

人货场模型

数据分析框架

时间对比

空间对比

目标对比

用户对比

竞品对比

对比分析

不同时间分组

不同产品类型分组

不同用户类型分组

不同渠道分组

分组分析

对2-4个重要属性进行分析

判断某个事物，事物具有多重属性，且属性之间没有直接的关联性，需要根据多重属性判断事物的结果

矩阵关联分析

分层罗列影响因素，发现问题

将复杂数据层层拆解为简单数据，从中发现问题和机会点

逻辑树分析

用于发现某个行为路径中的问题

漏斗分析

数据分析方法

数据展示

基础数据分析

产品早期，对产品发展有重要推动作用的用户，积极互动，充满热情

种子用户运营是最常见也是最有效的运营手段

什么是种子用户

产品早期用户体验无法保证，bug多，更多在用户使用中进行测试

种子用户的口碑积累之后再进行推广效果更好，利用老用户获取新用户，成本较低

部分类型的产品，例如平台类型的，天然需要一部分用户，因此做好价值供给与产品氛围打造就十分重要

为何有种子用户的存在

容错性较高，对产品或者功能的需求更迫切，更强烈

乐于发表意见，提出建议，并愿意与产品团队持续进行互动

在小圈子内有一定影响力，最好是意见领袖

理想种子用户长什么样

线下混圈子，建立强信任感（基于人）

依靠价值／理念的输出传递，自然吸引而来（基于事）

邀请码营造边界条件的运用

社会化媒体／社区等地的长期耕耘，定向挖走相关大V

获取理想种子用户的姿势

理想种子用户的画像与获取

给种子用户提供超预期的体验

面对种子用户建立强信任感，强互动的用户关系

种子用户运营的核心要点

参考米粉的初期运营思路

给予种子用户强烈的重视感与参与感

加强私人互动，建立牢固的私人关系

借助种子用户建立起来有价值的社交链接

礼品，补贴，各种惊喜的制造

一个大的原则，是提供60分的预期+80分的实际体验

种子用户的运营的重点与方法

销售额=品类1销售额+品类2销售额+......+品类3销售额

特定品类销售额=（站内流量*商品曝光率*站外转化率）+（品类站外的流量*站外转化率）

产品角度拆解

销售额=用户总量*付费率*ARPU值

用户角度拆解

什么是可以落地执行的指标，也就是非复合指标，是基础指标，是可以直接改变的指标

把宏大的目标拆解的足够细，使得掌控力加强，细化落地

目标拆解的核心，就是把目标拆解到可以落地执行的指标

销售的目标拆解

梳理涉及到目标转化率的所有流程

对流程涉及到的每个环节进行ABtest，提升各个环节的转化率

如何提升转化率

数据监控／分析／优化

基础运营知识

基础设计知识

基础研发知识

基础测试知识

其他知识

产品线规划

终端特点

场景互补

产品矩阵规划

阶段性目标需要以项目来落地实现

项目分析画布全貌

项目分析画布

项目将来在公司如何发展

项目目前在公司的位置在哪里

不是自己负责的项目在市场中的定位，而是在公司所有业务线中的定位

什么是项目定位

拉流量

增收入

做品牌

提效率

提利润

项目的价值表现

项目定位不准确，后续一切都是高风险

直接列出所有项目

梳理与自己相关的项目

列出与自己平行的公司级项目

高流量高收入

明星项目

高流量低收入

流量项目

高收入低流量

收入项目

低收入低流量

边缘项目

按照流量高低+收入高低形成坐标轴，来将所有项目进行定位

按照流量-收入矩阵排列当前项目

对项目的未来走向进行规划

根据收入-流量，对项目进行定位

写出当前项目的定位和走向

找准项目定位

战略级的项目，需要独立定位

项目定位

确立目标，拆解指标，拉平对目标的预期

为项目确立目标

大部分是定性，部分是定量

定量的部分是可以拆解的，而非用于执行

项目目标尽量聚焦，不超过3个

如果目标很多，将项目拆分阶段去完成

目标确立原则

通过加减乘除可以直接得到

直接影响

存在明显关联的1-3个关键因素，这些关键因素可被计算

间接因素

基于项目定位，确立项目目标

每个项目都有目标，一个或多个

将目标拆解为指标

之前没有与目标相关的度量数据

基线型

需要设置一个越多越好型的度量指标

正向度量型

需要设置一个越少越好型的度量指标

负向度量型

为一个度量设置一个范围

范围型

结果不能用一个度量值表述时

里程碑型

指标的类型

通过数理公式将指标进行拆解，适用于有确定数值的目标

公式维度

通过分析指标的影响程度来进行指标的拆解

评估维度

拆解指标的维度

每个目标都有指标，一个或多个

目标的明确对项目成功至关重要，而指标反而可以调整

目标向上与领导达成一致

目标与指标向下与团队达成一致

目标与指标的关系

项目-目标-指标

根据项目定位，初步设定目标

定位

项目解决的是什么问题

定性目标

期待的项目完成后的样子

项目跟公司未来战略的关系

定性

目标方向

目标由哪些关键因素构成

指标

它们的计算方式是什么

定量

向上管理

解决的问题是什么

完成后的理想状态是什么

资源压力

目前最大的困难是什么

目标构成的关键因素

指标计算

困难预估

如果去做，要做多久

向下管理

向上和向下沟通，明确目标的必要性和可行性

解决的核心问题（目标）是否与自己的目标匹配

关键因素是否认可

计算口径理解上是否一致

都清晰，自己别作

上级清晰-下级清晰

向下传达

上级清晰-下级不清晰

把下级的情况给上级讲明白

上级不清晰-下级清晰

先搞定上级，再向下传达

上级不清晰-下级不清晰

将上级是否清晰-下级是否清晰作为坐标轴，形成坐标矩阵

判断上下级对目标是否清楚

明确项目目标，拉平上下认知

对上级明确项目目标的必要性，对下验证项目目标的可行性

如何确立项目的目标与指标

确立目标与指标

如果我的项目成功，必须依赖谁，谁是真正的受益者

什么是上下游关系

从用户视角出发，从触达到完成服务的流程

AARRR+底层的效率提升

互联网公司的上下游关系

利用AARRR步骤，梳理所有项目，将所有项目放置在相应的步骤中，从中查看自己的项目所处的位置与上下游关系

梳理上下游流向，明确项目位置

将团队梳理后，根据团队所负责的事情，将其分别放置在AARRR的相应步骤中

列出所有团队，理清团队资源

项目开展所需要的资源

需要啥

上游，我们需要谁的帮助

下游，我们可以支持到谁

竞争，谁在和我们抢资源

在谁那

将所需的资源全部列出后，归到相应的团队中

明确项目所需的资源

理清上下游资源的关键步骤

向资源方合理表达资源诉求，提前沟通，提前预防风险

资源需求：需求、时间、标准、责任人

对上游，体现职业

对资源需求方，明确资源的需求，推进资源的到位

供给清单：可给到的资源、时间、标准、责任人

对下游，展示专业

理清上下游，目的是得出资源需求/供给清单

梳理上下游关系

业务运转的关键要素有哪些？当前阶段资源应该向哪里倾斜？

向一类角色提供价值

单边

两类不同的角色在产品中完成交易或服务

双边

有三类及以上的角色在平台完成交易或服务

多边

从参与者的数量，思考业务驱动模型

确认当前是单边/双边/多边驱动

只有一边是变量，服务一类角色的用户体验即可

鱼骨图拆解法

找到当前核心用户体验，拆解到二级影响因素

重点业务占据70%资源

次重点项目占据20%资源

其他业务共同使用剩下的10%资源

资源竞争的721原则

原则一：搞定B的前提是搞定A，则先A后B

原则二：搞定A对搞定B有明显帮助，反之不然，则先A后B

一级影响因素的重要性作为横轴，二级影响因素的重要性作为纵轴

分别罗列一级和二级影响因素的重要性

从中找到前几个重要的二级因素

如何排序

按照两个原则排序，all in前三个

质量

数量

供给

活跃

留存

拉新

消费

提升供给-消费效率

通过热度，感受稀缺资源

头部集中度高

如何找到稀缺

解决资源稀缺性

供给和消费间的平衡

有两类用户角色，不仅需要满足各自的用户体验，更需关心双边之间的匹配关系

找到相对重要的两边（通常是供应端），用双边方式去分析，另外一边（通常是消费端），可以用单边以体验为核心去思考

按驱动模型分析影响因素

找到核心影响因素，投入资源去解决

如何找到让业务快速发展的引擎

建立业务驱动模型

能表现业务发展与环境相匹配，并有逻辑关系

能解决阶段性的问题或挑战，而非功能或板块

基于公司战略，与公司、其他部门步调一致

什么是靠谱的中长期规划

重要不紧急，合适的时间，提前去完成工作

明确阶段性目标

困难与挑战

项目与方向匹配

方向清晰

持续清晰说明你的计划

让领导同事达成一致

上传下达

中长期规划的价值

用户量订单量剧增带来的新的问题

数量变化如洪水，处理不好会摧毁一切

数量变化

用户群品类扩展带来的冲级，类型变化对用户体验带来冲击

商品类型变化

其他类型的变化

类型变化

不同生命周期侧重点不同，关键是如何聚焦问题并进行解决

产品发展阶段

根据你对产品现在的定位，和未来的走向进行思考，做到不偏差

产品走向

规划落地的具体方法

中长期规划的四种思考方式

基于资源与业务情况进行分析，不要脱离实际情况

项目大小适中，每个阶段是一系列的项目，最长3个月为宜

拥抱变化，我们的规划一定是过于乐观的，但不代表不做

综合分析后，提出合理的规划路径

为避免因自己的使用习惯造成的偏差，请估计每个项目在一定时间段内会影响多少用户

实际的用户量

Reach（接触数量）

那些能对你的目标产生可观影响的项目，预估这个项目对个人产生的影响

巨大影响 = 3x，高 = 2x，中 = 1x，低 = 0.5x，极低 = 0.25x

Impact（影响程度）

我们认为这个功能能实现 R 和 I 的自信程度

高 = 100%，中 = 80%，低 = 50%

Confidence（信心指数）

估算项目需要团队的所有成员投入的总时间

使用整数，最少为 0.5 人/月

Effort（投入精力）

RICE分计算公式

RICE：简单的优先级管理方法

制定中长期产品规划

接手项目

天时

地利

人和

成功项目的三要素

从失败中进行复盘

减少失败的概率，尽人事，听天命

解决的痛点

解决的方案

市场的验证

市场的规模

商业模式

推广方案

竞争对手分析

竞争优势

团队

媒体报道

融资条件

好的BP是什么样

假设-MVP-验证

在尝试中找到PMF

如何降低新项目的失败率

如何探索新业务

假设Idea成立，具体的用户故事是什么

假设

拆解关键因素，分析可行性

可行性

需要投入的资源和商业回报周期

可能性

市场分析与竞品分析深入分析

论证市场

从0到1，大胆假设，小心求证

用户和场景的分析和拆解，并进行罗列

定性的：最极致的体验是如何的？

找对标：和最强的对手相比，你明显的优势是什么？

有画面：能通过描述就引发用户的感受

想象项目成功后的景象，通常是自己的slogan或愿景

什么样的用户，在什么情况下，使用产品解决什么样的问题，最佳的用户体验是如何的？

假设：用户定位与场景

按构成因素：达到理想状态，组成因素是什么

按时间顺序：先做什么，后做什么？

按资源顺序：先有A，再有B，有了AB，才能有C

按挑战顺序：从难到易，从易到难

实现最佳体验的关键因素，不超过三个

可落地可执行：有明确的路径可实现

有数值：至少有1-2个因素是能落实到数值上

SMART：关键实现条件，可以用SMART原则

向下一级拆解实现条件

最佳的用户体验是如何的？关键因素123以及相应的实现方法123是什么？

可行性分析：拆解关键因素

需求刚需程度（高中低）

用户使用频次（高中低）

产品服务模式（重中轻）

是否可规模化（难中易）

产品关键价值分析

项目早期

项目中期

关键驱动力

如何实现商业化

运营重点和难点

可能性分析：投入的资源与商业回报周期

市场分析：基于行业与竞品的分析

Idea分析画布

让idea变的更具体

产品MVP的设计

从MVP到PMF

从零到一

高阶产品进阶

专业知识

每一个页面在一个完整的产品中，都有自己的定位，也就是这个页面存在的目的，这个目的也就是需求。因此，在规划页面之前，确定这个目的就十分重要

C端目的：用户使用此页面想要完成的目的

B端目的：商家通过此页面想要完成的目的

定义页面需要达成的目的，包括B端和C端

提前定义好C端的目标群体，不同目标群体，解决方案都是不同的

设计解决方案的时候，需要将达成目的的过程场景化，在场景中方能提出周全的解决方案

一个目的对应一种解决方案，有时候，不同目的的解决方案是一个综合体，也就是用一种综合解决方案达成多个目的

选择对于C端而言，效率和精准度最高的方案

当C端目的和B端目的有冲突的时候，一般情况下，优先满足C端目的，也就是商业化需要为用户体验让步

定义通过何种解决方案来完成这些目的

需要提前定义好信息和功能的优先级，然后UI根据此优先级设计界面

是否需要某个信息和功能，最重要的依据就是这个信息和功能是否能够高效率的帮助用户达到目的

是否增加信息和功能，应依据奥卡姆剃刀原理：如无必要，勿增实体

当信息和功能是否需要拿捏不准的时候，考虑留下这个信息和功能的理由，如果没有充足的理由，就砍掉此信息点和功能，先做减法

在如今产品页面信息量过载的情况下，减少杂乱信息的干扰，利用视觉和交互的技巧为用户做引导很重要

定义解决方案的具体内容，包括信息和功能

展示和交互给到用户的期望，需要与实际给到用户的反馈匹配，以避免对用户产生挫败感

定义信息和功能的展示与交互方式

文案尽量精炼，使用短句、断句而非长句，降低用户的阅读和理解成本

文案字面描述与实际描述的事物一定是相符的

文案能够符合用户常规的理解习惯，切不可为差异化而使用用户不熟悉的内容

文案的编写技巧

页面功能和信息规划

网站的首页规划需要先理解业务逻辑和运营规划，因为首页是能够体现出来产品背后的业务和商业逻辑

一般情况下，首页在产品中的主要作用是中枢，通过此页面将用户引导到不同的页面

视觉设计的规范也会依据首页的风格进行确定

常见的有三种规划逻辑，一是以功能点做划分；二是以业务类型做划分；三是混合型，导航有可展开的二级频道

强业务形驱动的产品，导航会以业务类型来做划分，对用户的触达更加简单直接

以其他功能或内容驱动业务的产品，导航会以功能来划分或使用混合型导航，更多依靠功能和内容来将用户引导到业务上

导航的规划，既体现该产品的业务驱动逻辑，又要综合当前的运营计划

首页的导航也算是一种运营资源位，非长期固定，而是与运营计划强相关

首页中导航的规划逻辑

首页规划

承载产品的主要内容

突出展示对于用户有吸引力的部分或者产品的卖点

兼容用户在这个场景产生的需求所带来的操作（如询问客服、加购和下单）

体现产品本身的调性

体现网站和产品的运营或销售逻辑（如小米商城曾把客户评价的优先级与产品详情持平）

商详页对于B端的意义

体现产品的重要信息，帮助用户决策

当用户在此场景下有相应需求时，可以提供相应的支持

商详页对于C端的意义

后台的某些字段为空的情况下，后端如何给前端传递数据，前端如何做做null数据下的适配

后台某些字段的内容过长或数量超预期时，前端如何处理，做隐藏还是折叠？如果不处理的话，就需要在样式设计时将此种情况的兼容考虑进去

如果图片较多的时候，最好提前预置占位图，包括页面Loading的占位图和图片数据为null时的占位图

在规划商详页这种信息量较大，且大部分信息都是从后台获取的页面时，需兼容运营在后台填写信息时可能出现的各种情况，并在前端页面做相应的适配

与设备相关的是屏幕分辨率，受屏幕分辨率影响的是页面一屏展示的信息多少，会不会导致某些在页面悬停的内容和组件被遮挡或完全覆盖掉，导致用户无法获取信息甚至进行交互操作。因此需要提前了解主流屏幕分辨率的占比，常规情况下，至少覆盖95%的用户

受到浏览器的影响，会导致某些组件无法使用或者页面渲染出现问题。因此需要提前了解浏览器使用占比，常规情况下，至少覆盖95%的用户

详情页对设备和浏览器的适配一定要做

交互能预先考虑到用户的目的，并自动帮助用户完成无效的过程行为，确保用户只需要做决策行为

对于用户能够触达的交互，在用户尝试交互时一定要给予反馈，在用户尝试交互时页面静默是对用户最大的蔑视。

如果是不可交互的，则视觉上做处理，让用户知道是不能交互的。如果是有前置条件才能交互的，需要给予反馈，指引用户完成前置条件。

页面的交互细节

商详页规划

常规情况下，用户进行搜素后，直接进入产品的列表页，展示满足此搜索条件的所有商品，向用户说明搜索的关键词和符合关键词的商品总数量

在搜索条件下使用筛选功能，一定是基于搜索的结果进行筛选，也就是在搜索上增加条件，而非抛开搜索条件对所有商品进行筛选。在设置筛选条件时，需要将筛选条件和筛选后的结果反馈给用户

搜索和筛选都是设置条件，对所有产品进行符合条件的索引、排序和展示。不同的是搜素更多是模糊索引，而筛选则是结构化数据索引。搜素和筛选在服务端底层是一致的，都是对商品进行符合条件的索引后排序，然后在前端展示

筛选的条件一定是系统根据搜索结果能够满足的条件吐出

有些时候为加强运营，在点击搜索框之后，跳转到搜索页，搜索框并未获得焦点，同时在页面空白处展示运营推荐内容。再次点击搜索框，搜索框才能获得焦点，同时调用默认的输入法键盘

有些时候同时为了加强运营，将搜索框的默认展示的内容设定为运营推荐的内容，以起到推荐和对用户在无目的情况下的指引作用

用户在搜素框输入内容的同时，提前给到与内容匹配的搜索项，有两方面作用，一是减少用户的交互成本，更快的帮助用户达到目的；二是运营搜索项的排序，以达到想要的目的

搜索与筛选的关系

有人员信息展示的页面使用更加灵活的交互，而且在用户的注意力集中在某个人身上时给予一定的反馈，会增加用户于这个人的互动感，感觉更加真实可靠

一个产品必然是有目标用户，也需要提前定义目标用户的类型（例如旅游用户就可以从出行意愿是否强烈、出行目的地是否明确等维度来进行划分）

不同场景下出现的用户类型不一定是相同的，所以在定义场景之前，需要前先定义用户类型

场景的定义=什么类型的用户+在什么情况下+遇到什么问题

在页面规划之前，需要提前定义页面适用的场景，场景中就包含用户类型

同时需要定义页面在整个产品中的定位

其他页面规划

电商页面

搜索功能的入口，可以以搜索栏或ICON方式展示，入口位置、范围大小根据业务情况决定

点击后，既可以在当前页面键入关键词，也可以跳转到单独的搜索页

输入内容并点击搜索后，可以在当前页面跳转到搜索结果页，也可以新开页面展示搜索结果

搜索结果页，需要在搜索框中展示搜索关键词，目的是让用户知道自己搜索的内容，为优化关键词提供依据

搜索入口

在搜索前选择部分搜索条件，缩小搜索范围，提升搜索效率，本质上是关键词搜索+选择相应的筛选项

高级搜索

用户搜索的场景和内容形式是多样化的，为了满足这种多样化，就有辅助输入的内容

常见的有语音搜索和图片搜索，主要应对键入文本不方便和无法捕捉商品的重点信息，但是本质上还是为了提高搜索效率

辅助输入功能

有些直接在当前页面搜索，有些跳转到单独的搜索页面，PC常用的是在当前页面搜索，移动端常用的是单独的搜索页面

单独的搜索页面不仅可以满足基础的搜索需求，更可以展示更多的运营内容，满足运营需求，例如在单独的搜索页面上，增加推荐商品或者活动

搜索页面

搜索具体类型的内容，可以选择搜索内容的类型，快速缩小搜索范围，提升搜索效率

在搜索前和搜索后，都可以展示此分类入口，一个是预先分类，一个是事后分类

默认类型根据业务情况决定，也可默认使用综合类型

分类搜索

推荐系统根据用户推荐的或运营配置的关键词，是一种运营资源位

可以有多种表现方式，也可以快速导流到多种页面，如商详页、列表页、活动页等

在搜索结果页，按照一定规则（后端独立模块计算）展示与用户搜索内容相关的关键词提示，提升用户需找商品的效率

关键词提示

推荐系统根据用户推荐或运营配置的关键词，是一种运营资源位，可以走资源位配置系统或推荐系统

用户在不输入内容的情况下点击搜索，可以直接跳转到结果页，如商详页、列表页、活动页等，此处能够支持的页面类型较为多样化

视觉和交互的优先级高于关键词提示

默认填充文本

展示当前用户的历史搜索记录，点击后可以搜索此关键词，可以限制展示关键词的数量，5-10个最佳，不易太多或太少

数据从后端获取，后端有独立的行为记录分析系统进行统计

应提供历史搜索关键词的清除功能

历史搜索记录可以与关键词提示整合到搜索的下拉菜单中，在搜索框获取焦点且用户未输入内容时，展示整合的内容

历史搜索记录

根据用户键入的部分内容，预测用户要搜索的完整内容，展示预测结果和关键信息

预测结果的排序，也是由单独的系统计算后给出排序，如关键词的热度、当前用户的历史搜索记录等

展示预测结果时，如果预测结果涉及到的类别太多，也可以在预测结果+分类，以便让用户更加精准的找到目标结果

展示预测结果时，可以从视觉上展示当前输入内容与预测内容的匹配度，且弱化完全匹配内容，强化未匹配内容，以便让用户感知，给决策提供参考依据

关键信息的定义，视业务情况而定，如展示此关键词下的搜素结果的数量，让用户提前预知搜索结果

关键词预测

如果输入错误的关键词，在关键词预测结果中会进行改写，避免用户按照错误关键词进行搜索，同时保留仍以输入内容进行搜索

以错误关键词进行搜索，系统会纠正为正确关键词，展示正确关键词的搜索结果，并告知用户已进行处理。但会保留原关键词的搜索入口，仍可以原关键词进行搜索

关键词改写

在搜索结果页，以面包屑的形式展示搜索内容、搜索范围，让用户可以感知，方便进行下次搜索相关操作

搜索面包屑与筛选项配合使用，让用户快速的扩大和缩小范围，提升搜索效率

更激进的设计，可以直接在面包屑上切换其他条件

搜索面包屑

展示搜索结果的所有类别，方便用户区分和选择，提升寻找目标的效率

切换成相应类别，指的是在此类别下搜索内容

分类展示

将搜索结果的所有标签进行聚合后，再分类展示，供用户进行快速选择，提升搜索效率

同类型标签之间，提供单选与多选功能，如果是多选，不同条件之间取并集，不同类型标签之间，取交集。条件过多时，可以采用点击隐藏-展开的交互方式

筛选类型过多时，把常用的单独罗列，不常用的集合折叠

常用或运营主推的筛选项，可以单独罗列，方便交互，以提升效率

筛选项

搜索结果按照一定的规则进行排序，目的是为了提高寻找目标商品的效率，排序由单独的排序系统计算后，吐给前端展示

在多种类型的信息综合在一个结果页展示时，需要区隔开不同信息后再进行排序

电商常见的排序有默认排序（自然排序）、销量排序、价格排序（升序+降序）、评价排序等，也可以视业务来增加其他类型的排序

商品排序

展示搜索和筛选结果的数量和页数，让用户对搜索总结果有感知

展示搜索结果的页数时，可以配上翻页功能

结果数量/页数

在搜索和筛选结果中，进行二次搜索，目的是快速缩小商品范围，提升寻找效率

二次搜索的逻辑是在当前结果中再次进行搜索，因此需要同时满足两次搜索的条件

二次搜索

展示所有的搜索结果的关键信息，给用户提供决策依据，寻找合适的商品

列表页展示的产品信息视业务情况和需求场景而定，统一的标准是能够提供决策依据，会影响用户决策的重要信息

定义好点击热区，也就是在列表页点击商品的哪些范围可以跳转到商详页或其他页面

一般列表页涉及到图片展示，处理好图片和信息的加载顺序很重要，默认先加载信息，后加载图片，提供占位图避免开天窗

商品列表

商品可以按照不同的方式展示，常见的是横向浏览和纵向浏览两种方式

不同展示方式下，商品的信息内容和密度有所不同

展示切换

提供针对商品进行快捷操作的入口，如加入购物车、收藏、加入对比、进入店铺等

在列表页增加哪些快捷功能入口，视业务情况和需求场景而定，提供用户最常用的功能，在准不在多

快捷功能的热区范围需要与打开商详页的热区范围隔离开，最好能留有一定的安全范围，避免热区重叠

快捷功能

由单独的推荐系统计算后，取相应的商品数据，在前端展示

原生广告：最流行的广告方式，与自然内容的展示无差异，体验好，用户无感知，接受程度高，但是展示内容的类型受限

非原生广告：与自然内容的展示有差异，或与自然内容在空间和时间上隔离开，用户能够明确感知，体验和接受程度一般，但是展示内容多样性不受限

推荐商品也是广告的一种，本质上是非自然搜索结果或非自然排序，而是在结果中强行插入内容，分为原生和非原生两种

推荐商品

前端包含的元素

将数据划分为不同的类型（如商品、攻略、活动等），以便从不同类型中取出数据

最终在前端，可能会依据不同的类型将数据做区隔展示，也有可能做综合展示，且不同类型的展示可能有所不同

数据预分类

建议高质量与低质量数据的分类标准，让数据落到不同的集群

在建索引的时候将数据分为高质量和低质量，分别放在不同的集群之中

搜索的时候先从高质量集群中检索，不足时从低质量集群检索结果进行补充

整体思想是数据预处理和分而治之

根据数据的质量，可以分为高质量和低质量两种类型

索引商品的顺序不再受原始链的影响，可以灵活的采用自己特定排序方式，可使用的排序方案就会变多

单独特定排序的集群的倒排链中得分高的商品在前面，得分低的在后面，检索算法很容易做动态截断，即不再需要完整的查找整个链

对于常用且需要大量计算的排序如人气排序，可以将这些排序规则中质量较高的商品放到一个单独的索引和集群中去，这样可以加快某些排序规则的检索效率

可以将不同类型的数据放在不同的集群中，以提升检索效率

淘宝搜索对索引的遍历是顺序遍历，在假定索引有序的情况下，只需顺序查找取回所需的条目数就行了，不需要完全遍历

高质量与低质量集群索引的商品是没有交集，按检索条件和排序规则创建的商品索引是有交集的，即存在数据冗余，但这个冗余是可以接受的

淘宝的分层搜索基于数据预处理和分而治之的思想，在整个大集群上面构建了一些不同角度不同维度的小集群，分散流量，从而达到节省硬件资源的情况下提高检索效率

数据预分层

定义建立索引的字段，也就是商品的哪些字段被索引，如产品名称、描述、品牌、类别等

选择建立索引字段的范围，需要一些权衡，选择范围太大，结果会出现一些bad case（比如将商品描述中一些不相关的term建进了索引），同时倒排拉链过长也会影响性能

想在这个区域玩

想在行程中有这个地方

游玩地点名称（景点、城市、海岛、地区、国家等）

想要在某个地方玩多久

游玩地点名称+时长

这次出去玩的目的是什么

游玩目的（名校、蜜月等）

这次出去想要看的景观

景观、景色、自然现象（极光、瀑布、赏枫等）

想要看什么类型的产品

产品类型（签证、机票、保险、电话卡）

想要玩什么项目

游玩项目（租车、邮轮、滑雪、跳伞、房车、狗拉雪橇）

用户搜索的维度

对“用户可能的各种搜素维度”的字段进行索引，避免出现遗漏

所谓常用与不常用，以用户的搜索维度为标准

索引字段的优先级，先索引常用的字段，后索引不常用的字段

匹配常用字段的优先级高于匹配不常用字段的优先级

索引结果的排序也受到索引字段的影响

以旅游电商为例，索引字段需要依照以下原则

索引规则

常见的有语音语义识别和图像识别，分析输入的语音内容和图像内容，解析出关键内容后传给检索模块，进行后续流程

由单独的AI分析系统提供相应的服务，进行内容的输入-分析-输出

AI分析

关键词预测与改写为独立的模块，负责输入内容-计算-输出结论

用户输入的内容即时向后端传输，后端结合历史数据进行分析，给出预测的关键词，并检索关键词相关信息，一并回传给前端展示

可能会调用检索，取关键词需要展示的信息

需要兼容汉字和拼音两种文本格式

通过算法或者人工标注的方式，根据用户输入的内容，分析计算用户真正需要搜索的关键词，并检索关键词的结果，一并回传给前端展示

会调用检索系统对真正要搜索的关键词进行检索

关键词预测与改写

确定检索的关键词，一个或多个

建立倒排索引

索引归并，也就是数据召回

关键词检索

切词，将一段文本转化为多个单元，将多个单元进行索引

切词模块为单个小系统，在公用词库的基础上，可以加入自有词库

切词

与关键词检索的逻辑相似，只是没有切词，另外将term从关键词改为相应分类的ID或Code

后端分类体系相对稳定，几乎不变，用户感知不到后端分类

后端分类体系

前端分类体系结构可以很灵活，随意变化，一般由运营同学来维护

前端分类体系

分类体系分为两种

一般由运营同事进行维护这种关联关系

前、后端分类体系都是树状的结构，后端分类树的任意节点可以“挂载”一个或者多个前端分类树的叶子节点上面，这样两套分类体系之间就产生了关联

分类检索

用户通过关键词或者分类检索出的商品结果，自然排序都是按照相关性评分进行排序，评分高排序靠前，评分低排序靠后

商品相关度评分计算模型，需要根据业务情况来搭建，商品的评分也是由单独的模块进行计算得出

自然排序下，还有一些其他因素影响排序，例如有库存在前，无库存在后等，或者其他与业务相符合的逻辑

还可以按照其他条件排序，例如价格、好评率、优惠力度等，

有时需要将某个产品在搜索结果中前置、沉底、屏蔽等，因此检索系统后台就需要维护这么一份商品的“黑白名单”，在历遍所有排序规则后再进行一次排序

相关性+销量+人工干预，相关性和销量为绝对存在的值

人工干预包括人气排名，如成交量好评率收藏人数浏览量卖家信誉，根据以上综合计算

商品排序的常用逻辑

商品排序常用模型

商品排序的常用诉求

排序

分类过滤

标签过滤

价格区间过滤

地域过滤

库存过滤

是否自营

自定义过滤（根据业务情况而定，确定过滤的规则，如测试数据的过滤）

因为某些要求，需要在触发结果的基础上进行过滤，屏蔽掉部分结果的展示，常见的过滤如下

过滤

当用户检索商品时，检索系统除了展示检索结果以外，还会将检索结果的所有标签进行聚合和分类，传给前端进行展示

例如产品属性、价格区间、销量、评分等

标签聚合

SKU：库存的最小单位

SPU：商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性

当用户进行商品检索时，需要将SKU粒度的商品聚合成SPU粒度，使得检索结果比较多样，从而不至于满屏都是各种颜色、型号的同一款商品。等到用户进行商品详情页之后，再来选择具体的型号

SPU聚合

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

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

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

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

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

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

行为记录分析

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

搜索组成模块

后端包含的模块

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

精准搜索

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

粗略搜索

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

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

无目的搜索

计划搜索

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

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

临时搜索

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

用户使用搜索的目的

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

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

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

是否需要搜索功能

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

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

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

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

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

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

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

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

搜索入口的位置

常见的搜索入口的样式是搜索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类分析

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

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

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

市场总量分析

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

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

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

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

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

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

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

市场细分

市场机会分析

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

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

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

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

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

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

波特五力法

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

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

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

竞争生态分析

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

市场吸引力分析

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

矩阵分析

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

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

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

行业价值链分析

行业研究的六大标准框架

行业研究框架

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

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

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

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

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

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

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

CAC：用户获取成本

COC：用户运营成本

平台投资回报率(ROI) = 转化率*每个用户平均收入(ARPU)/(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

暂无

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

普拉姆理论的缺陷

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

优化需求管理流程

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

优化需求池

模型的具体优化

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

如何做需求管理

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

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

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

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

为什么需要产品架构图

复杂项目开始之前

何时需要产品架构图

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

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

列出问题域

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

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

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

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

如何列出问题域

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

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

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

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

确定解决方案与产品方向

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

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

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

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

搭建基础框架

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

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

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

处理不同信息层级的边界

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

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

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

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

明确架构分层

清晰的模块功能边界

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

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

具备迭代优化的能力

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

最终检查

如何制作产品架构图

如何构建产品结构

APQP：产品质量先期策划

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

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

PM的完成软硬两点

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

制定项目章程

搞清楚谁与项目相关

识别项目干系人

启动过程

编制项目执行的蓝图

制定项目管理计划

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

规划范围管理

收集要做什么

收集需求

确定要做什么

定义范围

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

创建WBS

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

规划进度管理

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

定义活动

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

估算活动资源

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

估算活动持续时间

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

制定进度计划

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

规划成本管理

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

估算成本

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

制定预算

确定合格的标准

规划质量管理

需要什么人，需要多少人

规划人力资源管理

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

规划沟通管理

定义如何对待风险

规划风险管理

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

识别风险

解开风险的面纱

实施定性风险分析

解开风险的真相

实施定量风险分析

定义如何应对风险

规划风险应对

买什么以及如何买

规划采购计划

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

规划干系人管理

按图索骥

指导与管理项目工作

通过过程保证质量

实施质量保证

组建项目团队

建设项目团队

管理项目团队

规划过程

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

沟通管理

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

管理干系人参与

购买要买的东西

实施采购

执行过程

盯着以及不停的盯着

监控项目工作

让变更在可控范围内

实施整体变更控制

让用户接受项目成果

确认范围

让范围在可控之内

控制范围

让项目进度在可控范围内

控制进度

让费用在可控范围内

控制成本

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

控制质量

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

控制沟通

让本次购买可控

控制采购

影响项目干系人积极参与

控制干系人参与

给项目或阶段划句号

结束项目或阶段

给本次采购划句号

结束采购

监控过程

项目管理的47个过程

项目管理47个过程

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

什么是着陆页（Landing page）

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

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

着陆页的特征

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

促成交易：购买

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

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

着陆页的类型（三种）

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

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

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

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

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

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

通过外部背书，增强用户的信任，打消用户的疑虑

可以通过权威人士的站台和背书，或者其他用户的正向评价

可以选择不同领域的人群代表，引发不同细分领域人群的共鸣

why are you（为什么选择你？）

利用限时或者限量优惠的方式推用户一把

限时或者限量礼包

成功的案例表述

action now（立刻行动）

人因情感而购买商品，并用逻辑性证明其合理性。因此，需要通过触及人的基本欲望和需求来激发情感反应，并最终达到你的目标——《极金广告》

WWWA转化逻辑

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

用图片来吸引用户眼球，处理图片信息的速度远远快于文字（图片中有人物形象的话，人物面向的方向，用户关注度更高）

可以尝试主标题为用户痛点，副标题为产品卖点

有一个与广告页呼应的主标题（主题与用户相关，例如给用户带来什么，或者能帮用户解决问题）

简单粗暴的告诉用户，留下信息能给你带来什么好处

语言简洁，设计简单

收集信息最好不超过三个

利用色块或者颜色对比，突出表格填写的区域

突出醒目的行动“提交”按钮

信息收集表格的要求

第一屏

结合用户痛点，介绍产品卖点

可以拆分为几个不同的痛点&卖点组合

用场景化／情感化／细节化的方式来描述用户的痛点和产品的卖点

把文案进行处理，显得更有画面感

行动按钮进行前置突出，在用户有感觉的时候，随时可以行动

第二屏

来自外部的声音，来自名人／机构／用户的点评和评价

选择用户评价时候，最好是可以选择不用领域的，增强用户的代入感

第三屏

呼吁用户采取行动，及早加入

提醒用户行动的好处，例如可以给用户带来优惠或者增值服务等，以刺激用户行动

利用限时的倒计时计时器来刺激用户

第四屏

对于要离开的用户，尽量低成本的与其产生关系，例如关注公众号免费试用等策略

最后

PC端引导填写类模版

页面较窄，页面能够承载内容的空间较小

用户注意力更短暂，页面停留时间短，浏览速度较快

交互形式更加丰富

移动端的特点

吸引用户的图片，解答能够给用户带来什么的问题

图片的主标题和副标题也是引导性质的文案

行动按钮永远前置（或滑动2-4秒钟之后出现，避免引起用户的排斥心理），让用户在决策的第一时间就可以触及行动按钮

用浮层或者向下翻动按钮的交互设计，引导用户向下翻页

展现用户痛点和相应卖点

主要注意的是这些内容在移动端的展现方式和文案内容，需要控制文案字数

同样，需要有画面感的文案描述，最好是具体场景

第二屏

展现外部背书的内容

除了用流的展现方式之外，也可以考虑使用左右滑动的卡片展现方式

煽动力的话术，或者是限时限量的活动和优惠等刺激用户

可以使用一个明确的点击箭头指向行动按钮

移动端引导点击类模版

例子：用户产生行为的成本越低，商家达到目的的难度越低，那么页面展示出来的转化逻辑就越简单，页面内容也就越少

用户行动的成本／理解产品或者服务的难易程度与转换逻辑的复杂性成正比

产品知名度越低，转换逻辑越复杂

产品的知名度与转换逻辑的复杂性成反比

页面展现内容多样性的标准

定位卖点（需求）

定位人群（用户）

定位场景（场景）

分别从以下三个角度的定位，进行文案的具体描述

转化型文案的拆解

着陆页有清晰的引导用户的转化逻辑（WWWA）

文案场景化

文案贴近用户，便于理解

用户视角，避免自嗨

言之有物的表达方式（文案）

货真价实的产品服务

高转化着陆页的特征总结

先验性：不用投放全部用户资源，使用部分用户资源即可提前完成测试，之后整体资料释放

并行性：节约整体测试的时间

科学性：依靠数据而非经验，变量更易受到控制

AB测试的优势

样本越大，结果相对越精确

流量情况：日均大于等于1000UV

人力成本：1-2人使用工具

拉长时间周期，也是为了扩大样本量

时间周期：大于等于7天

什么条件下使用AB测试

AB测试优化着陆页

点击热力图

注意力热力图

触达率

第一屏展现活动或品牌的价值主张

价值主张

让用户感受到与他的关系