1.产品/数据产品设计

1. 概述

产品设计逻辑和流程可以分为3个环节：用户需求调研梳理、产品设计流程和产品原型及需求文档
数据产品的本质是更好地为用户提供信息服务。数据产品设计的关键点和起点在于深刻准确地把握用户需求，而用户需求的调研需要注意“两个重点，一个难点”：（1）重点①：对象与内容
产品提供给谁？提供什么信息？不同对象所做的决策不同，所需的“信息”内容也就不同。用户需求调研首先应该明确产品使用对象和信息内容。
（2）重点②：环境与状态
用户需求调研，不仅需要明确产品使用对象是谁，用户需要哪些数据信息等，还要考虑用户接收信息的环境和状态。用户接收信息的环境状态不同，信息传递的效率和效果也就不同。
（3）难点：如何通透地理解需求
第一，沉浸。通过反复与用户沟通，把自己“沉浸”在用户角色之中，从而更好地体会用户需求。其次，产品经理需要迅速把自己想象成“小白”，时刻体会自己第一次见到产品时所接收的信息和作出的反应。
第二，防止被误导。很多时候，产品经理必须问清楚几个问题：你为什么需要这个功能？你想用这个功能做什么？这个功能解决了你业务上的什么问题？有没有更好的方式或方法满足你的需求？
第三，明确主次。产品经理进行用户需求调研和数据产品设计时必须优先解决重要的、核心的需求。

2.设计流程

业务流程图
（1）先梳理战略，后梳理流程
不管是ToC（To Consumer，即面向消费者）产品还是ToB（To Business，即面向商业组织）产品，首先都要明确产品的战略定位。明确哪些流程是重点和关键，哪些流程是次要和辅助，明确流程梳理过程的轻重缓急。所有ToB产品经理要特别注意去理解企业或产品的战略定位，从而更好地梳理业务流程。
（2）先主干流程，后枝叶流程
业务流程按照不同的颗粒度可以划分为详细度不同的流程。建议主干流程活动步骤为5~9个。更加详细的信息可以在二级或三级枝叶流程中再展示，
数据流程图
业务流程图虽然能够帮助产品经理和研发人员理解业务逻辑，但是研发人员更关注的是业务流程中数据的流转过程，所以需要进一步从数据角度来探讨整个业务流程，这就是数据流程图的作用。
数据流程图有两个特征：抽象性和概括性。抽象性指的是数据流程图把具体的组织机构、工作场所、物质流都去掉，只剩下信息和数据存储、流动、使用及加工情况。概括性则是指数据流程图把系统对各种业务的处理过程联系起来考虑，形成一个整体。

数据对象包含很多属性，而属性也是一类数据，所以绘制实体关系图时要注意区分实体和属性。在实践中，某个事物是作为实体还是属性并没有明确的界定，需要根据具体情况和需要而定，一般遵循如下准则。
①属性不可再分。属性不再具有需要描述的性质。
②属性不能与其他实体发生联系，关系只存在于实体与实体之间。

各种图的联系和区别
①流程图的作用是帮助我们理解业务过程，也就是搞清楚事情究竟是怎么流转的。
②实体关系图和数据流程图分别从逻辑关系角度和数据角度描述业务过程，这两者有什么区别呢？简单说来，实体关系图是静态描述，更像是“照片”；而数据流程图是动态描述，更像是“视频”。数据流程图从数据角度来梳理业务流程，明确数据的流入和流出过程；实体关系图主要关注某个数据流转环节中实体之间的逻辑关系。

3.产品设计逻辑

产品设计可以细分为“数据信息”和“展示交互”两个层面，其中数据信息是展示交互的前提和基础。数据信息层面既包括信息点之间的次序和路径，也就是信息路径设计，也包括单个信息点的设计；而展示交互层面主要体现为单个信息点的信息展示和交互操作。从这个意义上讲，数据产品设计的核心逻辑包括：信息路径设计和信息点功能设计。

3.1 信息路径设计

