初级产品经理总是只会接高级产品经理布置的任务，比如这个需求画个原型图，写个需求文档，但只见树木不见森林，不知道为什么要做这些。
今天我就给大家梳理一下高级产品经理都是如何进行产品设计的，思路是怎么样的。
首先要设计一款产品，就需要明白定方向，即产品战略和解决方案。
产品都要有方向，无方向的产品就如同在大海的帆船没有指南针，无法到达想要去的目的地。定方向包含产品战略和解决方案。产品战略定义了产品近期和远期的轮廓，划定了产品范围。
只有确定了产品的范围、战略和解决方案，才能确定如何设计产品，否则就只是为了设计产品而设计产品，找不到方向和目标。
1. 产品战略
通俗地讲，产品战略是指，明确要进入的市场、要服务的用户和要做的产品是什么。
比如，企业决定要给中小餐厅开发本地餐饮系统，解决餐厅的营销和管理问题。这就是一个产品战略。而产品范围就是做本地餐饮系统，以后的产品设计都要在这个范围内展开。
产品战略的制定要考虑企业当前情况、市场规模、竞争环境等因素。
2. 解决方案
在产品战略确定后，我们就要确定先做什么，后做什么。比如，先做点餐系统，再做预订系统，最后做排队系统。
要想清楚这些内容，一方面要能想到各种方案，如基于线下场景的各种点餐方案。
另一方面要能评估方案的价值，一个方案只有对使用者和开发者都有高价值，才值得开发。
确定了战略和解决方案，接下来是搭框架，包括功能框架和非功能框架。
在定方向完成后，产品经理就要做产品设计。高级产品经理不是一上来就画原型图，而应先搭建框架。该框架包括功能框架和非功能框架，是对这些内容的宏观定义。
产品的框架仿佛是摩天大楼的框架，或是人的骨骼框架，对产品起支撑和限定作用。
1、功能框架
功能框架要对功能做挖掘和限定。比如，企业决定要做线下的排队系统，就要明确该系统所具有的功能。梳理功能框架有两个难点。
首先，产品经理容易遗漏需求。比如，一个外卖平台的预订和排队系统，除了具备常规功能，还要具备给老板用的绩效统计功能，给维护人员用的故障排查功能，这些功能一旦遗漏，产品就是不完整的。
其次，产品经理往往梳理功能无层次。比如，一个外卖平台既具备订单待支付、已支付等功能，又要具备购物车、设置优惠券、查看物流信息等功能。尤其对于复杂系统，无层次地梳理功能，既不利于理清需求，也不利于研发人员理解。
这时需要通过用例的方法，解决上面两个难点，使用该方法就能没有遗漏、有层次地理清产品的功能。
对于“用例”也许很多人会很陌生，但“用户故事”你应该挺熟过。其实，用户故事就是用例的实践，用例可表达用户故事之间的联系。后续我会给大家详细讲解如何利用“用例”来梳理功能。
2. 非功能框架
功能是可以被用户使用的。比如，排队功能和点餐功能，都可以被用户使用，属于功能需求。除了功能需求，还有非功能需求，如安全、可维护、性能需求等。
如果说功能需求是用户使用APP或网站的原因，那非功能需求则是保护和支撑用户使用该APP或网站的基础。
从某种程度来看，非功能需求和功能需求同等重要。因为如果没有安全的保障，用户就不会使用该APP，如果APP访问速度慢，用户就会失去耐心而放弃使用。
很多初级产品经理不会梳理肺功能需求。一个原因是产品经理不懂这方面的知识，只能由研发人员代劳。
另一方面原因是，研发人员也能搞定这些需求。但情况并不总是如此。比如银行做的存取款系统。产品经理既要梳理该业务发生时间、业务类型、并发人数等，从而确定性能需求，也要树立监管部门、安全部门等提出的安全需求。在该场景下，产品经理就要学会这些知识。
最后是做细节，理清业务流程、业务操作、信息结构。
在业务框架搭建完毕后，就要做细节规划。这好比盖一座大楼，要先设计外部框架，再设计内部细节，细节包括房间的空间结构、水电布局等。对一项业务来说，细节包括业务流程、业务操作和信息结构。
大框架强调了功能有什么，而做细节就是要把功能细化，是一个从粗到细的过程。
有的功能比较简单，产品经理就不需要梳理这三类内容。但是如果功能复杂，产品经理就必须先梳理这些内容，这样做的一个原因在于，研发人员要根据这些内容设计系统，而不能只看原型图，另外一个原因是帮助产品经理理顺设计思路，为画原型图打下基础。下面我来介绍一下这三类内容。
1、业务流程
我们从上一期的业务定义了解到，业务都是有流程的。比如，排队的流程是，首先服务员询问顾客是否预订，然后服务员输入就餐人数，服务员打印排队小票，最后呼叫就餐顾客。再如，一个外卖订单，在用户支付完毕后，就需要运营人员确认发货，再到物流人员进行配送，这也是一个流程。面对一项复杂业务，产品经理需要先梳理好流程，再画原型图，这是一个完整的过程。
2、业务操作
我们用流程图梳理业务流程，还要用状态地图梳理业务操作。状态图表述在一项事务的不同状态下，人能做什么操作，该操作会改变事务的状态。比如，一个订单在用户支付完毕后，其状态就变成为已支付；在运营人员确认发货后，订单状态就变为已发货。在该案例中，人的操作就改变了订单的状态。
产品经理使用状态图，可让思考更全面。比如，用户下单了但未支付，谁能取消订单呢？可以是用户，可以是商家，也可以是系统。要做到这些，产品经理只需要看着状态图进行思考就可以。
状态图和流程图既有区别又有联系，我在后面会给大家详细讲解。
3、信息结构
信息结构表述了信息内容之间的关系。比如，一个订单含有该订单的下单时间、购物金额等信息内容。而一个订单可由多个物流运输，就是在表述信息之间的数量关系。
显然，订单支持一个还是多个物流，其前台和后台的原型图是不同的。隐私，信息结构决定了前台的展示、后台的交互。信息结构可用类图来表达。
如果信息结构设计错误，将导致信息冗余和系统无扩展，这也是造成研发人员返工的主要原因。后期会给大家讲解如何梳理信息结构和类图，避免这些问题的发生。
以上就是业务流程、业务操作和信息结构的内容。其中业务流程和业务操作在梳理业务的动态部分，信息结构在梳理业务的静态部分。
只有把上面的都梳理清楚，我们才开始画原型图，而不是一上来就画原型图，只有这样细致的梳理，你才能做好一款产品，也是高级产品经理必须具备的能力。
