但是听多了之后发现设计师的烦恼还是挺有规律的，无非就是这三大类：

1，太着急：经常早上提的需求下午就要，没有时间认真打磨和研究，更别提什么创新了。总是被需求方催着，只能草草了事，自己都不忍心看。

2，修改太多了：感觉对方也不知道要什么，怎么做都要被修改，大家都很纠结。

3，被指点江山：尤其是被不懂设计的人指点江山，经常提一些很主观和细节的要求，感觉还不如让他们自己做得了。

但是认真感受这些烦恼之后，发现一个更严重的问题就是：大部分设计师都没有设计的主动权。图是设计师在做，但是设计的过程和结果却不是设计师自己能够掌控的。

于是我就在想为什么会造成这样的问题，当然原因有很多，可是有一个很根本的原因就是在现在的互联网设计流程中，设计师本身就是处于整个流程的下游。

图

大家可以看到上图是我们常见的设计流程，需求方或用户提出需求，产品经理整理需求，最后才反馈给设计师开始设计。这看似司空见惯，但是却会造成一些问题：

1，信息滞后：大部分需求设计师都是最后一个知道的，也许在知道之前，产品经理和领导就已经讨论完了，甚至有了基本的设计解决方案。设计在最后才介入，只能做一些执行的工作。

2，目标不清：因为设计师无法了解原始的场景，当时用户的问题和需求点都没有自己感受到，只是别人传达的。那么可能会被传达少一些，或者加入很多主观的想法歪曲了一些，这样设计师所了解到的设计目标可能根本就不是一开始想要的。

3，进度失控：大部分情况下项目周期可能都是领导和产品经理订好了，什么时候立项、什么时候测试什么时候上线。等到某一天突然找设计师要图的时候，天啊~完全没有准备好!

尤其是像我们猎豹移动是一家产品经理为主导的公司，产品经理有很大的影响力和信息的垄断性，表现到烦恼上就是- 大家觉得产品经理太强势了!但是后来我仔细想想其实这也不算什么问题，百度也是工程师文化，阿里也是运营文化，估计除了苹果以外设计师在哪里都得面对这样的现实。

如何解决这些烦恼?

在聊如何解决的时候，我想说一下假如这些烦恼都已经解决了，假如有一种符合设计师的理想模式，那会是怎样的?

1，设计师由接任务变为推动设计：传统的情况我认为设计师都在接任务，接受别人的任务并且完成，这样不断的反复。但是在理想模式下设计师可以推动自己认为美好和正确地事情去变为现实;

2，设计师自己掌控自己的时间：尤其是设计师可以为自己留出认真思考和创新的时间，而不是始终疲于奔命;

3，方案的通过率高：指的是我们只需要出那么一两稿，就可以基本确定大方向，不用一直绕圈子;

而在这种模式下，我觉得设计师已经不再是流程的下游了，而是某些意义上来说，设计师在领导整个团队推进产品设计的提升，这就是设计师掌握了主动权。

---

大家可能会觉得这种梦寐以求状态实在太理想了，也可能会问到底应该怎么做才能掌控主动权呢?其实我也没有完全做到这种状态，但是我们团队始终在以这个目标不断的尝试和改进自己的工作方法，在很多情况下都已经产生了不错的效果，所以想分享一下我们的经验：

1，设计师要做到知己知彼，掌握全面的信息

我曾经做过浏览器的交互设计，我经常接到的需求一般会类似于“做一个加载网页的进度条”，要是平常可能大家就这么去认真的研究这个进度条了。但是我们会首先放在整个产品架构上去看这个需求，进度条是属于网页速度体验的一个环境，那么和安全、浏览器性能上有什么关联呢?又或者在表现形式上，加载的进度条和下载的进度条有什么区别呢?

所以我们的设计师会维护一个产品的用户体验架构，看问题并不是只看一个点，而是看一个面，并且看到他们之间的联系。这样可以提升我们的反应能力和设计的精准性，而要做到它就必须建立在有非常充分信息的基础上。

1.1 我认为设计师要掌握的信息有三类，第一个是要了解产品的战略方向。

具体表现就是产品的商业目标：为什么要做这个产品?;以及产品的策略：通过什么方式来实现这个目标?

刚加入金山调入浏览器部门的时候，上班第一天我就问领导一个问题“为什么要做猎豹浏览器”，当时领导一副诧异的表情类似“你一个美工干嘛要问这个?”。后来经过长聊之后我们才沟通清楚，作为设计师，之后的每一项方案、每一个研究和思考的方向、每一次设计决策，都是为了帮助实现你的产品目标。所以如果能沟通清楚让大家都清晰才能够更好的协作和执行，甚至让设计师发挥自己的主动性来达成目标。

给大家举个例子，一年之后我们进入海外市场，当时海外的浏览器市场还没有饱和，移动浏览器的技术瓶颈也还没有到。所以我们决定做一款“最快的手机浏览器”，依靠简单极致的速度去赢得用户的口碑。

