从思考到创造 2016-08-01 11:27
扫码打开虎嗅APP
文 / 林敏
7月初的时候，我参加IxDC大会的「设计管理」峰会（没错，就是那个惊动媒体圈的IxDC大会），与另外几位嘉宾一起就设计管理这个主题分享一点各自的理解和看法。事后来看，真心感谢现场观众的支持和爱护。我们几位“主讲人”都算交出了合格的答卷。峰会最后一个环节的现场问答由于时间缘故，无法对所有的提问一一作答。不过，细心的志愿者主动帮助汇总和整理了没能现场回答的问题。于是，就有了这一篇的场外问答集。
因为主题是设计管理，因此关于具体设计本身的问题（如：怎样进行本地化设计）并不包括在这个问答集中。此外，我把相似的问题进行了合并，并尽可能根据问题的相关性加以组织，重新分为以下七类：
设计评审
考核和KPI
设计师的成长
设计思维
团队定位
跨部门协作
需求管理
设计在价值正被越来越多的企业所认识到。我的这些回答希望能够为遇到类似问题的朋友们提供一点思路上的启发。因为每个团队的情况都有所不同，具体的措施未必具有直接可实施性，生搬硬套搞不好反而会适得其反。
一、有关设计评审的提问
对于大公司里面的设计作品，如何评审才是合理的流程？
日常的设计评审流程应该怎样才好？例如日常运营需要的视觉设计，由视觉leader来拍板定稿合理吗？还是要团队一起拍板？
设计方案评审中，有时会对方案投票。但人员素质不一，如何考虑方案评审中民主化的分量？
管理者的职责，除了管人之外，最重要的就是做决策。视觉方案由视觉leader拍板没有什么不合理。如果项目很重要，那就在视觉leader拍板后再由TA的上级审核确认。无论什么时候，交给团队拍板都是非常糟糕的方式。决策前可以征询团队意见，但决策绝对不需要投票。
把方案付诸投票的做法看似民主，其实是极其不可取的，也是不负责任的。民主不是“最佳”的同义词。民主的代价是低效和折衷。因此，如果我们真的在乎好设计，那么就把这个决策权交给公司里对“好设计”有深度理解的人就好。如果公司里没有这样的人，那就应该花心思去吸引这样的人加入公司。总之，评审本身并不需要民主。
设计评审的目的不只是看设计，更需要在满足功能需求和业务需求的基础上考量设计方案的好坏。因此，设计评审的前提是设计方和需求方（产品经理）对于这一次的设计需求（功能列表）和设计目标（关键业务变量）已经达成明确共识。在缺乏共识的情况下进行评审的意义不大，很容易成为自说自话。
评审本身，可以大致分以下几步进行核查：
（1）完备：所有的功能需求是否都得到支持；
（2）合规：设计方案是否符合公司的基本设计规范和一致性；
（3）架构：信息架构和组织方式是否合理；（不涉及信息架构的设计可以略过）
（4）可用：设计方案在可用性方面是否不存在明显问题；
（5）交互：围绕设计目标所做的每一项针对性设计是否合理；
（6）视觉：视觉方案是否符合品牌调性和目标用户的审美；
（7）原创：整体方案是否不存在抄袭行为。
二、有关考核和KPI的提问
对设计师考核的问题，有没有比较科学的考评方法？
对设计师应该如何考核KPI？设计团队KPI怎么制定合理？从哪些方面？
考核不好，KPI也不好，那最后的推进方式是什么？
设计团队如何抗衡运营KPI？运营手段与设计规范相冲突时，设计团队应该坚持规范还是如何处理？
我们谈设计管理，工作的管理有很多工具，人的管理的方法论是什么？大小团队是有区分的，能否给出一些管理方式的案例？对于设计师还是需要评估考核，不论团队内部还是参与到项目设计中，需要竞争，也要提供晋升通道。
KPI是个很复杂的问题。人是多样和复杂的，怎么管好人和企业是什么文化，管理者自己是什么特质，以及团队里都有什么样的人有很大关系。笼统地说，就是选对人，用好人，留住人。在管理这条路上，我也仍然在学习中。
在实践中，我把最重要的KPI分为两类来考虑。它们分别对应的是对业务的和对团队的贡献。对业务的KPI，要根据在公司的组织架构中，设计和市场的远近来选择不同的变量。离市场近的，可以考虑让设计师直接扛业务指标（例如自然转化率）。离市场远的，就从服务角度来设定KPI（例如被投诉次数）。对团队的KPI，需要管理者为每个设计师设定其当下对于团队的价值（例如带新人、出专利）。设定团队KPI的思路其实和前面是类似的，即体现为对业务的贡献和对大部门的贡献（例如提升部门里的其他团队的设计思维意识）。
考核和KPI的效果都不好的原因多半是没有选好评价用的变量。在我看来，不用去理会评价体系是叫什么名称。既然现有的不好用，那就去琢磨到底是哪些方面没有在现有的评价体系中得到体现，哪些正在应用的指标并不能给出有效的评价，然后试着重新选择或调整变量。这本身也是一个试错和迭代的过程。
虽然运营的很多设计需求很碎很杂很乱，但是设计团队没有必要和运营相抗衡。比较理想的做法是运营团队有自己的设计师，满足自己的设计需求。作为产品的设计团队，就可以专注于产品的设计。如果必须由设计团队来支持运营的设计需求，那么最好是指定专人来做。例如将团队里资历最浅的设计师（们）分出一部分精力用于提供运营支持。这样做的好处是可以让新成员熟悉运营团队及其需求，并随着TA们的成长而过渡到对产品设计的专注上。
运营的设计和产品的设计是不同性质和目的的设计，没有必要要求运营的设计必须符合设计规范。但是，这也并不意味着运营可以想怎么做就怎么做。较好的做法是在设计规范中逐条注明是否需要运营遵从。
在我的团队中，我很强调设计师在理性和感性两方面的融合与平衡。除了手上功夫好，思路开阔之外，我还要求设计师能够条理清晰地阐释自己的设计。再结合团队本身需要不断成长的需求，我一般会从五个维度评价一名设计师的综合能力。
(1)执行力：是否能够有效完成具体的设计需求；
(2)创新力：是否具有开阔的思路，能够提出有效的创新方案；
(3)理解力：是否具备逻辑思考和有效阐述设计方案的能力；
(4)协作性：是否能够与他人进行有效的沟通和协作；
(5)导性：是否能够有效给予年轻设计师指导和帮助。
不过，并不是每一位设计师都需要同时在这五个维度表现出色。前三项是“标配”，后两项是“加分项”。团队处于不同时期的时候，对每个设计师的能力要求会有不同的侧重。这就需要设计管理者能够根据团队的需要适时调整和引导每位设计师在某些维度上多下工夫。
三、有关设计师的成长的提问
在管理中，有没有什么机制或方法来提升团队设计能力或设计水平，尤其对于成长中的团队？
设计规范导入易导致刚刚从业的设计人员存在过分依赖情况，降低创新意识。成长期团队应如何应对？
对于涉及团队中的成长型设计人员，如何有效帮助他们提升设计水平？有时候会担心过多的干预会影响他们的创意和积极性，但如果放任最后的成果又往往达不到要求。设计师大部分都很有个性，所以沟通修改往往也不会很顺利。除了磨练他们自己的个性外，在设计团队管理者角度有什么技巧可言么？
用户体验设计团队中，管理者与设计师之间以怎样的方式相处最佳？狼与羊，狼与狼，羊与羊？
关于设计师在团队中的成长，没有什么秘密。在团队层面上，就是鼓励大家多交流多讨论。比如每周固定一个时间，让设计师轮流分享自己近期的设计，重点是分享设计背后的细节思考，以及最终设计的不足或缺憾。同时，让其他设计师发表各自的见解和建议，形成集体讨论。不过，从管理角度说，不应该为这件事分配太多的时间（比如每周半天可能就有些不太合适），因为设计师的成长从根本上说应该是自我驱动的。依赖管理者的鞭策才能成长的设计师我认为是不值得培养的。
同样的道理，设计规范的导入就不需要过分照顾新从业人员的“惰性”。在规范问题上，要清楚规范并不是把设计变成搭积木，而只是为设计定义了一些边界。只要在边界以内，是允许（而且鼓励）创新的。设计主管有责任把设计规范的正确理解传递给新的成员。如果出现个别设计师创新力不足的情况，应该及时给予提醒和关注。上面提到的团队内部的设计分享为年轻设计师的学习成长提供了一个有效途径。如果团队新成员较多的话，那么可以定期组织一次围绕规范的创新工作坊来强化大家对规范的理解和应用。
我在峰会现场的发言中有提到，那些认为设计团队的氛围就应该是“平等自由、一团和气”的设计管理者在我看来是不合格的。在我看来，对设计师群体的管理不见得就要采用多么特别的管理方式。设计师“难搞”的地方不是个性，而是傲气。
设计师的傲气在管理上的表现就是不服管。程序员、工程师也都是很有个性的群体，但他们与设计师不同的地方在于基本上都可以通过讲道理解决工作上的争议。而有些设计师要显得过于感性一些，要“哄”要“捧”。
作为设计团队的管理者，要处理好“哄”、“捧”和理性之间的关系。我自己的经验是从接手或组建团队的第一天开始，就要明确“人”和“事”上的原则：对人将心比心，对事以理服人。
管理者与设计师之间的相处之道，我认为最好的方式是合作模式。是狼是羊都不是重点，重点是不要把两者处理成管人和被人管的对立关系。管理者的工作分工是从事管理，设计师的工作分工是从事设计。双方在合作模式中实现共赢。
管理者面对还在成长中的年轻设计师，理应多一点耐心。举例来说，你可以和TA坐下来，让TA对自己愿意接受的干预度给一个度量（比如完成80%左右才拿出来讨论）。在项目风险可控的情况下，你要尽可能满足TA的这个预期。然后根据每次的实际产出结果进行调整（比如从80%下调为60%，或是上调至90%），找到更合理的干预度。这样作为设计师也很清楚你对TA的干预并不是心血来潮，而是基于TA的工作能力。要想获得更少的干预，TA就需要更快地成长。
四、有关设计思维的提问
在一家传统生产制造型企业，应该由什么角色的人来推动design thinking方法论？因为遇到一个困难，做设计的没有市场观，做市场的不懂技术，谁也说服不了谁。
如何让传统的公司具备设计DNA，具体方法又是什么？
针对设计管理驱动设计创新中，“驱动”这个动词在项目实施上有哪些可推荐的操作流程或指导？
产品设计如何用好“设计思维”？希望能举例说明。
如何把design thinking方法论结合其他项目推动方法论（比如敏捷思维）更好地在项目实施中运用？
要在产品设计中用好“设计思维”，简单说就是在任何一个用户触点上都用心设计，保持一致的、能够打动人的体验。至于例子，苹果公司有的是。
今天还只是少数公司可以真正做到以设计进行驱动。如何实现“驱动”是个十分复杂的话题。我可以简单列出几个要点：
从上而下，先在最高管理层确立对“设计”的理解；
跨部门文化建设，不把“设计思维”局限在设计部门里；
注重每一个用户触点的设计，而不只是在产品界面上；
“品牌-体验-设计”的深度融合；
坚持，坚持，再坚持！
设计和市场谁也说服不了对方的情况很常见，因为不同职能部门在不同的语境里难免出现自说自话。要推动design thinking成为一种跨部门的共识，需要企业自上而下的推动。因此，从根本上说，这是一个需要CEO或者负责用户体验的副总裁（今天在本土企业中还不存在）来牵头并保持关注的事情。对于传统公司而言，让大老板真正理解设计和设计的力量是关键。没有达成这一步，其他的都是空谈。
除了设计思维，今天还有一些流行的方法论。需要说明的一点是，将各种方法论加以叠加，不应该成为一个目的。将多种方法论放到单个项目中同时实施，很容易给项目增加不必要的复杂度。
此外，博采众长的前提是真正理解每一种方法论的精髓。当我们一定要结合多种方法论的时候，应该在熟练掌握至少其中一种方法论的基础上进行添加。无论如何都应该避免把两种都不熟悉的方法论加以叠加，这绝对会成为一个噩梦。在叠加的时候，不要采用简单的加法，而应该是对已经熟练掌握的方法论进行调整，并且是逐个环节加以调整。最后，通过在项目中的尝试来检验效果的好坏，并加以修正。关于方法论的运用，最根本也最有效的方式是逐步形成自己的方法论。
五、有关团队定位的提问
如何管理高层审美，逐步输出并影响高层？
新建的部门很容易出成果，但是时间久了以后发现小团队效率更高。虽然UED的存在更有利于人员成长，可是在领导面前比较苍白，体现商业价值非常必要。
UED成立后作为内部的资源池由各部门调用。但调用时间长了以后，外派的设计师成了产品线内的专家，很难进行人员扭转，产品线不肯换人。那么，UED是否有存在的必要？如何让UED在公司内部体现商业价值？
UED怎样摆脱“乙方”被动位置，真正在设计上、体验上有所突破变为主动？
高层审美的问题，是很多团队都会遭遇的现实问题。我对这个问题的处理，就是帮助高层确立“专业的事交给专业的人去做”的观念。具体做法上，一明一暗。明的方面就是要经常在高层面前谈论与审美相关的话题（例如时尚、文化），并能言之有物。这不仅需要个人的深厚积累，还要有很好的表达能力。所以这要看个人性格及修为如何，并不适合每个人。暗的方面就是既要听高层的“指点江山”，又要坚持自己的正确判断。做两个版本，做对比测试，在时间轴上通过数据让高层逐渐认识到自己固执己见的见解并非真的很高明。
UED团队应该以何种形式的存在，并没有标准答案。当业务线还小的时候，使用公司内部共用的UED支持在结果上更有保障。当业务线壮大起来以后，拥有自己的设计力量就显得更为合理。UED团队，如果只是接需求做项目，那本质上和外部的设计咨询公司没有差别，存在的意义便很单薄。所以，从长远讲，内部的UED团队需要构建超越外部设计咨询公司的核心竞争力。作为UED团队的管理者，对于UED团队的定位要有自己的理解和坚持。
UED团队从被动支持变为主动引领，这个过程并不简单。实现转变的关键因素不在设计团队本身，而在高层。先要在高层形成设计驱动的观念，然后才是设计团队的出色表现加以彰显和巩固。这是一个只能自上而下的过程。但这并不意味着设计管理者就是被动地等待高层的顿悟。相反，在这个过程中，设计管理者扮演着十分关键的角色。光埋头把事情做好并不能保证会自然地实现从被动到主动的转变。
六、有关跨部门协作的提问
工作中交互和产品人员的分工怎么调整？感觉这两者工作中交叉很多，有很多交换设计师做的（设计）产品人员不认可，或者觉得这块（工作）应该他们自己干。
在产品快速迭代的过程中，交互设计跟不上产品迭代的步伐，该如何定位交互设计？
设计提到的很多创新点，会在实际上线过程中受到来自程序、运营、销售各方面的制约和阻碍，怎样处理这种矛盾呢？
设计创新的过程中，如何在开发部门和市场部门对设计价值的质疑和开发成本的阻力下进行有效的推动？
跨业务线的项目，会让某两个小组临时融为一个小组来协同设计。这个时候，强调的就是协作和分享了，算是在试错，所以对于拿捏的方式还是有些疑问。
产品和交互之间的职能重叠在很多企业里普遍存在。产品做交互，交互做视觉，视觉做海报，是典型的职能错位。产品做的事情是从市场角度定义产品，也就是做什么，为谁做，做到什么程度，产生什么价值，以及怎么到达用户手里的问题。交互做的事情是把产品的功能需求转化为靠谱的交互设计方案，也就是定义用户该怎么使用自家产品的问题。
如果交互跟不上产品，那么可能的原因有两个：产品迭代太快或是交互设计太慢。
首先把这两个原因做一个剖析，不要简单要求交互加速。产品是不是必须跑这么快？慢一点可不可以？
假设说的确是交互的速度问题。那么接下来要解决的是交互设计的提速。可以有以下一些措施供参考：
优化产品到交互的衔接流程
建立设计规范
提供设计中间件
增加交互设计师的数量
用高级交互设计师置换经验不足的新人
但不管怎样，交互设计的定位不会改变，也不应该改变。产品因为交互跟不上就自己动手做交互并不解决问题，只会带来更大的问题。至少我没有见到过成功案例。
不管具体是因为什么原因，在存在质疑的情况下推进设计创新是几乎不可能成功的。处在这种境地中，就要把角色换一换。不要追求设计驱动，尤其避免强推设计。我个人觉得较合适的做法是改以配合为主，去发现开发或市场部门好的创新想法，然后帮助完善和呈现，再争取加入一两个设计上的创意。换句话说，先从小贡献者做起。不要时时刻刻把自己当作一个引领者。
开展跨部门协作是不可避免的。其中最大的风险不是各自团队的专业能力，而是各自的“hidden agenda”（台面下的小算盘）。
不要把“为了让项目更好”当作开展跨部门协作的第一目标。当然，我们都希望项目能更好。但是，跨部门协作的成功率并不高。在正式开始协作（甚至开始商讨协作）前，需要先想清楚（设计好）两个小组通过协作各自能够获得什么实实在在的利益。这个利益是要能够体现在KPI中的。尽管我们反对KPI驱动的工作模式，但是在协作关系中必须假设对方会以KPI作为考量。
两个小组的协作，要避免直接指挥对方团队的人。构建一个leader对leader层面的定期沟通机制很关键。这样出现问题或是需要调整资源的时候才能够及时沟通，及时决策。做好自己一方的事情，承诺的一定要做到，这会增加对方兑现承诺的概率。
既然是试错，一定要在协作之初就让对方团队清楚项目的试错风险。如果失败了，对双方团队有没有影响，能不能承受。不要只看到成功的诱惑而忽视失败的可能。从这个意义上说，项目的拿捏关键点是不要把目标定得太高。小成比一无所成要好很多。
如果双方是第一次协作，那不要对项目的成功抱太大希望。项目在试错，团队协作也在试错，成功的概率自然小了许多。都算50%的概率，最后也只有25%的概率会顺利。所以，从保护自身团队的角度出发，要把项目风险事先和团队沟通清楚，出现问题才不至于陷入混乱。
设计过程中一定会有很多创意。这些创意可能很酷炫，但不一定现实。这种看似矛盾的状况其实是个沟通的问题。站在设计的角度，一定要清楚创意可以天马行空，但创新必须力所能及。设计首先不要把来自开发、运营、销售等其他职能的限制条件看作是对创新的制约和阻碍。这些限制条件一直都在那里，只是我们没有去注意和了解，直到被创意燃烧到兴奋的时候才意识到。
多和其他部们交流，了解这些限制条件。当创意涌现的时候，先在设计内部以及邀请相关部门评估是否会触及这些限制条件，然后根据创意的重要性来决定是否值得尝试突破限制。接下来就应该和相关部门展开积极的沟通，一起寻找解决之道。而不是摆开一副“你们都不懂，直接照我这样做就好”的姿态。
把创新作为多方合作的共同产物，而不是只看到自己的功劳，把别人都当作支持角色。当开发、运营、销售都能够感受到自己在其中的贡献的时候，自然就不会有什么不可调和的矛盾了。
七、有关需求管理的提问
怎么看待业务频繁的需求变动？如何从管理角度正确平衡需求与设计？
产品发布前，疯狂改UI的issue，都是这样的么？
设计与项目进度如何协调？设计也和产品一样有迭代概念吗？
需求变动在新的产品尝试中很正常。但频繁的变动就有些不正常了。出现这个局面，大概是流程、项目管理、专业性这几个方面中的一个或几个出了问题。
遇到这种情况，要立刻和业务方沟通，理清原因。是市场变化太快，还是需求方太多，还是需求方的想法太多，还是其他什么原因。一定要搞清楚。站在设计团队角度，要在协作过程中持续对业务方进行“信任”评价。信任等级越差，就应该越坚决地拒绝业务方提出的一些需求变更。这也意味着，设计团队对于产品和业务需要有自己的理解和判断，只是埋头做设计是不够的。因为那样就完全不知道该拒绝那些需求。团队里需要有对“生意”敏感和有想法的人。
另外，设计应该出现在项目进度计划中。我在不少公司看到项目进度中的“设计”环节并不是由设计团队给出的。“倒推法”看似合理，但挤压的往往都是研究和设计的时间。所以，设计团队需要参与到项目进度的讨论中，并负责给出“设计”环节的进度估计。如果这点都被排斥在外，那设计团队在组织内的地位差不多就是美工了。如此，也不用操心去协调进度，应该操心怎样提升内部影响力。
设计也有迭代的概念。我们经常会看到的大改版就是迭代。这一点，和产品没有什么不同。
作者公号：林老师的私塾【FollowDrLin】
