产品经理总是面临产品设计的问题。产品设计可能没有标准流程，每个产品经理都有自己的经验。笔者根据多年经验总结出七个步骤，在此与大家分享。
这是昨天一个同学在知识星球问我的问题。是关于产品设计的流程和SOP。
说实话，回答这样的问题还是挺有压力的，因为关于制作产品的SOP，实际上并没有行业标准。可能每个公司都有自己的一套流程，甚至同一个公司不同的团队都有自己的流程，所以不能称之为标准化。
话说回来，只要你能交付有价值的产品，过程都是次要的。黑猫白猫，会抓老鼠就是好猫。
然后我的猫会喵喵叫我的产品制作过程，可能不对；但绝对是我练过的，供你参考。
一共7步，基于昨天在星球的回答，再说一遍。
一、业务分析-做什么
几乎每个产品都对应一个或多个业务流程，业务流程是业务事件的一种表达，是不同角色之间的信息流和交互方式，对应的可交付成果是业务流程图。
例如，电子商务业务包括订单生产流程图、货物仓储流程图和资金流程图。外卖业务包括接单业务流程图、派单业务流程图、订单流转流程图等。
做一个产品，第一步是把业务分析清楚，搞清楚要做什么，涉及哪些角色，业务交互节点是什么，信息流、资金流、物流是怎么流的。
想通了这一点，就可以画出不同业务模块的流程图，这样会让整体情况更加清晰。此外，我们的产品定位和产品路线图也包含在此链接中。
二、产品分析——解决什么用户问题？
完成业务分析，设计业务流程后，就可以进入产品分析了。这一部分的主要目的是阐明要解决哪些用户问题。
具体包括目标用户、人群画像、需求定义、用户体验图设计等。主要是从用户和产品的角度出发，通过一些工具形象地表达产品要解决的问题。
比如具体的用户画像构建，需求分类，结合业务流程绘制用户情感体验图。
然后在这一步，需要定义MVP和产品的关键路径，形成需求和功能的列表，并进行优先级排序。
另外，我们常说的竞争产品分析和用户调研也是在这一步完成，并交付相应的调研分析报告。
这一步的核心是围绕“解决用户有什么问题”展开工作。
三、结构设计——构建产品骨架
第三步更具体，就是我们常说的设计信息架构和功能结构。可交付成果是树形结构的思维导图，每个人都应该看过，做过。
但需要区分的是，信息架构和功能结构不是一回事。前者是描述产品的信息骨架。比如一个网站的结构包括哪些部分，每个部分包括哪些字段信息。这一步最好有技术生参与。
后者从操作的角度描述了具体的功能结构。例如，帐户系统包括注册和登录功能。
为什么需要这两张图？
信息架构帮助我们在全球范围内理解产品的信息脉络，尤其是对于一些复杂的项目，更有利于模块化集成和分类。
功能结构也能清楚的告诉我们现在的产品有哪些具体的大功能和子功能。它们中的一些可以被提取出来，并与类似的项目相结合，因此可以在技术层面上进行模块化和集成。
目前为止，我们不会进入具体的原型绘制阶段。
虽然以上三个步骤很重要，但实际上很多人和团队都忽略了。出现的问题是产品的混乱。新人来了之后，对产品没有全景，也不知道从何下手。
说到历史功能的调整，不太清楚之前的架构和模块划分是怎么设计的，全身而动。这就像一座桥需要拔掉一颗螺丝钉，但是你不知道拔掉之后整个桥会不会塌。
四。原型设计-如何使用产品
这一步大家都比较熟悉，我就不说用工具画原型，做交互设计了。
特别是在小公司，功能设计和交互设计多由产品经理完成，而在大公司，可能会有专门的交互设计团队。
比如我之前在JD.COM的时候，具体的交互设计是由专门的UED团队来做的，产品经理更注重需求定义和流程设计。
动词 （verb的缩写）视觉设计-产品看起来像什么？
视觉设计属于设计师的工作范畴，产品经理不能过多干预。我一直主张专业的事情应该由专业的人来做。
产品经理在这一步要做什么？主要是向设计师描述产品的使用场景和用户特征，即产品在什么情况下被什么特征的用户使用。
在这方面，设计者可以采用不同的布局设计和配色方案。
比如中老年产品，按钮大小和字体颜色可能需要更醒目。如果设计师不了解大背景和产品用户，可能会自己玩，导致产品可用性低。
当然，这里的低可用性是指在目标用户中的可用性不高，但产品本身是可用的。
不及物动词数据设计-验证什么
我们可以说大部分产品都是基于事先的假设设计的，也就是说我们很难提前知道实际情况，所以需要通过数据区验证。
数据设计主要是根据第三步和第四步的结果定义具体的验证项目，并在产品功能上设计相应的数据嵌入点、数据恢复和统计机制。
比如在电商产品的商品详情页，如果用户更想“直接购买”或者“加入购物车”，那么这两个按钮上会埋下数据，然后统计一段时间内这两个渠道产生的订单转化率。
现在已经进入精细化运营时代，相应的，产品也进入了精细化设计阶段。用科学的方式验证需求，用数据证明设计，已经成为产品经理的必备技能之一。
七。假设验证-真相是什么？
最后一步是根据数据结果进行回顾和调整。只有假设不行，只有数据不行。最重要的是我们能从数据中得到什么样的洞察。
基于洞察做出相应的产品调整，然后进入新的验证闭环。这部分的内容在我之前的文章《HVO——基于数据驱动的产品设计方法》中有详细描述。
写在最后
以上七个步骤虽然是一个产品设计步骤，但不是标准步骤，更不是SOP。有的公司可能直接从第一步跳到第四步，也有很多公司省略了最后两步。
但无论如何，可能是因为公司的资源和时间有限，无法按照这一步来进行产品工作，但我们的产品经理心里还是要有这个谱的。至少我们知道一个产品的生产过程。
我说的不一定对。我只是把它扔出去和你分享。有点灵感就好了。
如果对产品问题感兴趣，可以一起讨论。
最后一件事，今天我出去见一个朋友。她是运营商，但对产品了解不多。她的话给我留下了深刻的印象。
她说“我知道产品设计没有看起来那么简单，我对产品经理还是挺敬畏的”。
#专栏作家#
《产品经理必须了解的技术》一书作者Juliye Care前产品总监，在创业公司负责很多从0到1的产品，目前在一家电商巨头负责产品工作。
本文由人人作为产品经理原创发布。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
免责声明：本平台仅供信息发布交流之途，请谨慎判断信息真伪。如遇虚假诈骗信息，请立即举报
举报