但是可能很多人就问，“快”不是性能和开发的问题吗?和设计有什么关系?其实快不仅是性能，视觉上的简洁轻巧，交互上的化繁为简，都是用户能真切感受到的“快”。

所以当时我们做的第一件事情就是把主题改成白色了。猎豹的品牌色一直是黑色和橙色，非常重的质感，老板很喜欢。所以我们这个改动不是一般的难，一来它触犯了品牌一致性的大忌，二来非常难说服老板上个年代的审美观。但是因为强烈的目标感，大家最终还是推进下来了这件事情。

然后设计师因为对目标的了解也发挥了很大的主动创新能力，比如在简单App启动过程中，我们为了让App的启动感觉更快，做了很多细节上的修改。

传统上的App启动分为上图这几个步骤，程序启动是一定要等几秒的，一般产品会选择做一个品牌宣传的页面，比如UC这样。但是我们当时选择一张图片，让模拟加载出一般的“框架效果”，这样用户就会以为我们是一个逐渐加载的过程。

图

当然这也不是我们原创，只是我们为了快的目标，而最终选择了这个方向。

另外一个步骤就是首页的内容展现也会有一个加载，虽然很短但是如果不作处理的话就会显示一个loading也不是很好。于是我们又用了一张图片，是用户上次退出的时候主屏的截图来替代loading的小菊花，这样过渡效果就柔和很多。

图

另外还有一个小细节，同样的截图，我们颜色确是不一样的(下图文本框)，这样一深一浅是模拟加载的时候内容渐隐展现出来的感觉。

图

所以就是这样几张简单的图，我们在感官上给了用户顺畅和快速启动感受。所以其实在实际工作中，产品的方向深刻的影响了设计师的每一个判断和思考，同样也影响了设计师的效率和成败。有的时候我们只觉得管好眼前的事情或者分内的事情，殊不知反而会带来更多的迷茫、争执和不理解。

1.2 了解用户反馈和数据

在传统的流程下设计师大部分情况可能都不会直接接触到数据和用户反馈，而是经过运营或产品经理整理，或者好一点的公司还能有用研给一个结论。更有的同学觉得，数据和用户反馈不就是产品经理和运营用到的吗?设计主要还是靠美感和品位。

但是更多时候设计是解决问题的，问题的来源往往就来自于数据和用户反馈。可是数据和反馈并不能直接给出设计师想要的目标，它们仅仅是素材，运营同学可以从中看出如何改善运营活动，产品同学可以从中挖掘需求，所以设计同学也应该自己去研究和消化数据和用户反馈来改进自己的设计。

我们团队的流程通常是这样的，有一位专门的同学每天收集来自各个渠道的用户反馈然后发给团队所有成员，如果大家有兴趣的话，可以挖掘用户的原文并且找到用户的联系方式继续深聊。如果数量多或者比较严重，则会在讨论会上各个角色都提出自己的专业建议，并且讨论项目排期和改进计划。

数据也是一个道理，数据的涨跌会因为很多复杂的原因造成，各个角色也会参与和跟进到数据的变化的分析中。有的时候我们的设计师会做出很多种设计样式小量测试，然后看数据的变化来得出最佳的设计方案。

所以这两样东西设计师不光是简单地看：反馈的原始场景是什么?反馈的是什么样的用户?能否深挖这个反馈，和用户联系?

也不仅仅是看而已：收集并且观察，重要的还得跟进细节;长期保留作为以后设计决策的依据;长期观察，提升自己对用户和数据的理解;

---

1.3 了解项目计划

设计师对项目计划有很强的被动感，很多时候觉得反正你们定好我按照安排做就行了，不知道也不想知道别人都在干什么，但是这样往往最终都给自己带来了麻烦。

有一次周五下午一个产品经理找我说有一个很急的需求，希望我周一的时候能给出方案。当时我就懵了，这不是要我周末加班吗?说好的和妹子看电影什么的。于是我反问他项目计划，为什么周一要方案。原来周一的时候产品经理例会，他要给产品总监汇报这个需求但是没有原型无从说起。经过了解后我们达成一致，我先给他一个粗略的方案，能够表现出大概的交互方向，然后等之后在确认了我再补充上各种细节和分支，这样即满足他也不会耽搁我很久。

所以设计师如果对项目计划的各个节点都充分了解不但可以避免误会和争吵，还能提前准备和思考，把控自己的工作节奏。比如：

什么时候可以定设计方向?(提前做好充足的准备，探索风格)

什么时候开发要介入?(需要给出基本框架和布局)

什么时候开发会细调界面?(需要给出细节和标注了)

什么时候测试和上线?(要和开发一起调试实现效果)

上线之后效果的反馈周期?(帮助自己验证和改进设计)

