3.1 更前置的开展设计工作

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

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

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

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

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

3.2 主动发起和跟进

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

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

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

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

2）增加大家的参与感 ：就是在正式的评审环节前，让各自利益相关的人看一看，听听他们的想法和建议。

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

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

3.3 管理产品经理

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

所以转变观念很重要。

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

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

来源： CocoaChina