下面这篇文章是笔者以一家真实公司真实业务（关键内容脱敏）为背景，介绍如何在产品规划完成的情况下，快速出原型图的相关内容，大家一起往下看了解更多关于修订记录与全局说明的内容吧！
这一系列文章我会以一家真实公司真实业务（关键内容脱敏）为背景，介绍如何在产品规划完成的情况下，快速出原型图。之所以要用真实的公司和业务，是因为这样才会有更多的细节可以给大家解释，而不是泛泛的画一些标准的操作流程。很多时候，产品设计的不好就是因为挖掘需求的时候没有挖掘到关键细节导致流程断点、功能缺失等从而导致用户体验差。
本文大纲
这次先向大家介绍一下产品原型模板中的修订记录与全局说明。它们在文档中的位置：
在发布产品文档时，需要在修订记录中增加本次发布与之前发布内容的关键差异点，以后备查、复盘会用到。
修订记录在文档中一般长这样：
主要包含：业务背景、上层的应用规划、本文档对应产品的产品规划、整份文档都会用到的术语、整份文档都需要遵循的规范等。
因为这些信息对整份文档的所有内容都有影响或约束。举例子来说：
业务背景、规划等，是这份文档的上层文档，约束了这份文档的范围。没有业务背景，就没有要解决的业务问题。没有应用规划、产品规划，就缺失了解决问题的方案的顶层规划。这些都是本文档（OMS系统原型）的上层约束信息。具体可以看看下面我画的草图。
术语：主要包含业务语言中的术语，以及产品技术语言中的术语。你在跟业务方沟通时，经常用的一些名词、动词可能就是业务语言。大家有空可以了解技术领域的DDD的思想，这个我以后在业务建模相关内容时会展开介绍。技术语言就是你和其他产品、技术团队沟通时用到的名词、动词。一般来说，业务语言和技术语言要尽可能一致，避免理解差异，这样业务和技术团队的沟通成本才比较低。
举几个例子吧：
业务术语：业务方口中的订单、渠道、商品分别指代什么？订单是客户原始订单，还是OMS中的标准订单？渠道是分销渠道，还是商城店铺？商品是SPU、SKU还是ERP中的物料等等。
技术术语：虚拟库存、实物库存是什么？物料是什么？订单头、物料行、配送行等是什么？。
规范：对文档中的样式、描述方法等作出统一规范。比如文档的框架、流程图画法的规范、页面原型的框架等，文档中重复做的事情尽量形成统一的规范。比如文档中有大量的页面（列表页、详情页等），那就制定一个页面原型框架；比如有非常多的操作流程，那就制定一个流程图规范；比如每个页面都会有功能的解释说明，那就制定一个功能解释的规范等。跟你配合过几次的技术同事熟悉这套规范后，以后看文档就很舒心，可以很轻松的定位和查找。最好一个产品团队使用一套规范。
下面对全局说明的关键信息展开讲一下。
1） 业务背景介绍
主要介绍本文档设计的系统，用来支撑的业务线的情况，发现的问题，系统建设的价值预期是什么。这是所有产品规划、业务流程、产品功能设计的起点。
一般来说，在某个系统的原型图这种最底层的文档中，会直接引用上层的文档（如产品规划文档、应用架构规划文档等），而不会直接对业务背景做详细阐述。可以看一下我下面画的草图，了解不同层次的输出物的关系。
底层文档引用上层文档的好处是：
关于如何从业务出发，逐层分析拆解出某个系统的解决方案，版本迭代计划，是另一个话题，在这里不展开。我画了一个草图，大致逻辑如下：
本次系列文章，对标的就是第五、第六层级的原型设计文档。
上面的逻辑是企业架构（EA）设计的逻辑，大家感兴趣可以去了解一下TOGAF。对比了解过的同学，可以发现草图里缺少了技术架构。原因是①技术架构太专业了，我没有能力阐述完整。②技术架构一般由技术架构师、技术组长等角色提供，产品经理一般不参与技术架构设计。
2）应用规划
对标上面的草图，应用规划属于第三层，要描述整个业务线或整个企业的完整的数据架构与应用架构。
数据架构对企业非常重要，但是另一个专业话题，在这里我不展开了。
应用架构就是完整的IT系统规划，除了各位比较熟悉的应用层系统（如OMS、SRM、OA、ERP等），还包括了底层的平台系统（如用户系统（含统一鉴权）、网关系统、门户系统、BI系统等）、底层技术系统（如租户系统、PaaS等）。
应用规划要回答的问题是，如何通过一系列的IT系统来支撑业务发展，解决业务问题。
3）产品规划
对标上面的草图，产品规划属于第四层，描述单个系统的整体规划，包括系统支撑的业务描述、系统关键用例、系统关键业务对象模型、关键业务流程等。
产品规划要回答的问题是，这个IT系统要解决什么业务问题，如何解决。
4）业务背景的模板示例
有的同学可能会问，系统价值怎么能精确到数值的？这主要看调研的深度和业务方的重视程度，如果业务方对这个问题非常痛，我们调研的深度能足够深入，那每个具体问题解决后预估的人效提升是能估算出来的，就能转换成业务的具体数值。
比如自动对账与结算功能，解决的问题主要是：①出我方账单，②与客户账单自动比对并输出差异报告，③快速调账，④出结算单，⑤推送开票与应收。
整体评估下来，对账功能整体提效80%以上。业务方领导可以根据这些方案描述，预估出是不是可以减少编制、减少出错而避免的经济损失等。减少编制不意味着裁员哈，只意味着这个岗位不需要那么多人了，多出来的人天可以调岗到别的岗位，或做别的工作。
我这里给出示例，大家要根据自己公司的具体情况整理提炼。
我给出几个示例供大家参考。
1）流程图规范
2）系统首页规范（截取）
3）列表页示例（截取）
4）创建页、编辑页示例（截取）
5）各种弹框的规范示例（截取）
本篇文章承接上一篇文章（PRD模板），介绍了修订记录、全局说明的内容，并用实际案例给了一些示例图。在全局说明部分，稍微展开介绍了一下产品规划的完整逻辑链，可能稍显啰嗦，欢迎大家在评论区探讨。
本文所有内容均为原创，示例图仅供参考，大家要结合实际调整。大家要自己练习找手感。
本文由 @Xinspace 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。