本文仅作为学习分享，部分内容出处已找不到了，如原文作者介意分享会删除。

优秀产品法则：优秀的产品=满足用户的需求+牛逼的技术实现+优秀的产品体验

一、产品设计基本逻辑

二、业务层——项目及业务价值

什么是有价值的项目？

一位IDG的投资经理人道出了具有投资价值项目或产品的三个衡量标准：完美的团队；刚需；符合大趋势，顺势而为。

2.1系统定位：满足用户的需求

要知道用户的需求是什么，最有效的方法就是不断的提问。

Who——什么人；

Where——什么场景下；

why——什么目的；

why——遇到什么困难；

how——期望如何帮助。

2.2系统架构及模块抽象能力

程序设计本身服务可靠稳定：基础设施、架构、应用设计对容灾的考虑；

产品设计初期基本都是以老板的业务思路为中心，而老板看不出产品设计中的逻辑问题或者你跟他说他也不知道；以至于在很多情况下衡量一个产品经理的好坏变成了以原型画的好不好，所以现在很多产品经理的原型趋近于高保真，但其实这并不是重点。

我们以一个抽象的案例来讲述一下从0到1的产品设计本身很重要的一个问题；

（1）首先：很多产品经理都会画思维导图，从（产品功能点、设计点、交互、等等方面），但很多思维导图起不到指导原型设计的作用，造成很多人只会问你要原型而不是思维导图。

那么思维导图怎么话呢？初期我们以产品定位为导向，那我们画的思维导图就应该是下图这样的；

A：现在我们根据思维导图画出的原型及操作流程应该是如下图所示：

B：那如果我们在设计的时候，因为定位或者其他原因错误的把B定位放错在了A的后方位置，如图所示在产品初期这样的问题不容易被发现也并不会影响到产品设计：

（2）现在产品开始进行不断的迭代版本，每个功能/产品定位将衍生出很多分支；

行为线上的中间节点，因为只是获取结果的中间步骤，应该具有操作短，少分支的特点。但是由于初期的行为线设计的不对，导致在发展过程中，行为的中间节点有非常强烈的分支欲望。

如果发生1中提到的B现象，那么我们会发现产品的走向图如下：

在不断的迭代中会发生A和B产生非常大的关联，互相糅合的现象，但是产品的乱像已现，越来越控制不住了，开始往臃肿和混乱方向发展。更可拍的是，这个时候没人敢对日益庞大的，并且正在运行的运营产品下刀子，哪怕是老板自己都不行。

造成这个的原因其实是因为没有进行清晰的产品定位，错误的把和A具有同等级别的B放在了A的业务逻辑内，并且没有及时进行产品分离设计。

但是初期没察觉错把B放在了A1的位置上，后期B本身的特性导致了B有过多的分支。并且B的衍生分支和B作为中间节点的特性和A行为起始点的特性都不符合。但是这样的错误也不易察觉，把新开的B1-1，B2-2线作为新的功能入口就行了。

（3）其实要做到这样的这个很难，也是真正考量产品经理的功力的时候，首先还是对于业务的理解和思考，是深入的理解和思考，这是个前提。

依据这样设计出来的产品，有时候感觉不是自己在设计产品，而是产品本身在生长，产品自己在推动自己前进，只是需要我们最初的时候找到产品本身的种子，然后把它放在合适的土壤里。

产品本身是在自我生长的，不断的日益强大，而不是不断的勉强度日。今日找个山洞避雨，明天搭个棚子躲雪，为什么不是一开始就在建造小木屋然后慢慢改造成摩天大厦....

解决问题的办法就是：加强设计的中间过程，也就是思维层的抽象设计。更直白的体现就是思维导图。

2.3规划蓝图

2.3规划部分原文链接：https://www.zhihu.com/question/19561774/answer/140451886/著作权归作者所有

(1)明确做规划的目的

这个说得比较空，其实是比较关键的，直接影响你的规划结构和重点突出。不同的汇报人群、不同的产品阶段、不同的工作时间，规划的重点是不一样的。

面对不同汇报人群：

向上汇报：重点应该是突出规划的方向和你最终期望的效果，向领导说明怎么得出的方向，为什么可以这么做。

向项目组宣讲：重点应该是总结和突出规划细节，告诉项目组他们之前完成的成绩和接下来要做什么。

在不同产品阶段，就像很多回答提到的，不同的产品阶段会有不同的规划侧重点：

初步/成长期的产品：做好方向上的判断，也就是分析趋势上，避免走错方向

快速成长：突出产品路线图，指导迭代版本

稳定期：可以增加数据分析和优化方案，更多的用户分析和竞品分析

在不同的工作时间点：

年终、季终会有各种总结和规划，规划是很好的对过去总结和回望，对下一年做出大体的规划

