• 

那么在现实中我是怎么用这个思想去指导设计决策呢？

比如作为交互设计师，我可能会接到需求是要 “设计一个App的导航方式”。我会先把各种可能应用到的导航方式全部列出来，并且分析他们各自的优点和缺点。然后我判断的依据是：它的优点是解决核心目标最佳的方案，而它的缺点又是可以被容忍的，这就是最合适的方案。

如果我要设计的是一个像新闻一样的沉浸阅读App，就会倾向选择抽屉式导航。而如果是强调不同模块的互动，强调用户去参与更多功能的，就会选择普通的底部tab形式。

 

给大家举一个例子，有一次我去找领导讨论，想确定一个导航方式的时候：我想很多设计师也会这样吧，发现自己在和外部讨论的时候总是很容易被说服，或者发现最终讨论的结果不是一回事，自己又在不停的改一些无关紧要的东西，方案为什么不能很快被完结呢？其实就是因为在后续的推进和沟通中没有保持目标的导向性。

我的经验是，先聚焦在如何推进和解决最关键的部分上，暂时忽略分支和细节。比如在对一些设计稿的时候领导和其他人总会针对一些小地方提出自己的建 议，我都会拉回来说咱们这次主要是定xxx，其他地方后续我们可以慢慢修改。这样就相当于把自己的工作分了步骤，不至于绕一大圈而丢失很多效率。

 

我一直有一种观点，就是认为如果没有被最终实现的设计不能算作真正的设计作品。因为从本质上来说它没有带来任何价值，也没有解决任何用户的问题，只 是流于形式和艺术。所以要做到这将设计落实下去，设计师就应该不断地思考如何把提升自己的推动力，这些不仅仅考验的是出图的能力，对设计师的沟通力和把控 力也有了很高的要求。

我认为首先要做到我之前说的两点（也就是了解信息和明确目标），另外还可以分享一些提升推进力的具体流程和方法：

 

场景A：PM来找到设计师说 ：“小U，老大说这个地方体验不好，咱们改一下吧，后天要发版所以你明天给我方案好了。”

场景B：设计师找到PM同学说 ：“小P，最近我们的用研发现A流程的体验还有问题啊，我们想了一些解决方案并且有一个不错的，所以你看看什么时候能够协调出开发资源呢？ ”

大家觉得，哪一个场景更好？

我们认为要做到场景B，就得有一套前置开展设计的流程和方法。我们团队的设计师在看待设计工作的时候并不是看成一个点，而是看成一个面，一套体系。 比如说我们会维护一个用户体验地图，将产品的使用流程分解，去标注每个节点都有什么做的好的地方和差的地方，这样就可以直观的反应出哪里的体验还有改进的 余地。加上之前我们对信息的收集和目标的确定，设计师在产品经理提出具体的要求前，就已经可以大概知道哪些地方需要改进和提升了。

接下来的我们会把问题池中的重要问题提炼出来，然后去规划它的解决方案。比如UX内部自己开展一些用研计划、概念稿、可用性测试，直到我们认为出现 了一个不错的可解决的方案。接下来就是在合适的时间去推动整个产品团队实现这个方案，比如在技术成熟，资源有富余，或者领导正好关心这一块的时候适时的提 出来。而暂时还没有推进的方案我们则会保留下来，这样下次有人再提出来的时候我们不但已经非常了解了，而且可以很快解决问题。

 

之前讲项目计划的时候也提到，很多设计师都只关心自己这一块的工作，而没有去Push大家的习惯，比如图已经做好了一封邮件丢出去就不管了，反正等结果就好了。但是实际上我就遇到过很多坑，比如丢出去图产品经理没有反馈，等到好几天后又突然反馈说不行再改改，但是离完结时间也没多久了。或者又一次其他人选了一个站在设计角度不是最优的方案，我当时也因为懒也就没有再去争了，但是最后被老大看到还是痛批了一顿老老实实改。

所以说到底设计师根本是为了自己的设计结果和效果负责的，而不仅仅为了完成当下的任务，设计师还得自己去发起和跟进自己的设计。

 

完成了方案就及时的找相关的人讨论，而且要发起会议，不是简单地丢一封邮件给对应的产品经理，这些人可能包括领导，开发，测试等。

为什么要这样呢？因为点对点的沟通没有面对面的沟通效率来的高，大家可以集中把意见都提出来，省下一个环节一个环节的麻烦。

 

就是在正式的评审环节前，让各自利益相关的人看一看，听听他们的想法和建议。

大家有没有这样的经历？开发如果觉得这个设计方案不好实现，往往不会说开发难实现，而是会说这个设计不好看或者体验差。这因为在公开场合示弱往往是很不好意思的事情，所以提前去了解一下大家的想法和建议，这样才可以平衡各方的利益，免得被一次拍死。而且如果你私下采纳过大家的想法，对于其他人就有种 “自己也参与了这个设计，这也是我的方案” 的感觉，是可以潜在的获得更多支持的。

 

很多人会把跟进实现的工作丢给产品经理或者项目经理，但是其实他们是不懂设计的，也没有像素眼，很多细节点理解不到位。所以设计师自己去盯去看还是很重要的，用户在用得不爽的时候只会骂设计师，才不会记得你的设计稿呢。另外在猎豹招聘设计师的时候，能有实现的产品我们都只看实现的效果，如果对方说是实现不好，我们都会反问 “那为什么你没有把控好实现的效果？”

 

这一点听起来很奇怪吧？明明是PM管理我们吧？尤其是在猎豹移动和360这样产品经理强势到类似领导的公司，或者很多小团队中没有独立的UX部门， 设计师本身就依附在产品经理下面。但是我想说其实产品经理只是设计师顺利工作的一个因素罢了，以正确的方式面对产品经理的需求，并且适当的提出质疑和建 议，获得他们的信任。在某些程度上，还可以利用产品经理对整体需求和资源的把控优势来推进很多事情。

所以转变观念很重要。

 

最后说了这么多，其实核心的观点就是：了解信息 – 明确目标 – 推进设计，如果要再深入展开的话会还能有很多的内容和案例可以讲。但是大家一定有一个疑问：我平时都忙的要死，哪还有时间和精力去做这么多事情？

其实我认为大部分人，真正有效的工作时间都只有40%，而浪费在争吵、等待、理解错误和反复修改的时间上确是大部分。所以与其浪费时间做错误的事情，还不如多多思考该怎样改进自己的工作方法，怎样养成一些好的习惯。