但是在了解和思考项目计划的时候有一点需要注意的是，设计师的考量标准是目标和结果而不是项目计划中对方的要求。经常有的项目计划太紧张让我喘不过气来，但是却想要很高的结果。比如产品经理说希望改进界面大幅度提高用户口碑，但是却只给我半周的时间，如果我客观分析了不行，我就会直接告诉他说半周我能完成一个新的设计方案，但是绝对做不到想要的这个结果的。这是能力问题，要不你换个大价钱找个能做到的，这次逼我也没有用啊。

---

2，设计师要明确设计目标

2.1 思考设计目标是什么呢?我到底做这个设计方案是为了解决什么事情?

首先“解决方案” 绝对不是目标，我们大部分时候接收到的其实都是解决方案而不是目标。比如产品经理有的时候说：“你要新加一个按钮，或者新加一个红色的按钮”。但是新加按钮其实是为了为某个功能做一个入口，入口一定要是按钮吗?是不是banner，卡通图形也可以?而要做红色的按钮也许是为了强调这个入口，那么强调的方式也可以有很多种，除了颜色以外，布局位置，周围的留白，阴影和质感都可以起到强调作用。

所以有的时候设计师听到需求方这么具象的要求都很生气，心里想着“哇靠明明和我们风格不符没办法这样做好吗?要不你来做“，但是实际上都是因为互相都没有深刻去挖掘目标。这样的例子还有很多：

1，设计一个注册流程= 满足用户收藏的欲望= 真的需要注册吗?

2，增加几张启动欢迎页面= 告诉用户版本新功能= 放在场景中引导是否更有效?

3，将banner做大一些= 提升30%的转化率= 内容是否也有改进余地?

2.2 为谁而设计?

我们做UE行业的人有一个单纯而美好的错误，就是认为我们都是为用户而设计的。但是现实很残酷，除了用户，我们还要考虑为公司的商业利益而设计，甚至是为领导而设计。在做设计的时候如果没有考虑到这两点可能方案就被莫名其妙的拍死了，有的人还会因为挫折太多而开始反思自己的志向。

有一段时间我特别苦恼公司的商业化目标，因为以前一直埋头做用户口碑，想着把产品体验做好就可以了。但是产品突然到了收割期介入了很多“商业产品经理”，提出过很多超出自己底线和无理的需求。刚开始的时候我还一直不理解和反抗，但是仔细想想我才明白，商业化本身和用户体验不冲突。所谓用户体验，本来就是在帮助公司实现商业价值的前提下，尽量让产品保持好的体验的。

而想明白了这个，就开始更积极的去想如何把商业化的体验做好。比如提升广告质量，在场景和使用路径下做精准化投放等。其实很多人觉得商业化是万恶之源，只是因为大家都打着商业化的旗号而懒于思考，见缝插针，简单粗暴做事情罢了，而没有真正的拥抱和思考它。

---

2.3 规划目标的优先级

如果我们设计师接收到的目标只有一个，那干活的时候就太轻松了，因为我们只要稍微挖掘就可以知道应该怎么做。但是到现实中我们往往遭遇的矛盾就是感觉通常目标都有好多，产品经理这也想要，那也想要，这也不能丢，那个也很重要，到底要怎么办?最有趣的段子就是需求方的要求是：高端大气有档次，低调奢华有内涵，简约中带着点霸气，既体现欧式奢华又能传承中国古韵...(笑)。所以我们通常接收到的需求，都是会包含很多目标的，我们要把这样目标分解成优先级：

1，核心目标：核心目标只有一个，是最符合本次产品设计和改版根本缘由的。我通常会和产品经理说假设因为时间和能力有限，他提的所有的要求中我只能实现一个，他会怎么砍?残酷和艰难的抉择留给对方自己，因为只有明确了唯一的核心目标，设计师才能在日后有什么冲突和矛盾的时候做出争取的抉择和判断。

2，兼顾目标：除了核心目标以外，需求方还会说很多“这些最好也需要达到”的目标，比如和品牌相统一，尽量保证开发性能之类的。对待兼顾的目标我的原则是如果能实现我就尽量实现，但是实现不了或者与核心目标有冲突则果断砍掉。有的时候设计师会和产品经理一起纠结在这些兼顾目标中去，纠结完其中一个又纠结另外一个，所以如果之前已经和对方沟通过核心目标，当发生矛盾的时候大家砍掉就变得很自然。

3，有则更好：这个比较简单，就是能做到最好了，需求方也不做特别要求。但是很多时候需求方认为只是有则更好的东西，到了设计师眼里变成很重要的东西，比如做的超华丽，可以发到网上无数点赞的那种。这就需要设计师理解设计的根本是帮助产品解决问题的，优先做好核心目标再思考在这个地方的提升会更受大家欢迎一些。

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

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

图

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

---

2.4 保持目标的导向性

给大家举一个例子，有一次我去找领导讨论，想确定一个导航方式的时候：

图

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

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

3，加强设计的推动力

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

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

---

3.1 更前置的开展设计工作

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

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

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

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

图

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

图

---

3.2 主动发起和跟进

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

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

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

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

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

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

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

---

3.3 管理产品经理

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

所以转变观念很重要。

Review

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

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