文章为作者根据自身经验所做出的总结，希望能够给你带来一定的启发。

大半年的时间，思考了很多，却行动的很少，一直深思，一直徘徊。每一天，每一周，一个月，半年，甚至更久，一直思考，每一天，每一周……从哪里来？到哪里去？路很多、怎么走？成为什么样的人？

好像每天我们都会在心里默默的规划自己人生目标，给自己设定目标，一个月实现什么，半年实现什么，或近或远，有了目标才有行动的动力（宁可选择模糊的正确，也不选择正确的模糊）。

最近一直想写点什么，整理一下自己，回顾一下自己，从UI转型产品的思维历程，就当对自己工作以来的总结。

设计师，哈哈哈我就是设计屌师，从平面设计到UI设计再转型产品设计。

一、UI设计师转行产品经理有一些先天优势

1. 设计师接触的产品会比较多，看得多、抄的多（你懂的），照葫芦画瓢能力强；
2. 设计师普遍沟通表达能力不会太弱（忽悠能力）；
3. 设计师通常会更关注体验和细节，一些文字属于的表达贴切不贴切，字数的多少，换行不换行，按钮总共有几种状态等等，这一方面是很没做过设计的PM所不擅长的。

二、也有一定的劣势

1. 对于开发的逻辑和思维，是比较欠缺的。你以为这样做简单，其实开发这样做一点都不简单，你认为这样做看起来会有一些技术的难度，但是开发两秒钟给你搞定了，这种情况会时常发生；
2. 由于常年注重细节，导致容易跳不出细节，眼光放不长远；
3. 太过自我，不够客观，较难跳出自己的设计思路，重新换个角度看。

三、忘了那些细节，你已经不是UI设计师了

1. 细节决定成败

“一个产品是否能成功，要取决于时代背景、市场、渠道资源、用户体验、技术实力等多个方面的。“

细节决定成败”中所说的“细节”，不再是我们以前所理解的“细节”，它是一个具备了更广泛意义的词。

如果你现在还在盯着一个界面上的按钮，琢磨这个颜色饱和度是不是还能再低点，这个字号是不是太小了，那你注定又做不好产品。

我们应该投入更多的精力在功能的设计上，这才是我们应该关注的细节。比如一个功能是否能跑通，会不会引起连锁反应，不要想完了一个界面，发现后续的一系列功能都会出现逻辑上的漏洞。

打个比方，比如你想修改一下充值缴费的结构。那你要考虑的是，这个修改会不会影响到用户的缴费操作，会不会影响到信息查找，会有什么影响，如果有影响，该怎么处理，如果改动了，用户的余额处理怎么处理，会不会金额不对等等。

再比如，你觉得一个术语表述的不清楚，应该换一个名词。那就要考虑整个系统中究竟有多少个地方涉及到这个词语，如果要这么改，究竟会涉及到多少地方，是不是有很多隐藏操作之后才会出现的提示语也包含了这些词。想全面之后，你要权衡利弊，决定到底应该怎么改。

2. 别把什么都做到极致，你不知道那有没有价值

很多没有快速迭代思想的公司，在做产品的时候，一开始都会处于一种自我感觉屌爆了的意淫状态中，把一个东西想的无比美好，最后做出来发现没人用，傻眼了，然后疯狂地开始做各种匪夷所思的事情，因为前期资源投入太多，没有退路了，只能病急乱投医。

如果你是产品经理，应该尽可能避免这种事情的发生。

这是快速迭代和精益创业里面的一些思路，到底应该如何做，自己要有权衡。

3. 搞明白你要干啥，别再瞎忙活了

做产品也是一样，首先你要领一个任务，这个任务就是在这个时间段内，我们的产品要达到什么样的目的。

确定了任务之后，我们再有选择进行砍怪，砍涨经验值最快的怪，砍你目前级别砍的动的怪，如果同时领了好几个任务，那你就要把砍怪的路线安排好。

你交付一个任务，就相当于你交付了一个可上线的版本。然后你利用交付这个任务时候得到的经验值和金钱（用户数的增加或客单价的提高之类的），购买装备，以便继续完成更高级的任务（发展更多的业务或客户之类的）。

总之，没有人会不领任务直接出去乱砍怪，对吧？

这里再多说一句，我所想表达的领任务，并不是指手里接收的工作任务，而是产品在其生命周期的此时此刻，应该在战略上达到的目标。绝对不是指的领导给你安排了什么工作。

4. 拆分你的设计任务，不要眉毛胡子一把抓

我们应该把工作中遇到的所有事情，按逻辑分清。从想问题的方式，到做事情的方式，都要分。

比如开需求讨论会，讨论主题就要围绕着需求是否可行展开，不要在这时候过于深入地讨论怎么做的问题。

如果已经决定要做了，产品经理就要研究怎么做，不要再回过头来思考是不是应该做；不把思路理清，所有的讨论都会变成没有结论的头脑风暴。

除了开会讨论之外，设计工作也是同理。比如下面这个界面，我要把他改成新版的样子。

那这个设计最少要分成四个层面的事情来独立考虑。

1. 界面布局改进（信息架构、UI或交互设计）；
2. 体验方面的改进（改文字什么的）；
3. 旧功能改进（考虑旧用户、旧数据、旧版本）；
4. 新功能增加。

以上每个层面，当你拿出来把他当做一个独立的设计任务贯穿前后地思考的时候，你都会发现更多的问题。甚至还应该拆分的更细，每一个修改的点都当做一个设计任务来做，总之千万不要眉毛胡子一把抓。

5. 沟通，别自己胡思乱想

前面说了做UI的优势，在于沟通能力较强，短处在于对开发的逻辑理解较浅。而通常程序员的长处在于逻辑缜密，但沟通能力较差，这时候我们应该发挥我们的长处，去弥补他们的短处。

千万不要闷头自己搞，要积极的与开发的同志沟通，时不常的问问，我这么做行不行， 我这么做有没有坑，你有没有什么建议，平时自己主动地多看看各种开源的管理系统。

我相信，只要你有一颗真诚的沟通的心，以及对方不是一个特别资深的程序员，那你应该可以学习到不少的东西。

当我们被拍砖的时候，不要像个怨妇似的咒骂，好好想一想问题产生的原因，分析清楚原因，采取相应的策略。

我一直认为，当在被拍砖的时候（不管是开发拍，还是运营拍，还是老板拍，或者是一起群拍），都是我获得进步的最好时机，也是获取更多真实信息的最好时机。怕就怕没人拍你的砖，人家直接不鸟你，那就真的彻底完蛋了。

我是十分相信所有人都会是积极的心态来面对工作的。但举个极端假设的例子，就假设对方就是一个消极的保守派，他就是懒得干活，就是毫无缘由的拒绝你的合理设计，那你也要考虑，究竟是为什么会造成现在的局面，是因为你没有把产品的理念和愿景传达到位，还是你的态度不好，或者是态度太好了？

想明白后，尝试性地采取相应策略。记住，先从自己身上找问题，先从改变自己开始，不吃亏。

持续对用户、业务和商业模式的深刻洞察，特别从商业层面去梳理业务架构，是产品经理的高阶能力。

愿自己这条路上越走越远。

本文由 @兴平 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。