需要了解的产品结构图

发表于 2019-02-20 分类于产品阅读次数： Waline：

唐杰的产品结构图梳理

1. 信息结构图（罗列信息）

在写产品需求文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来设计功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。

罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是使用思维导图软件( MindManager )罗列成结构图，因此我称这一步为「信息结构图」。

2. 产品结构图（梳理需求）

当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步就要梳理产品的需求。在设计产品原型之前，我们首先要罗列出产品的功能结构，包括频道、页面、模块及元素。这一步依然使用思维导图软件，像绘制楼盘鸟瞰图一样将产品的结构绘制成结构图，因此我称这一步为「产品结构图」。

产品结构图是一种将产品原型以结构化的方式展现的图表，结构内容也如同产品原型一样，从频道到页面，再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式，并不是给其他工作人员查看的文档，通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然，也方便思考。

3. 界面线框图（原型设计）

当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

原型设计是帮助我们更细致的思考，并做各项需求的评估，同时也是将自己脑海里的想法进行输出的一种方式。通过原型设计后，我们就可以进行产品宣讲了，相比较于抽象的文字描述，原型则更加直观的展现产品的需求，设计和技术人员或者老板也能够更加直观的了解到产品意图。

原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner 等等。

当到了原型设计这一步时，已经不仅仅是构思了，我们需要更加深入的了解每个页面上的元素和这些元素的属性。例如按钮元素，我们就需要考虑这个按钮的功能，并且这个功能操作后带给后端和前端的反馈。例如注册会员按钮，用户操作后，第一步逻辑是验证用户输入的信息是否合法，不合法则给出前端反馈；合法则和后端通信验证是否已经存在同样信息，已经存在则给出前端反馈，不存在则进入下一步，注册成功；注册成功后的反馈是跳转页面，还是弹出层提示用户完善资料，这些都是需要更详情的考虑。当然这些更细致的思考是留在需求文档撰写时的，而此时我们需要做的就是把这些元素通过原型表现出来。

原型设计的表现手法主要有三种：手绘原型、灰模原型、交互原型。从工作效率的角度考虑，我非常建议先通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性。当方案的可行性被验证之后，我们再根据个人习惯或团队要求，通过软件工具进行更深入的设计。

4. 用例模型（产品用例图）

用例( Use Case )是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作，或者技术人员任务交接时，让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑。

用例起源和发展于软件时代的产品研发，后来被综合到UML规范之中，成为一种标准化的需求表述体系。虽然用例在软件研发和技术工作中应用的非常广泛，但是在互联网产品规划和设计中，并不经常使用，互联网产品的需求表达为了敏捷效率，通常采用原型加产品需求文档。

5. 功能流程图(逻辑流程)

前面几步我们将产品需求逐渐细化并且通过原型的方式将产品需求形象化的展现了出来，但是在产品功能的逻辑细节方面，原型就非常不直观了，所以用例是一个非常重要的描述需求过程的文档。

但是由于用例文档以文字为主，并且格式复杂，不适用于高效率的产品需求表述，所以展现逻辑流程的「功能流程图」是一个简洁直观的可替代用例文档的方式。

6. PRD 文档（需求文档）

前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节，到了这一步的时候我们已经非常清晰的了解产品需求，此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。

产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式，主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的，所以产品需求文档没有统一的行业规范标准，无论以什么样的格式撰写产品需求文档，最终的目的都是让执行人员能够理解产品需求，根据需求完成产品。

产品需求文档的表现形式有很多种，常见的有 Word、图片和交互原型这三种形式，文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中，我们可以自行不断的修改完善，但是如果正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录，这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录，格式都大同小异。

来自：杰出产品经理书