项目实战：设计师如何更有效拿到结果?

03.提案确认、评估阶段——意愿驱动，结果导向

　　好，现在我们手中有了一个上述的“好的设计”方案了。接下来的主要任务就是让这个方案得到相关人士的认可，这些人包括：

老板，他有生杀予夺的大权，他说好，可以做，那么这个项目的阻力就小很多。
同部门同事，他们会从专业水平来对这个设计进行评审，到底好用不好用，有没有更好的办法——这个时候可能会被信息轰炸掉，要注意鉴别，并非所有的意见都要参考的，毕竟每个人的立场不同，思考问题的角度和深入程度不同。。
需求分析（RA）,前端人员和工程师：他们是要负责实现的，虽然在出最终的方案前已经让需求人员介入进行可行性分析，但是最终方案出了以后，一样要再次进行评估，此时不仅仅是可行性，也要评估具体的工作量，要实现这些设计功能和效果，前端需要多少人日，工程师需要多少人日等。
相关部门同事，如这条产品线的产品经理，毕竟是动了人家的土，也许某种情况下涉及到的产品线不止一方，可能同时需要和几个产品经理进行沟通协调，还有客服部同事，网站一经改动，他们就必须要通知到，不然怎么教客户用啊。所以，在没有正式上线前就应该让他们知道，另外作为一个与客户亲密接触的部门，他们也能够提供一些有用的信息，帮助我们进行改进。

　　记得王石在武大的一场讲座上回答“登雪山难还是管理企业难还是做慈善事业难”的问题时，他的答案是：登雪山最容易，因为只是在和自己与雪山打交道。管理企业次之，涉及到的人很多，做慈善最难，涉及到的人更多。

　　所以，与人打交道和协调本身就是不容易的事情。很多时候，用心力交瘁，劳而无功来形容一点都不为过。但是（对不起，又一个但是），不这么做，又怎么能够拿到结果呢？自己发起和主导的项目，是不能依赖产品经理的，要自己主动出击。

　　缠，磨，黏，死缠烂打——种种招数，会哭的孩子有奶喝，这是老话。

　　出了意愿驱使去争取资源和认可外，当然也要对好的建议进行采纳吸收，踏踏实实进行方案的“妥协”和“调整”。

　　反正最终目的仍是得到认可，多方认可，直到把这个项目排在日程表上。

　　当然，我们还要求设计师是有大局观的，根据自己项目和别的项目对比得出的优先级排日程和资源就好了，不要太过了。。

能力要求：

　　多方沟通与协调能力——还要求“多语言能力”，怎么说呢：

　　与工程师要用工程师的话语沟通，与数据分析人员要用数据平台的语言沟通，与设计同仁们则用设计的语言沟通，与老板们要以产品经理的语言沟通。与copy writer则要用英文沟通，设计师，尤其是新人，要主动地多和同事、别的部门的同学沟通，以掌握其语言特点。

承受挫折，卷土重来的心理素质

　　不可避免会碰很多钉子，可能你的改进虽然整体效果不错，但是可能会触及到某个产品经理的利益，可能影响到他的考核（比如流量的下降）。要说服他讲究大局观而放弃掉这些流量损失，是看似“不可能的任务”。所以在挫折下屡败屡战，绝对是心理素质，当然，也可以曲线救国，争取重要人士的支持。

理性预估项目风险与价值

　　设计师当然是感性的。但是现实是，你纵使拍疼了大腿给你的老板说：这个设计真的很好很好啊，用户一定会多么多么喜欢用的啊……没用的。老板和别的贡献资源的同事们都眼巴巴问你要“证据”，你能拍着胸口承诺说：“我保证用户一定会更喜欢用”。那么，怎么保证？所以感性的设计师也要有预估项目收益的能力，当然，是量化的。比如，数据。改进前后流量的前后对比等。对着空气去预计当然有很大的风险，不过既然不做不行，就逐渐锻炼自己拍脑袋也越拍越准确。刚开始当然从最底线开始预估，最低达到多少，希望的结果是达到多少。不要过于保守——不然大家没兴趣，不要过于冒进——不然自己压力大。如何刚刚挠到痒处，着实还需要考虑考虑学习学习。