什么是信息路径
产品原型只是产品方案的一个直观体现，是一个阶段性的交付物。产品经理在开始动手画原型之前还有一个重要的工作要做，那就是设计信息路径。产品设计可以从“数据信息”层面分为“信息点”与“信息点之间依存关系”两个部分，也就是说设计产品时不仅要考虑展示哪些信息点，还要考虑信息点展示之间的次序和关系。这里所说的“信息点之间的依存关系”就是“信息路径”。
当我们逛商场购买剃须刀时，我们会先看看商场的导视图，确认超市处于商城的哪一层；然后进入超市区域，再查看超市的导视图，找到日用品货架位置；走到日用品货架位置，最终找到自己需要的剃须刀。这里，我们通过导视图使用了“楼层-区域-货架-位置”这样的定位路径，很便捷地找到了自己所需要的剃须刀。其实，商场设计的“楼层-区域-货架-位置”信息展示路径，就是一个“信息路径”的案例。
信息路径设计思想
信息路径设计能更加准确、快速、高效地传递信息要点，便于用户更高效、更舒适地接收和反馈信息。设计信息路径时主要考虑两方面因素：
信息传递规律
数据产品的作用从某种意义上讲就是将数据中蕴含的信息点高效地传递给用户。用户接收产品信息的效率和效果会受到人类固有认知规律的约束，所以了解用户信息接收规律对于产品设计具有重要意义。产品经理需要了解一些基本的认知规律。
（1）短时信息容量
哈佛大学心理学家乔治·米勒发现，普通人的心智不能同时处理7个以上的单位，人类大脑短时记忆的规律：不能超过7个信息点。
（2）大脑厌恶混乱的信息
心理学中有个著名的“格式塔效应”，揭示了我们大脑倾向于从混乱中寻找模式，极力从不同的信息点中寻找规律和联系，而厌恶混乱的信息。
（3）大脑认知抗拒改变
大脑认知还有一个特征就是一旦形成了固定认知，改变起来极其困难。例如，由于宝洁公司大量的广告轰炸，人们一想起“去屑”就会想到“海飞丝”；一想到“柔顺”就会想到“飘柔”。市场营销中的“定位”学派，正是利用人类认知的这个特征，通过各种营销手段来抢夺用户的“心智”。
用户使用场景
用户接收信息的效率和效果不仅受到人类固有认知规律的约束，也受到用户产品使用场景的影响。比如，滴滴司机开车过程中接单的页面，信息就必须简洁清晰，字体尽可能大，字尽可能少。
产品经理设计产品时需考虑用户产品使用场景，从信息角度来看，就是要考虑产品使用场景的时空因素对于用户接收信息的影响，这也是信息路径设计时需要重点关注的方面。
（1）使用场景的时间特征
关注产品使用场景的时间特征就是关注产品使用的时间长度和时间分布。产品经理需要明确用户主要在什么时间点使用、使用时长为多久，从而考虑信息点呈现的数量和次序。
（2）使用场景的空间特征
关注用户产品使用场景的空间特征就是关注用户产品使用的空间位置和特点。例如，用户是在户外使用还是办公室使用？用户是在静止环境下使用还是在移动环境下使用？
常见的信息路径
产品经理进行信息路径设计时既要考虑用户的认知规律，也要考虑用户的使用场景，从而清晰地知道用户信息接收的具体特征，便于设计对应的信息路径。
人们认识事物总是首先关注宏观和整体概况，从而有个全面的图景和认识；然后关注细微层面的东西。
设计产品时一种常见的信息路径设计思路就是：首先向用户传递宏观层面的信息，让用户有个整体的感知；然后传递中观层面的信息，让用户能够聚焦到某个行业或区域；最后递进到微观层面，让用户了解具体的详细信息。这样，用户就像是查看地图一样，从宏观层面到中观层面再到微观层面，根据自己的需求不断递进，不断细化信息颗粒度。从“宏观-中观-微观”角度层层递进展示信息，是一种常见且有效的信息路径。
不过，有时候用户会对某个或某些信息点特别关注，这就需要产品经理使用另外一种信息路径“重要-次重要-次要”。
另外，在一些情况下，信息点的时间维度特征非常明显，例如，设计一款监测系统，对于“事前”“事中”和“事后”的监测指标数值的展示，就要考虑从时间维度展开进行信息路径设计。
总的来说，信息路径设计并不是一成不变的，它更为重要的意义在于提醒产品经理重视信息点之间呈现的关系。常见的信息路径可以归纳为以下几种。
①按逻辑关系区分：宏观-中观-微观。
②按用户关注度区分：重要-次重要-次要。
③按时间维度区分：事前-事中-事后。
除了上面的信息路径设计思路，实践中也有一些常见的经验做法可供借鉴参考和补充。
（1）按照功能相似性进行信息分类
产品经理在设计信息路径时，经常把相似功能模块放置在一个大的模块下，作为大功能模块的一部分。例如，微信中的“消息”包含了好友消息、群消息、订阅号消息、文件助手消息、陌生人消息等。虽然各种消息在存在差别但是都属于消息大类，所以我们会发现这些消息子模块都在归集在“微信”功能模块下面。而探索性质的或者时效性要求不高的模块，则归集放置在“发现”功能模块下。例如，“朋友圈”“扫一扫”“摇一摇”“看一看”“搜一搜”“附近的人”“购物”“游戏”等子模块都归集在微信产品的“发现”功能模块下面。
2）按照使用频率来设置展示位置
哪个功能使用频率高，就应该把哪个功能放在用户最容易浏览或者交互的地方。
（3）按照功能之间的业务关系来规划层级关系
功能与功能之间，一般有并列、递进、互斥等几种关系。功能之间如果是递进关系，设计信息路径时可以考虑纵向递进关系，例如，在京东商城购物时，“下单”和“支付”就是递进关系，用户需要先“下单”，之后才能够进行“支付”。
3.2 信息点功能设计
产品设计不仅要考虑“信息点之间的依存关系和次序”，也要考虑单个信息点的交互与展示，这就是信息点功能设计。信息点功能设计可以分为“交互”和“展示”。其中，交互主要是指信息的“增删改查”，展示则是指信息的“可视化展示”。
①信息增添：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息的录入或添加。例如，淘宝网购物时的“新增收货地址”等交互。
②信息删除：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息删除。例如，用户可以在电子商务平台删除过往的购物记录。
③信息修改：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息修改。例如，用户修改“收货地址”或“联系电话”等。
④信息查询：在进行信息点功能设计时，经常需要用户通过交互按钮实现信息查询。对于大部分数据产品而言，信息查询是用户使用频率非常高的功能，需要重点关注。例如，时间筛选、区域筛选、文字搜索、排序等都是信息查询常见的功能设计。
而信息点的“展示”主要体现为“可视化”设计，这部分内容将在数据可视化章节进行详细讲解。

