在产品工作中，时常会遇到需要不断返工改进的情况。那么，如何避免设计漏洞，减少返工的情况呢？本文将从四个方面出发，对这个问题展开分析，希望对你有帮助。
“我只是一个初级产品经理嘛。”
我相信这是很多初级产品经理经常挂在嘴边的话，当设计出来的产品大洞套着小洞，那不对这也不行，几个问题扛不住就给自己找说辞。甚至还变本加厉认为，产品嘛，就是要不断返工，不断总结和改进问题的岗位。
以前我也是这么认为，但是，如果产品经理总是这么后知后觉，那岂不是每个人都能当产品经理？那产品经理的核心价值体现在哪里？真的只是个画图仔吗？
当然不是，产品经理就是要先人一步，事无巨细地考虑每一个设计点，降低增加资源成本的风险，这是身为产品经理的自我硬性要求，无论你是处于什么阶段的产品经理。
那有没有一个系统性的方法能帮助我们设计产品，避免出现上述问题呢？
有！其实很多时候设计的返工，只是缺少了一个重要的，系统架构设计的过程，这个设计过程的方法论，称为纵横深梳法（来至于《无漏设计》，考虑到要适用到B端产品，有适量改编）。
纵横深梳法可以规范我们的设计过程，提高设计的质量，减少无谓的返工。
主要分为4个步骤：
功能架构梳理
纵向流程梳理
信息架构梳理
展示架构梳理
一、功能架构梳理
功能架构梳理是把核心业务延展成具体的功能，不考虑用户的操作和提供给用户的信息，只考虑3个原则：是否满足用户需求、是否满足系统需求，以及整个系统中不同模块和细节是否相互矛盾。
来，我用一个简单的小功能（手机备忘录）作为示例来演示这个过程。
首先我们来分析需求，手机备忘录需要解决我们什么痛点？从场景出发，有两个业务场景的痛点我认为（错了别打我，哈哈哈）是必须要解决的：日常琐事太多需要记录，以及太多任务要及时提醒用户去完成。
那么核心功能就出来了，笔记与待办。此时已经满足第1个原则（是否满足用户需求）。
接着第2个原则，是否满足系统需求。我不喜欢用太官方的描述来解释系统需求，简单来说系统需求，就是为了满足用户需求所产生的其他需求（如账号管理、权限管理和日志管理等）。同时这个原则也会贯穿在纵向流程梳理的过程中，以来完善功能架构。但因为本示例很简单，第2个原则可以不做考虑。
第3个原则，整个系统中不同模块和细节是否相互矛盾。即功能的设计尽量不遗漏不重复（刚刚好），同时更要和谐统一，形成业务闭环。这一原则非常考验产品经理对业务理解，当然，因为实际项目的情况一般来说都比较复杂，所以做不到也没有关系，在后续的步骤中可以完善这一环节。
二、纵向流程梳理
纵向流程的梳理是在功能结构梳理的基础上，梳理每个主要业务流程。在这里我想分享一个概念「沙盘推演」。
「沙盘」是什么呢？沙盘是古代和近代军事战争中，常用于模拟敌我双方所处的地形以及情况，进行战争推演从而预测战争发展的方向。其作用价值在于预防潜在的风险和问题，和更好的规划、部署整体的产品节奏，为客户提供更优的产品。
那问题来了，如何进行「沙盘推演」？
设定沙盘场景，设定业务的虚拟场景，比如时间、地点、事件。时间即业务场景通常运行的时间，地点为场景所处的场地，事件即要去推动什么样的事情向前发展。
设定沙盘角色，在虚拟场景中涉及的所有角色，以及角色之间的关系。角色就是人，只有人才能推动整个沙盘的事件向前推动发展。
沙盘核心要素，注意两个点，一是1个业务场景是否只有1个发展方向，要尝试问自己以下2个问题：
当前推演的事件是否在不同时间点遇到不同人有不同业务流程或者事情？如果有不同的业务流程，那一条是最优的，以及为什么（注意成本、风险以及可能出现的问题）？
第二个点，流程要经过正向推导和反向验证。在正向推导发现正向问题之后，一定要经过反向验证，推导出非常规流程带来的风险和问题。
来，现在开始「沙盘推演」。回到我在01举的例子，首先设定场景，我会在什么时间点、什么地点以及什么事情下会打开手机备忘录APP记录一些备忘。
晚上9点，我在逛知乎时，在一篇”长的帅是一种怎样的体验“的回答下，发现了一金句，‘长得帅是一种无法与人说的孤独’。这句话和我内心产生了共鸣，我立即复制，打开手机备忘录APP，选择笔记粘贴上了这一句话。
场景和角色都具有了，说说沙盘的核心要素里的2个要点。当前业务场景是否只有1个发展方向。我举的例子中，是在我浏览知乎时截取一部分粘贴进笔记里，这个时候就问自己，是否只有进行手动粘贴的方式？
如果不是，更好的流程是怎样的呢？是否可以用选取一段文字弹出自动保存进笔记里的功能呢？是否甚至不用选择一段文字，双击下文章自动把语句分好，用户可以直接选取想要的语句保存进笔记呢（只是猜想，合不合理要根据实际业务判断）？
反向验证，是在一些有流程审批失败、流程发生意外等导致的业务流程回溯，手机备忘录例子因为有wo点lan小，所以就不给大家细说了。
经过「沙盘推演」之后，主要业务流程都梳理完成了，这个时候就可以跟客户进行更进一步的需求确认工作了。
三、信息架构梳理
两个字，对象。
流程的本质就是数据的演变，演变的过程主要由一个个业务对象参与的。角色对象、笔记对象、任务对象等等组成了手机备忘录流程的血液，换句话说，只要你把业务流程中的每个节点有哪些业务对象理清楚之后，你的信息架构也基本完成了，即使有不同，也只是对象的属性变化而已。
那么问题又来了，怎么把流程中数据抽象出一个个对象？
抱歉，我没有系统的总结过如何抽象对象，但是对象的来源有两个，我可以告诉你。
一是对象产生的地方是在有表单填写的流程节点。如用户登录需要创建账号，创建就需要表单，表单的每个字段是一个对象的属性，而属性的组成就是一个对象。
二是对象往往是由一个个实体组成的，比如说我在公众号里发表了一篇文章，我、公众号以及文章就是3个实体，而这3个实体对应进系统里就是3个业务对象。即对象的来源可以从需求描述的文本中抽取出来。
如手机备忘录中，有两个非常明显的对象，记事本与任务待办。
这两个来源覆盖了流程中所有对象，对象抽取完成之后产品的信息架构也显而易见了。
四、展示架构梳理
展示架构是为绘制原型图做的最后一次准备，通过纵向、横向梳理，你已经清楚用户在每个流程，每个流程节点在做什么事，要给用户展现什么，但是，这些都是抽象、逻辑的。
现在，我们可以忘掉前面的逻辑梳理（因为你已经完全熟悉了这些逻辑），直接从具体应用出发，用树状结构展示出层级的顺序、每个层级包含的元素（元素类别为信息和交互）。这时候，你就只考虑把那些元素放上层，那些放下层，不再考虑还要补充或者删除那些功能和信息，也不再考虑流程是否正确。
当然04这一步骤的使用场景一般是在移动端，PC端往往一个页面就要承载大量信息和交互，且你在设计展示架构的时候相当于也在画原型了，所以如果是PC端产品，到这一步如果前3步认真做了，04只要基本构思下，就可以开始画原型了。
使用纵横深梳法（4个步骤）后，基本一个产品设计不会出现较大的业务错误，同时产品架构在你脑中肯定是非常清晰的，更助于你站在更高维度去思考业务。
当然，我整篇文章其实是分享一种”术“，而并没有达到”道“的层面，所以在具体实操的过程中，很多底层逻辑还是要依靠你作为产品经理的产品感，而产品感是你无数次思考好的产品，践行多次产品的设计之后才能得到和提升的，所以产品经理，真的没有捷径。
以上。
作者：二会，在产品经理中长得帅那种，公号：产品汪看世界（chanpinwang）。
