收到了用户的需求，但是要怎么开始做的？怎么开始设计呢？或许本文可以给你借鉴的方法，enjoy~
部门最近新入一个产品实习生，完全小白一只，没有任何的设计经验。
放假前一天，她很苦恼地说：“我知道她的问题是什么，但是我不知道怎么开始设计……”
很多人刚开始做产品的时候，可能也会遇到这样的问题。收到了用户的需求，但是要怎么开始做的？怎么开始设计呢？刚开始的切入可能会非常的困扰和艰难。
那么，今天我要分享的是，“当收到客户需求或吐槽以后，怎么开始进行产品优化改造？”
获得新需求开始设计的过程中，需要几个关键步骤：
了解你的系统，熟悉产品所有流程和细节
分析你的产品，看产品当前是哪里有缺陷或需要更改；
设计你的方案，检验用户需求是否得解决。
第一关键步骤：了解你的系统，熟悉产品所有流程和细节
作为产品经理，你应该比所有人更熟悉你的系统。作为一名产品小白，最基本的要求就是快速、全面熟悉你的产品。你得理解产品当前所有的现状，如果有可能，了解到每个功能背后的“故事”。
怎样才能快速熟悉系统？亲手整理系统的每个功能模块，自己亲身体验系统的每个功能特性。把你对系统的理解，整理成为像“功能说明书”。找到团队的相关人员，像他们了解你所疑惑的每个问题的背后故事，这些故事能帮你更全面、深入了解产品现状以及为什么是这样。
怎么评估算熟悉一个系统？当用户提出一个需求，你能马上判断出来是哪个功能模块解决，或者什么样的组合方案解决，那么恭喜你，你已经了解产品的全部。
当然，很多产品小细节可能你会逐渐才发现，但是产品的主体框架、流程、模块/功能需要快速了解。只有对产品有熟悉度，你才能更有效跟用户进行需求沟通。这将会帮你做需求的最初始评估，客户需求当前系统能满足吗？哪里不满足？
带着对系统的理解，你可能开始跟用户进行沟通他遇到的问题或需求。究竟什么是“用户需求？用户痛点” 用户对你描述的就是他想要的吗？
用一个老生常谈的例子，老板对你说，“给我一杯水”，“水”是老板现在的需求吗？
如果这时候不去探究他为什么要这杯水，那么你可能会再遇到以下几种情况：
（1）给了老板一杯热水（内心独白：喝热水好，你觉得老板肯定觉得很暖心）~
结果怎样，老板大发雷霆，给我热水干什么，你想热死我啊… 这时候你才发现，老板大汗淋漓，他可能是太热了~
这时候如果你换为的解决方案是“把老板空调打开，给他一杯凉开水，再备上一杯冰饮” 老板可能会对你刮目相看~
（2）给了老板一杯热茶（内心独白：平时老板都喝茶，他肯定需要喝茶了）~
结果，老板说你猪脑子啊，用热茶我怎么能浇花… 浇花！！！ 你不知道，老板最近迷上绿植，让你给他水，实际上是要给绿植浇水…
这时候，你如果跟老板交流一下养花心得，白天浇水不是最佳时机，晚上浇水对绿植最好，然后告诉老板说，我先接杯水，放半天，晚上给他带过来，还能去除水中的氯气，老板肯定会对你赞不绝口。
这是一个非常经典的案例，老板对你发出的是，是明确的指令，是他给出的一个解决方案。老板为什么要这杯水？他真实背后的需求痛点是什么？这才是我们需要去探索明确的。如果用户实际的痛点不明确，你可能会频繁被对方KO，你做的解决方案可能会被对方改来改去。
用户常常觉得他就知道什么方案是最好的，因此他跟你沟通的时候会直接告诉你他想要的解决方案。因此，在和用户沟通的时候，你会发现对方已经直接帮你做好设计了，他已经跟你说了需要加什么功能，哪里需要改成什么。如果客户对你描述的已经是跟产品功能特性相关的内容，那么他已经在描述自己的解决方案了。
如果遇到上面的客户，你就得多问问他实际要解决什么问题？有一种快速的方法是，追问客户，他为什么要？解决了他什么问题？如果系统按他的提议做了，那么他的工作会有什么变化？
用户的解决方案是从他的认知范围提供出来的，作为产品经理的我们，可能会为他的痛点提出更好更合理的方案建议。因此，了解到客户提出的“需求”的背后更真实的原因，通常能让我们更好提出系统优化方案。
第三步骤：分析你的产品，看产品当前是哪里有缺陷或需要更改
通过第二个步骤，你已经非常明确当前客户的需求痛点，并跟你的团队确认了本期需要解决的关键问题是什么？那么，你需要确定本期改造的目标，也就是系统将改造成什么样来满足用户什么痛点。
通常，你可以用这样的文案结构来描述你的目标：
“本期我们希望通过提供什么的特性，帮助什么样的人，解决什么样的问题”
确定好目标以后，你需要重新分析你的产品。这一次的分析跟第一个环节的分析目标不一样，主要目的是为了了解，系统当前究竟哪些环节、哪些模块有问题影响了用户需求的满足。因此，你需要去重新整理系统，将不满足的环节或功能模块标记出来。
这意味着，为了解决用户本期的需求，我们需要在这些有问题的点上做改造。
第四步骤：设计你的方案，检验用户需求是否得解决
找到了影响点，产品经理最能发挥效用的一个环节出来，你需要开始设计你的解决方案。在原来的环节中。需要怎样改造？
如果是产品的流程有问题，可能你改造的是系统的流程；如果是之前的规则有问题，可能你改造的仅仅是个简单的规则；如果只是原因功能的缺失，可能你设计的就是一个新特性。
根据不同问题的分析结构决定了最终我们的设计方案，因此方案可能有大有小，可能有的方案就是一个线下行为，告诉用户怎么用即可，并不一定体现在我们的系统。
那么，对于我的方案究竟是否OK，怎么来检验呢？这样又回到了我们的第二个分析环节，用户实际痛点。你可以假设自己的产品已经按照自己的设计实现，那么实现以后用户提到的问题解决了吗？如果能够解决，那么恭喜你，你的设计方案最起码从用户的场景出发已经满足了。
当然，一个设计方案是否最终OK，除了用户的需求满足了，还有很多其他的考虑点，比如，技术可行性，时间成本，人力成本，而其他这些影响因素是小白需要在做好方案跟团队相关人员去讨论沟通的。
很多小白可能觉得，如果不多增加一点功能，或者不改点交互，那么我做的是什么呢？在我们部门的小白本期负责的改造中，其实她不需要动任何的流程和步骤，改造的可能仅仅是换一个极其微小的“规则”，这个规则对于界面来说，可能没有任何改变。所以她很心虚，觉得我做了什么呢？就这样ok了吗？实际上，用户需求的解决很可能就是这么小，小到很多人看不到，但这就是一种最简单的方案。
小结
当收到用户需求以后，你需要做的是：
1）反思你理解系统吗？
3）分析系统中有什么不满足的点，或者需要在哪些点上改造才能实现目标；