4 产品原型及需求文档

产品经理从用户需求出发，依据产品设计逻辑和流程将用户需求转化为产品原型和需求文档后，研发人员才能够根据产品原型和需求文档开始研发工作。所以，产品原型和需求文档既是产品设计流程的结果，又是产品研发流程的开始。
4.1 产品原型
原型图，也被称为线框图，是产品经理将用户需求转化为产品解决方案的重要载体，是产品经理与研发人员进行沟通的重要工具。
4.2 需求文档
产品设计是一个将用户需求由抽象概念转化为具象化产品的过程，经常需要借助文字或图像进行展现，这就是产品需求文档（Product Requirement Document，PRD）。PRD主要是给设计、研发等相关人员阅读的文档，目的是告诉这部分人员产品页面内容、交互规则和输出结果等详细信息，像是一份详细的产品功能需求说明书。

PRD概述
PRD是产品经理用来跟技术开发人员和其他相关人员进行沟通的辅助文本工具，由产品经理负责撰写。这里有两点需要注意。
第一，它是文本工具。这也就是说，相对于口头沟通，PDR能够使沟通过程和沟通意见落在纸上，同时也为后期沟通提供了文字记录，便于查询。
第二，它是辅助沟通的工具。PRD不是用来划分责任归属的，而是用来辅助沟通的。大量的沟通还是要通过产品经理和技术开发人员口头交流来完成，PRD只是把沟通的关键性结果做一个留档和备份，便于后期随时查询使用。
一般说来，一份完整的PRD至少包括3个部分：需求描述、功能描述和变更记录。
需求描述
需求描述是告诉技术开发人员和相关人员“为什么要设计开发这个功能”，是产品存在的基础和前提。产品需求根据对象的侧重不同可以区分为：业务需求和用户需求。
业务需求：业务需要表达的是组织或客户高层次的目标。业务需求侧重描述组织为什么要开发该款产品或者希望通过这款产品达到什么目标，它通常表达的是项目投资者、产品购买客户等的需求。
用户需求：用户需求是指产品的功能满足了用户某个场景下的使用需求，解决了用户的某个问题。这主要是从用户角度来定义和阐述的需求，描述了用户能使用系统来做些什么。例如，用户需要对产品的全球销售情况有一个直观和宏观的印象，这就需要给用户提供一个可视化界面，直观地展示产品全球销售的关键信息点。
功能描述
功能描述规定了开发人员需要在产品中实现的软件功能，用户可以使用这些功能来满足其业务需求。功能描述既可以从人和系统的旁观者角度来描述，也可以从产品角度来描述。前者叫用例描述，后者叫功能点描述。实践中，功能点描述多采用在Axure原型图旁边注释的方式，而用例描述更多采用PRD方式来详细论述。
无论是用例描述还是功能点描述，其最终目的都是希望研发人员能够快速清晰地理解产品功能需求。所以，一般包括以下内容。
交互规则：交互规则是指使得产品元素状态发生改变的规则和规范，既包括用户交互规则，也包括元素状态自动变化的规则。例如，用户操作产品页面上各种交互元素和组件（筛选按钮、滑动条）使得产品状态发生改变；或者系统自动设定了元素状态变化规则，如电商平台自动设定了打折时效期，一旦过了该段时间，商品价格自动复原等。
数据规则：数据规则主要是指数据产品展现层与数据库进行数据交互的规则。例如，用户通过注册页面输入信息并存储在数据库中，那么就需要指明注册页面包括的字段、每个字段的类型及长度等内容。
变更日志
变更日志的编写并不复杂，但是一些产品经理常常因为怕麻烦而忽略了，这往往给产品研发带来不小的隐患。
产品需求变动其实是很正常的事情，但是如果需求变动没有及时记录，那么可能会出现这样的情况：产品经理想表达的是A，结果表达成了B，技术开发人员听到的是B，理解的内容却是C，最后因为客观限制把产品做成了D。如果及时把需求变动记录在PRD上，那么技术开发人员和产品经理沟通就不仅限于当时口头沟通的“一瞬间”，而是有了可以进一步细致讨论的基础和材料，使得双向细致的沟通成为可能。
另外，如果产品需求变动不及时记录，一段时间后可能会因为遗忘导致各种问题。产品原型不可能一步到位。有了更新日志，大家一看日志就知道产品经理改了哪些地方，进而直接锁定修改目标，大大提升研发效率和开发进度。一个合格产品经理一定要养成及时记录变更日志的良好习惯，也要对变更日志给予足够的重视。