进入工作高速期，会有不断的版本迭代，这时候应该突出每项的规划细节，包括需求List，优先级等等，而这种形式的不一定是要写PPT，用execl表格就能搞定

当然，最重要的目的并不是完成这份报告，而是对接下来工作的预期和产品节奏的掌控。规划决不能敷衍了事，“一年之计在于春”，这句话没错。

(2)列提纲

目的明确好了之后，我会把规划的结构列出来（可以使用常见的脑图），这样会便于写的时候整理思路，我拿我做的其中一次规划举例，这次项目是初步/成长期的产品，会突出行业分析和产品规划。大致以下结构：

数据总结和分析：过去项目的关系数据情况，分析下趋势，得出产品弱点和不足。

行业趋势和竞品分析：产品所处的行业趋势怎么样，出现了哪些方向。

产品定位：趋势有了，那么产品本身在这个行业环境的身份是怎么，结合身份、环境趋势、用户需求，你希望做什么，有哪些方向和Key Point，也就是产品定位。（最好用一句关键句表达出来，比如每个产品都有的slogan）

产品规划：结合定位中提出的Key Point，提出完成KeyPoint需要解决哪些问题，提出解决方案（关键句总结）

产品路线图（RoadMap）：完成规划需要做哪些功能，在什么时间段完成什么功能。

目标：最终期望达到的目标

(3)往提纲里填内容

数据总结和分析：

将项目的关键指标用图表的形式表达出来，关键指标大致分几类：流量、转化率、粘性、营收。流量包括：用户数总量，新增用户比率等等；转化率包括渗透率、点击率等等（当然每个行业都有不一样的转化率定义，比如ROI）；粘性包括留存率、人均启动次数、人均使用时长等等。针对关键指标的变化趋势，分析产品优劣势。

行业趋势&竞品分析：

这一部分需要准备的前期工作比较多，也看平时积累的多少，比如平时写的竞品分析等等，都可以用上了。行业趋势报告各大平台也会有，友盟、智观、企鹅智库、TalkingDate等等，附上链接：

友盟：【友盟+】数据报告

智观易库：易观－研究报告－行业分析报告－分析报告

TalkingDate：数据报告-移动观象台-TalkingData

一般找行业报告我会上面找，平时也会多看看。

ok，资料有了，读了那么多行业趋势报告，请用几句关键句总结下你认为的行业趋势，并分别用一页PPT来阐述这个趋势。（灵活阐述）

产品定位：

产品定位指的是产品的大方向，应该是一句总结性的句子，类似solgan。我认为这个就像指导思想一样（请看党的指导思想），在以后的工作中有引导作用，知道什么是重点，比如两个需求排期冲突了，优先排接近产品定位的需求。

产品定位应该结合产品所处的环境，也就是第二部分的行业趋势，加上产品本身的身份和用户需求来得出，我称之为Key Point，也就是你接下来要做的几个重点工作和方向。

当然就像我前面说的，不同的人群、时间点、阶段都有不同侧重点，比如成熟型的产品这部分可以拆解用户分析、竞品分析，重点突出这两部分，为后面提出优化方案提供依据。

别问我为什么用户分析那么简单，因为在此之前，我已经做过用户调研，理解了用户后才去写的，并全部加入此次规划中，会显得规划没有重点。（产品经理一定是要清楚理解用户需求和业务需求的）

产品规划：

针对提出的Key Point，一个个阐述。大致的逻辑是，列出你期望达到的目标，阻碍到达目标的的问题是什么（产品问题和现状），提出解决方案。

产品路线图：

规划完了之后，会有一堆要做的事情，也就是需求list，将这些需求list大致按时间线排列起来，当然也可以按里程碑串联起来。我这里列的是时间线的路线图：

目标：

提出合理的目标，可以是产品目标也可以是KPI（一般来说KPI是在规划前提前测算好的），这部分也可以说是打鸡血部分，对项目组有鼓励作用，对领导可以作为争取资源的依据。

三、逻辑层

3.1实体建模

实体建模描述原文链接http://www.woshipm.com/pd/934883.html

实体，一般是指能够独立存在，作为属性定位基础的东西。业内的实体概念具有此哲学思想以外，还是一个特定的软件模块。例如电商中的sku、品类、订单等均可称为实体，只是有些实体重要有些不重要。

实体建模，就是从业务流程抽象出实体，部分流程以实体为中心，便于理解和管理。例如抽象出订单实体，就可以根据流程管理订单的生命周期（状态）。

实体建模注意两点：实体的属性与生命周期和实体间的关系。

实体的属性与生命周期

一开始，选择哪些是主要实体的时候，重点要看业务流程中流动的是什么东西，有时候表面上看不出来，就需要思考共同点和本质。举个例子，在业务流程上，管理员会在一段时间内安排给用户一系列工作，工作是批量安排的，并没有明显的实体，通过思考后抽象出【任务】的实体，【任务】又分【母任务】和【子任务】，前者指管理员设置的任务，后者指用户自己的任务。

