初级产品经理或许都有这样的遭遇——由于产品规划与设计时，覆盖得不够全面与严谨，导致产品方案错漏百出。继而陷入了低落与沮丧，不知道从何入手做出改进。而笔者就针对这一现象，总结出了六点产品设计心得，希望对你有所帮助。
对于一个刚入门的后台产品经理进行产品设计或者写PRD的时候，经常会出现覆盖不够全面，逻辑前后不一致等问题。
导致在需求评审时成为了众矢之的——大家不断发现你的疏漏，在现场对你提出问题，而你又没有办法立刻给出解决方案，极度尴尬甚至上升到非工作因素互怼局面。
或者刚上线的功能就出现线上事故，最终复盘下来发现是设计缺陷。
几次之后，可能对产品的心理打击非常大，不仅仅是大家甚至自己都开始怀疑自己是否还适合继续这份工作。
那么产品经理就要在产品设计的时候做到全面和严谨，在达到惊艳或者巧妙之前，先让产品方案可落地。今天总结下自己在产品方案设计的时候的一些心得。
一、主要流程与上下游逻辑贯通
为了保证方案的可行性，需要按照主要流程进行拆分，保证流程可以严谨地串联起来。
以消息推送举例，从发送、下发、到达、点击等核心流程，要能够完整地串联起来，通过业务触发系统触发消息（包含业务ID与业务信息），流转至消息发送平台（包含消息流水号与业务ID），下发至通道（消息流水号与通道信息），并且通过连接或客户端进行消息上报（消息流水号和点击信息）。
这样，就完成了消息的下发与转化流程，并且通过了消息平台的消息唯一流水号可以全链路关联上起各个环节。
一般来说，系统间的对接都是由产品经理来对接，因此这些信息也有必要同步明确给研发。这样自己对于系统也有了更深入的了解，研发对产品的好感也会比直接丢给研发一个接口定义文档好很多。
对于上下游有很好的串联，也可开拓自己的视野，更好地了解项目或者功能的全貌，摆脱大公司里螺丝钉的窘境。
对于复杂的系统或项目，需要从整体的流程开始设计，逐步细化拆分，以保证流程的通畅。如果在细节设计时发现无法实现或实现方案对整体流程有影响，需要及时反馈，调整整体方案后再次落实。
二、异常情况或缺省值的处理
正常的逻辑按照业务流程可以一步一步递推出来，符合人们思考逻辑。
但是其实很多线上的问题都是由于异常情况考虑的缺失，而且后果轻则用户体验较差，重则导致产生的线上事故。异常情况的校验，更是考验产品经理的严谨，
比如系统的门户设计有数据、公告、待办审批等模块，但是大部分用户是没有审核权限的，那么这个模块的该怎么处理？是隐藏还是显示一个“当前暂无审批待办”的文案提示？
比较严重的是线上发布的营销活动被黑产疯狂“薅羊毛”，粗心的会按照自己的设想一步一步引导用户完成业务转化，然后给予用户奖励，并一心期待效果来完成KPI，但忽略了黑产利用了中间各个环节的漏洞绕过了你的业务门槛，直接领取了你的奖励。
当然，异常情况是穷举不完的，受物理环境、网络情况、用户行为等等许多因素影响，一切的异常情况都要基于用户当时的场景来思考
三、数据概念
做产品经理要对数据有敏感性，对于线上数据结果的解读来分析挖掘离不开数据的采集。因此，在产品设计时数据的需求也要同时明确，这也往往是后台或者功能性产品缺失的能力。
1. 数据的流转
要明确出来数据是从上游哪个系统过来，是通过什么方式传递，会涉及哪些字段，如果有特殊逻辑，是需要取哪些枚举值，对应什么处理。
对于自己系统产生的数据，是否需要留存记录？是否需要同步至下游系统或者公司的数据集市。
2. 数据的时效与更新方式
对于数据来说，要明确下数据的时效，是实时更新还是离线更新，是更新记录还是新增记录，保留变更记录。提前说明数据需求，避免上线后出现看不到实时数据和历史记录的尴尬局面，但是也不是必须所有场景都需要实时数据，也要从实际需求和大批量数据实时计算的成本中平衡。
3. 数据的量级
数据量级要从业务的角度给一个预估值，以便研发在开发考虑系统的性能问题，是否有高并发的场景，避免出现对业务流量的预估不足导致出现线上服务不可用的情况。
4. 数据的统计与分析
哪些指标是可以来反应效果或监控异常的，口径定义是什么？在哪里展示？是否需要添加报警机制？这些统计分析问题需要产品经理额外关注，这样才能知道自己的系统运行情况怎么样、线上的业务发展的如何。
四、一致性
一致性是指在涉及较为复杂的系统或业务逻辑时，多个环节、多个功能之间在交互文案或产品逻辑是否保持一致。比如，推送的“点击率”与“打开率”，本身是一个含义，但是在不同的页面展示的文案不一致，可能让用户或研发觉得这是2个不同的指标，产生歧义，需要支付额外的答疑成本。
更严重的是产品流程不一致，比如活动定向发布流程，一个入口先选择人群——配置活动信息——配置权益预算；另一个入口先配置权益预算——配置活动信息——选择人群。
两个流程是有差异的，需要结合内部运营流程确定，避免出现多个入口流程不一致，导致运营的混乱。
五、牢记需求使命
在产品设计过程中，一定要牢记需求的使命，我们这么做到底是为了什么？
如果通过论证发现没有办法实现你的需求目的，或者是发现有更好的方案可以实现这个目的，那么就需要重新考虑方案，快速协调各个相关方进行讨论确认，得到优化方案，避免出现为了做而做。
还有一种情况就是避免过于陷入细节或沉迷于自认为非常巧妙的方案导致自己偏离了这个需求的初衷，付出了很高的成本也没有很好地达到预期目标。
六、明确差异与变化
这条原则主要适用于已经有一定基础功能需要优化或拓展的需求，一定要明确差异与变化，强调下改动点和改动的原因与目的。如果你的系统的各种处理逻辑已经非常复杂，那么明确地区分出来改动点，可以降低研发同学的抗拒，也可以测试效率与提高交付的效果。
还有一种情况就是，对于一个现有系统来说已经有了一些逻辑和流程，如果不明确出来的话，大家可能还会按照原来的逻辑开发，导致无法衔接或者交付的内容并不是实际的需求。
当你逐步按照以上的原则来进行产品设计的时候，你就会发现你需要去提前想到很多情况，很多信息，这样就降低了信息不明确带来的后期交付质量差的风险。
同时，可以更好地为研发提供确定的信息，研发侧对产品的好感也会提升，那么合作起来也会更加顺畅。
更重要的是，当你正在做到如此严谨的时候，你会发现产品的每一个细节、每一处逻辑你都了如指掌，会有产品和人融合的感觉，这个时候你也可以更好地做宏观产品规划。
