咳咳，做一个产品首先要说的是需求。呃呃呃，需求太抽象了，不太像人话，还是说点人话吧，做一个产品或者功能的前提是回答一个问题“为了谁解决什么问题，解决到什么程度，花多少资源，达到什么效果？”

好吧，然而今天并不想说这个问题，毕竟因为这个问题一直被boss骂个无数遍，完全没脸说。今天只想说说产品经理的基本功——产品的设计逻辑。

To B的产品最重要的是逻辑思维。想清楚整套业务流程的底层支持才是正经事。不得其法的状态就像理毛线一样，越理越乱，然后理到最后你就不知道你到底在整理一些什么东西了。因此需要一套整体的思维框架去帮助我们来更好的整理自己的思路，整理产品的框架。

罗列目标——>罗列所需功能模块——>罗列信息架构——>罗列页面架构——>整理出原型——>流程图&状态图——>需求文档

罗列目标

虽然并不想说目标，但是目标却是个不得不提的东西。毕竟没有目标，做的事情就没有方向和意义了。我想菜鸟很容易对此认识不清就直接进入所谓的产品设计流程。好吧，说的就是我这种菜鸟，一直自认为是一个目标导向的人，但是等到真的天天被骂的时候才突然之间意识到，原来对于目标的定义实在太不靠谱了。

“为了谁，解决什么问题，解决到什么程度，花多少资源，达到什么效果？”

这并不是一个容易回答的问题，不像给自己个人定目标，我100天要写一百篇文章，实在是太简单了。现在想想低level的自己曾经连给自己定个如果简单的目标都要纠结老半天，瞬间觉得惭愧。

为了回答这个问题，你得知道“谁”，那样就得多多多多多再多的和用户接触接触再接触。你要知道“解决什么问题”，那就得知道问题是什么，为什么会有这个问题，先回答5个why再说吧。“解决到什么程度”快速迭代的方式需要最小可视化产品展示给用户，那就得知道做到什么程度能够解决用户最痛的点。“达到什么效果”然后，需要制定一个大概指标用以衡量自己是否达到要求。这个也就成了可以量化的指标了。

然而知道这些也并没有什么卵用，毕竟回答这些点是需要靠时间和方法积累的，明显目前段位不够。多半的回答还是来源于同事和boss提供。

罗列所需功能模块

当有了一个目标，下一步要做的是便是解决问题的方案的问题，对于能够通过平台解决的，自然就是通过一定的产品功能来解决啦。至于线下流程的制定就先不讨论了。

和开发讨论好需要实现哪些功能可以达到目的，然后把它列出来，一个个的审核有没有更好的替代办法。如果实在想不出来了可以和同事一起讨论一下，以确保该解决方案是最靠谱的方案。

罗列信息架构

根据所需要做的功能，收集需要的信息，更多的是关于某个特定的对象的所有属性，罗列这个信息的价值在于思维的全面性。如果没有这个信息的架构，我们很容易遗漏关键的信息，而设计页面的时候更加容易丢三落四。

当然最佳的状态是不仅能够知道对象的属性是什么，而是同时能够知道这些属性存在的价值是什么，为什么要这些属性。思考清楚这些东西能够让自己对产品的认知度加深很多。

罗列页面架构

页面架构有点像是在搭产品的骨架了，或者说是一种导航的设计，页面的亲子关系是怎样的，页面与页面之间的流转是怎么样的，进入流程和出去流程又是怎么样的，知道这些我们就能够对自己的产品有一个非常成体系的认识，思考产品的时候便更多地是全局性的，而非局部性的。

这个节点的意义有点像是地图，每次你思考的时候会从根节点出发，如果不做这个，便很容易造成死门，缺这少那的。

整理出原型

原型图是最直接的展现方式，有了页面的架构，我们已经可以知道总共需要画几个原型文档。这样便更加直观，对于细化自己的思维来说是个不可或缺的东西。当然这个还有一个重要的点是原型能够更好的把你想要的东西展示给开发和设计。

整理原型需要注意的是不断的去验证方式、功能、方案的合理性，对象属性的合理性，以及交互体验的可用性。

流程图&状态图

流程图是帮助我们理清楚产品功能细节的重要工具，而状态图则可以帮助我们形成产品功能的流转闭环。流程图是逻辑思维的高度体现，如果没有一个良好的逻辑支持，很容易遗漏各种特殊情况，而导致出现异样页面。而状态图则可以确保功能流程的健全性，更加直观的展示出所有状态变化的触发点，从而保证不会进入一种状态死门（进去了便出不来的情况）。

需求文档

文档是产品形态交互的进一步细化，主要的作用还是用来把自己的想法告知自己的小伙伴啦！

所以到最后，扯了这么多，发现这些点在《用户体验要素》里面都可以找到，以前总是看不懂，不明白为什么那么多人推荐这么书，自己踩过一些坑，终于看到了更多的关键点。

以前level太低，看《用户体验要素》只看到了部分叶子，便觉得这本书并没有什么用。现在level比以前高了一些，终于可以看到一个树干了，然而也知道了看到树干并没有什么卵用。或者等到level再高一些，能够看到根。或者再再高一些，能够看到一颗种子。

别给自己做能力限制！