产品思维在产品管理和用户体验设计之间构建了富有成效的关系，这种关系让产品变的更强大。

                                                                ————某位Dribbble大佬  

文字较多侧重于描述：产品这个岗位在工作中需要具备的技能，发挥的作用，整个产品的知识体系有哪些。共计会分为七篇文章描述。供各位 UI 设计师参考。

这部分在开头略做解释：各位在生活中使用某一款产品的时候一定会被他的一些有意或者无意的设计所苦恼到。而精益产品设计则是为了去不断完善产品设计中无意造成的一些缺陷型设计。如：当我们的手机静音时闹钟是否会想起、当我们骑共享单车时会有两个小时的时间设定等等

讲道理上海的春秋天骑行真的很舒服（屌丝的快乐）！哈哈哈哈哈

目录：

        一、业务逻辑设计

        二、功能设计

        三、流程设计

        四、框架设计—【功能、内容组织—框架（导航）选择】

        五、原形设计

        六、版本迭代设计

        七、PRD —[文档描述—产品描述—功能描述—非功能需求—其他】

一、业务逻辑设计

业务逻辑即用户与产品之间的逻辑关系，业务逻辑设计明确了产品的用户角色有几种，每一种用户角色需要通过产品完成哪些任务，并且通过不同角色之间的协作以实现业务流程闭环。

所以，在业务逻辑设计阶段，作为产品经理需要回答两个主要问题：

产品用户角色有几类？

各类用户角色与产品之间的关系是什么？

上图简单解析了滴滴出行的业务逻辑，滴滴出行主要用户角色有两类，乘客与司机。乘客通过滴滴平台下单，平台

运营方基于算法将订单派发到合适的司机端，司机接单前往指定地点接客并送达至目的地，乘客付款，司机收款。

至此完成了滴滴的闭环业务流程。

二、功能设计

功能设计就是将业务逻辑设计中所描述的用户与产品间的关系转化成具体的产品功能。在功能设计阶段，还需要在业务逻辑具象化、功能化。

在进行功能设计过程中，除了要考虑前面我们明确的业务逻辑外，还有几个方面是应该考虑的：

1. 用户需求

功能是为了满足用户需求的，所以在功能设计时要充分考虑用户需求，以人为本，以满足用户需求为第一目标。

2. 用户任务

用户任务就是用户通过使用产品而完成某一个既定目标，在功能设计时要考虑到用户在完成任务路径上会做什么，如何让用户更快、更容易完成任务。

3. 使用场景

要考虑到用户在什么场景下使用产品或功能，如 PC 端个人状态分享时会以文字、图片为主，而在移动端如微信在朋友圈进行分享根据用户的使用场景在图片、文字基础上又加入了小视频这种符合用户使用场景的功能。

4. 技术限制

不是所有的功能都能被开发团队所实现，很多时候功能的可实现性都很大程度上依赖于技术能力，在功能设计时要考虑功能技术上的可实现性。

5.竞品

对竞品的功能分析也是在功能设计上常用的一种方式，通过对竞品功能的取长（抄）补短（袭），完善我们的功能设计。

三、流程设计

流程设计，即通过时序顺序描述产品或功能是如何运行的，简单来说就是从哪里开始、经历了哪些步骤，到哪里结束。

1. 回归业务逻辑

业务逻辑是从业务即具体使用人的角度对某个任务执行过程的描述，而流程就是对业务逻辑的流程化体现，所以在进行流程设计前要先明确业务逻辑， 这样设计出来的流程才能与实际相符合。

2. 明确用户与任务

明确每一个流程中具体的用户是谁以及任务是什么。

3. 开始与结束

明确流程从哪里开始、到哪里结束，一般情况下流程只会有一个开始和一个结束。

4. 参与角色

有时流程中可能不止一个参与角色，这时就要梳理清楚不同角色执行任务的顺序以及协作过程，通常对于多角色参与的流程可采用泳道图（流程图的一种）进行流程展现。

1. 明确顺序及异常情况

明确流程的执行顺序，在流程中如果遇到用户执行错误的操作或者系统发现异常如何处理也是要在流程设计中考虑清楚的。

2. 优化、调整

完成流程设计后可以找业务专家或者真实用户参与测试或建议，对业务流程进行优化或调整。

3. 输出文档

最终形成业务完善的流程图。

四、框架设计

架构设计是将产品的功能和内容有序的组织在一起，让用户更容易找到自己想要的内容，可以通过入口的安排、内容组织传达、突出某些信息给用户。主要涉及对功能内容的组织以及对框架（导航）的选择。

1.功能、内容组织

对功能、内容的组织，又称为产品信息架构设计，即如何将功能、内容进行层级化整合，让用户在使用产品过程中可以很快明确某一个功能或某个内容在哪里。在进行功能、内容组织设计时，通常考虑一下几个因素：

1. 用户的理解

在进行内容、功能组织的时候要充分考虑用户思维，按照用户理解的方式对功能进行分类组织。如果对功能的组织分类把握不准，可以采用卡片分类法加以判断。卡片分类法先将产品的所有功能写在一张张卡片上，然后邀请目标

用户来对卡片进行分类，最终得到的结果就是从用户的角度所理解的产品功能组织方式，在进行功能组织的时候可以参考卡片分类的结果进行功能与内容的组织。

2. 功能和内容使用频次

在进行功能和内容的组织时，考虑用户对功能以及内容的使用频次，将高频次的功能与内容放在用户更容易找到的地方。

3. 产品的核心功能

产品的核心功能要放在突出的位置，让用户可以快速发现并且方便使用。

2. 框架（导航）选择

本文中涉及框架选择主要针对移动端产品设计，在 PC 端更多成为导航设计。

1. Tab 式

可以看到美团和站酷底部的 tab 式框架，用户在使用时可以轻松切换 tab 标签来实现不同内容的查看以及任务的完成。Tab 式框架是目前主流产品所采用的方式，同样一款框架有优势也必然有劣势。

优点：主要功能突出，用户不需要寻找方便各功能入口间频繁切换

缺点：功能过多时，均放在 tab 导航会显得过于笨重沉浸式体验不足

2. 抽屉式

网易云音乐和 QQ 就是抽屉式框架的代表之一，将不同功能模块的切换隐藏在APP 的左上角，点开后才会展现不同功能模块的选项。

优点：给内容也足够展示空间，营造沉浸式体验

拓展性好，侧边栏可以提供更多功能入口展示空间缺点：主要功能入口不够突出

切换入口需要二次点击

3. 跳板式

跳板式指产品的功能在首页面上以一个个面板的形式展现，用户可根据自己的目标选择相应面板功能跳转至相关功能页面，这其中美图秀秀是这一类框架的典型代表。

优点：清晰展现各个入口

可以展示多个入口缺点：重点功能不够突出

各个入口间跳转不灵活

4. 列表式

列表式框架在内容类产品中应用的更为广泛，内容型产品以提供用户信息为主，将信息以列表的形式展现给用户，让用户可以获取更多内容。

优点：内容层次清晰

可展示内容多

缺点：内容过多时，无法突出重点内容

5. 结合式（推荐）

 

上述四种框架结构是目前移动应用所采用的主流方式，如果你有过很多产品的使用经验你会发现，其实每款 APP 并不是只应用了这其中的某一种，而是根据产品的特点选用了其中的某几种组合使用，如上面提到的知乎日报的例

子，在内容展现上采用了列表式框架，在产品功能模块上就采用了抽屉式框架进行辅助。

 

所以，根据产品的特性，有针对性的对框架进行组合，会让产品架构更加符合用户的目标，框架的样式不是重点，重要的是让用户可以更容易找到自己想要的功能与内容。

五、原形设计

原型设计，即对最终产品个页面内容简单呈现，是将产品需求整合后的产品化体现以及用户将如何与产品发生交互。原型是产品经理要完成的关于对产品构思的形象化文档，为后续的交互设计师、开发团队提供参考。

1.原型的作用

1.1 整理自己想法和思路具象化手段

1.2 帮助你将你的构想传达给交互以及开发团队

1.3 开发团队的参考文档

2.原型设计流程

1.1 根据信息架构图，明确产品的功能模块

1.2 规划用户任务路径，明确用户任务过程中需要的功能点

1.3 明确用户任务路径上的具体页面，将功能点与页面进行匹配

1.4 形成页面流程图

1.5 完成具体页面设计

 

3.关于原型设计的几点建议

1. 不纠结绘制工具，原型绘制的工具很多 Axure、墨刀、PS、Sketch 等等数不胜数，在这里不要纠结使用哪种软件更有逼格，只要能把产品的构想完整表达出来就行。

2. 不追求高保真，关于产品原型的完成程度以及交互细节，产品原型一般有低保真（简单线框图）和高保真（带有复杂交互动作的线框图），网上关于原型交互的教程也很多，但是在这里我想说明的是与其将时间用来制作高保真原型，不如用更多的时间研究如何让产品的用户体验更好，更符合用户的使用习惯。

3. 不过度设计，在进行产品功能设计时要充分考虑目前市场上流行产品的用户使用习惯，除非你要做一个革命性的创新，否则最好还是按照主流用户习惯进行产品功能以及流程设计。

六、版本迭代设计

版本迭代设计的概念在需求决策阶段就有所提及，在需求决策阶段对需求优先级的排序决定的是当前版本要解决哪些需求，那么哪些需求延后解决，哪些需求再延后解决呢？这就需要进行版本迭代设计。

通过对多款优秀产品的成长路线分析发现，具备较好成长前景的产品都是把握良好版本迭代节奏的产品。通过将产品生命周期与版本迭代路线结合研究分析，产品在探索期迭代节奏较快，这种节奏随着产品核心功能打磨完成进入成长期后会逐渐放缓，当产品进入成熟期后会继续减缓。一般来说，产品在探索期会保持 1-2 周一个版本的迭代速度，进入成长期后会保持在 2-3 周，当产品进入成熟期后会延长至 1 个月左右更新一次。当然，这个迭代节奏针对大部分产品而言，对于特殊产品来说需要特殊分析对待。

什么是好的版本设计？

其实本质上来说又回到了如何做需求决策的问题上，版本迭代设计就是决定哪个需求在哪个版本解决的问题。

（其实这部分内容在需求决策一篇有过详细介绍，可以查看需求决策部分的内容。）

七、PRD

PRD 又称产品需求文档，是产品经理需要掌握并且经常用到的文档之一， 产品需求文档的内容即对精益产品设计流程中每一个环节的文字化展现。将产品设计形成文档交付给 UI、UE、研发等团队进行产品下一阶段的开发，将原型变成真正的“产品”。

1.文档描述

1. 文档目的

PRD 文档的主要面向群体是研发，是在 BRD 文档之后，对产品需求的进一步细化，通过结构化的语言让研发更容易理解产品需要做的内容是什么。

2. 产品目标

产品希望达到什么目标，满足用户什么场景下的什么需求。

3. 术语缩写

产品的业务逻辑上有很多术语，也许是技术研发人员不了解的，通过术语缩写的解释，让研发人员对产品的业务逻辑更加明确，不会影响产品研发进度和内容

4. 版本状态

通过版本状态，修订人以及修订内容，让以后接触的人可以快速了解产品情况，同时对于产品需求变更有更明确的认知

2.产品描述

1. 整体描述对

产品的整体信息架构以及产品的业务流程进行梳理，包含产品的整体架构以及主业务流程。

2. 需求描述

针对业务流程，进行具体需求描述，细化业务需求。

3. 角色区分

通常产品的使用用户不止一种类型，在这里对所有使用产品的用户进行划分，对不同角色用户的需求进行分类描述。

3.功能描述

1. 业务流程

通常一个产品会包含多个功能模块，针对每一个细化的功能模块，又有具体的业务流程。

2. 界面原型

针对于产品设计的线框图，这里会产出低保真或高保真原型图，基于目前快速迭代的产品策略，一般都会输出低保真原型图以保证快速开发上线。

在界面原型的基础上，需添加逻辑规则和交互规则以让研发团队或交互设计团队理解更多的产品细节，开发出符合产品需求的产品。

逻辑规则，即产品功能点、字段的逻辑要求及限制（如登录注册页面中，手机号字段首位必须为 1，手机号必须为 11 位）

交互规则，即用户使用功能后给予的反馈是什么，如功能按钮发生点击、翻页等交互动作时会产生什么效果

3. 业务说明

针对复杂的业务逻辑和业务流程，对角色进行区分，针对不同角色的操作进行需求描述。

4. 字段说明

字段说明涉及研发人员在进行产品开发时的细节问题，一般会对数据字典，字段的类型，范围进行说明，方便研发人员进行产品研发。

 

4.非功能需求

根据不同产品及公司需要，这部分内容可能会有所不同。本文中实战案例中非功能需求包括安全性、统一性、实用性等原则。

5. 其他

根据产品、团队的不同，个性化加入相关需求说明。

最近上海的风好舒服！

骑单车更快乐！

加油，少年么！！！！！