每个实体都会自己的属性，订单会有订单号、状态、卖家ID、买家ID等等，属性是用来做判断或者与其他实体关联的，订单的状态就是做判断，卖家ID和买家ID则是与其他实体关联，把主要的想到即可，具体。生命周期其实也是一种属性，单独拿出来为了凸显它的重要性，要包含实体的所有生命周期，否则会出现异常。

（2）实体间的关系

某种实体关系（矩形=实体，菱形=关系，椭圆=实体的主要属性）

实体间的关系是指实体的逻辑关系，包括实体和实体的关系以及实体属性和实体的关系。实体和实体之间是一对多、多对多、多对一还是一对一，例如一个帐号可以有多个订单，一个订单有多个SKU。实体属性和实体的关系，例如上面例子的【母任务】创建后才会产生【子任务】，而【子任务】又有完成、归档的概念，因此【母任务】创建后某些属性的修改就要注意。一般来说，实体和实体都是互相独立的，【子任务】这种算是特殊情况。

3.2角色结构

角色结构需要根据业务需求进行确认，确认后需要对权限进行划分。

角色结构：

角色结构主要考虑多系统通用的情况，比如一个用户在APP端或者第三方合作平台使用手机号、微信、QQ、第三方账号登录，我们要在必要的情况下根据关键信息将此用户归为平台的一个用户，做到账号共享。

*角色结构设计可参考如下实例（支付账号体系）：链接分享http://www.woshipm.com/pd/459443.html；这个作者的文字都是干货，支付界的朋友们可以多看几篇~

权限划分：

（1）权限怎么分？

方案：权限可以分成三种（1）菜单权限（2）页面权限（3）操作权限

（2）相同角色的人员，如果有个别权限不同，应该怎样分配？

方案：账号先选择角色，然后针对账号再选择对应的特殊权限

（3）公司的一些敏感信息应该怎么控制权限？

方案：把敏感字段当成一个权限来进行分配

3.3逻辑流程

逻辑流程就是要把实体、角色和功能（操作/判断/子流程）之间的关系想清楚想通透。每个模块包含哪些功能都会在梳理逻辑的过程中找到答案，也可以顺便理清楚模块和功能的优先级，后续可补充到产品规划中。

逻辑流程以不同的目标为中心会呈现出不一样的流程，以业务为中心的流程重点讲述的是业务的过程，以实体为中心的流程重点讲述的是实体的生命周期（状态），以操作为中心流程重点讲述的是交互和判断（也可以到交互层再画）。

以业务为中心的流程就是要把上述的实体、角色和功能（操作/判断/子流程）集合到一张图上。要体现出以下两点：1.每个角色在业务中的作用，其实就是每个角色的主要功能或者操作 2.核心功能，与业务直接相关的功能或者操作，例如点击【去支付】订单生成等，如果非核心功能流程太多可以直接用子流程代替。

以实体为中心的流程要体现出实体的生命周期，设计实体的生命周期的时候要符合客观事实，系统中很多地方的判断都是要根据实体的生命周期的。要体现出以下点：1.包含实体的所有生命周期，绝对不能遗漏 2.什么操作/判断会调整实体的生命周期，逻辑合理描述清晰。

四、交互层

4.1模块功能

4.2页面结构

页面功能结构，它不是设计稿，也不代表最终布局，线框图所展示的布局，最主要的作用是描述功能与内容的逻辑关系。

此处需要参考2.2的系统结构进行设计，尤其是注意层级关系和耦合关系。

此处可参考我写过的关于soul产品体验，里面有讲到页面设计不遵循系统结构设计的案例：https://www.jianshu.com/p/bc6cf02fd814

4.3产品原型——交互设计（少即是多）

原型设计：用户需求最终都要可视化，抽象的需求最终都要反映在具体的产品形态上。

用户价值不会因为是统一了（大而全）而体现的，而是每一个单项是否能真正赢得用户的喜爱。“简单”的核心在于，做好最核心的10个，放弃其它的90个。

技术人员总希望将每个需要的不需要的功能都铺在面板上让用户看到。而好的产品总是让用户看不到技术的存在。

交互设计：交互体贴细致，视觉简洁清爽

产品体验—高端用户/差异化产品的影响力

高端用户(意见领袖）的关注：有用户价值我们就应该这么做。赢得高端挑剔用户的口碑；

做差异化和高端化卖点倒是不错，未必有多少人用，但能影响人。

[例如：当前QQ邮箱提供的IMAP4功能，只有QQ和GMail做了免费的IMAP服务！]

[例如：苹果手机做的触屏按压技术，其实使用的人很少，但是这是一个和其他手机差异化的一个功能，当他发布的时候别人还是觉得很厉害，对这个产品进行传播。]