编者按：如何形成自己的设计方法，建立交付物的衡量标准，优化协同模式。在这篇文章里，你可以看到一个阿里专业设计师是如何进行自我提升的。鸿影：如果2015对我来说尚处于用户体验设计的职场入门阶段，2016的核心则是开始撕下初级与新人标签的进阶修炼。4月份的2016 S1开始的时候，我给自己设定了包括形成个人设计方法论与应用案例等一系列目标，如今S1结束，也是时候对这段时间的进阶修炼来一个总结回顾了。
形成自己的设计方法 在公司内部经常会有一些跨部门的UED分享活动，听下来个人最明显的一点感触就是，这些来分享的设计师普遍有着一套自己思考总结出来的设计方法论，并且有成功应用案例支撑。也许有人会有疑惑，现在关于设计方法的轮子到处都是，网上随便一搜就能找到某某大厂某某大牛的设计方法分享，直接拿来用就好了，为什么还要费心费力自己造轮子呢？在我自己的设计方法还没有完全成型时，我一度很迷信于网上别人的各种设计方法的分享，并试图在自己的项目里加以运用，但结果却差强人意：设计推导的过程看似洋洋洒洒专业性十足，拿出来给别人一看一讲就发现漏洞百出；有时为了套方法而套方法，体验地图一类的输出物看似有模有样，最后项目做完了才发现设计方案时基本没用到……虽然自己用的都是别人经过验证的设计方法，但却没有理解透这些方法的应用场景与局限所在，也不清楚哪些环节其实并非必要存在，自然也让实际的应用效果大打折扣。而靠自己思考、沉淀和交流改进出来的设计方法，理解和运用起来则要透彻顺手很多。如何形成自己的设计方法？最好的途径是跟着项目走，尤其是要主动去争取那些介入节点早、体验驱动强、完整性高的项目机会（我自己的设计方法就是在一个UX作为Owner驱动的网站改版项目中形成的，这个项目中的Owner角色争取也是主动向PD提出，然后得到对方放权的），作为设计师，从最开始的业务问题分析与用户调研，到最后的系统设计方案产出，每个环节都深度参与，对一些前期的工作要摒除掉「这是用研干的」、「这是PD干的」的思维局限，而采用和专业人士共创输出的方式；因为设计方法是一个很完整的发现问题-分析问题-解决问题-验证效果的过程，如果总是让产品经理把用户痛点和解决方案全部梳理好给你，自己满足于做一些交互细节的优化与补全（这也是我觉得大公司的大型设计团队不一定那么好的重要原因，想接触高完整性、高自由度的项目偏难，虽然也会羡慕他们能花很多心思去打磨动效等体验细节），而不是主动争取更早的介入时机与更多的项目话语权的话，是很难在项目里建立起全链路的思维方式，进而提炼总结出自己的设计方法的。在建立设计方法的过程中，除了从项目的每个环节中思考提炼以外，也要多吸收前人的经验（不是无脑照搬，而是有意识去找业务背景、产品类型相通的应用案例），多和经验比自己丰富的同事请教交流，不断修正优化自己的设计方法，而不是幻想着一劳永逸。
建立交付物衡量标准 大厂的实习生/校招生入职后基本都会有Mentor（我厂内部的叫法是师兄）带着，设计交付物往往都是先经过Mentor的一轮Review，再正式拿去和大家评审，Mentor们能发现很多我们自己没注意到的问题，指导我们做出改进。但对于Mentor的过于依赖（无论项目大小都要找Mentor看一遍，遇到问题直接问Mentor解决方案而不是自己先想出方案再请教），则会让我们丧失独立思考与判断方案好坏的能力（两年前我曾被一位Mentor这么批评过），我是很难相信一个独立思考能力弱的设计师可以做到真正的「独当一面」，而「独当一面」的能力正是初级设计师与高级设计师的重要分水岭之一。怎么更准确全面地思考和判断自己的设计方案的好坏呢？我的应对策略是给自己建立一套完整的交互设计方案衡量标准，再用这套标准去要求和驱动自己做出更好的设计。我的这套衡量标准建立也不是一朝一夕，而是在项目中不断总结沉淀自己踩过的坑，再结合网上前辈们的一些分享而成，涉及到目标相关性、流程完整性、整体美观性、易理解性、易操作性、技术可行性、分支与边界状态、情感趣味性、品牌调性传达、业务创新性、社会责任感等多个方面，具体大家可以参考我的这篇文章：交互设计方案衡量标准的五层总结。
驱动协同模式的优化 一些交互设计师喜欢抱怨自己的岗位在上下游协同中效率低下、话语权低、可有可无等，然后产生转产品转视觉转前端等念头，我也承认和其他岗位相比，交互设计的话语权与不可替代性确实有一些先天劣势，但我不认为这就足以构成我们抱怨和转岗的理由，相比坐以待毙式的消极对待，我更倾向主动去争取和驱动交互设计师与上下游协作模式的优化，从项目组的角度是去提高协作效率与产品最终体验，从交互设计师个人的角度则是去争取更大的思考发挥空间与话语权。在和上游（产品经理、业务方）的协同模式改进中，我争取的是更早的项目介入时机与全流程的跟进参与，从传统的Prd评审完成（这个时候PD基本都梳理得差不多了，在时间有限的情况下设计师很多时候就只能做细节优化补全了）再介入，到亲身参与和用户的接触访谈、从用户反馈中获取最原始、第一手的需求，然后和用研、PD共同完成一系列的场景梳理和需求分析工作，PD的输出物从传统的Prd转变成聚焦在内容底层逻辑梳理的新Prd，设计师对界面布局有充分的思考发挥空间。不过需要指出的是，这样做容易造成时间周期拖长，不是对每种项目都适用，比如一些强业务需求、上线时间紧急的的项目，还是传统的合作方式效率更高。在和下游（视觉设计、前端开发）的协同模式改进中，我争取的是重复性工作（对设计专业提升意义不大， 还对设计思考的时间造成挤压）的减少，主要是设计规范的沉淀（这类分享网上有很多，就不赘述了）、以及和视觉更交叉性的合作方式（不是所有项目都要过一遍交互再过一遍视觉，可以视对交互/视觉的要求程度由其中一个人全包，规范的沉淀也能促进这一进程）。我羡慕过友部门的大型设计团队有自己专业成熟的设计流程和设计规范沉淀，新人也能很快上手，但当在没有这些的情况下，自己亲手去按自己的想法把流程优化和规范沉淀这些事情做起来，而不是当一个只会用别人的流程别人的规范的螺丝钉（以前实习时跟过有成熟设计规范的项目，对比下来那段时间的成长速度也是相对最慢的）后，成就感其实要强烈很多。
提升软技能 可能是性格原因，口头表达能力可以说是我实习期间 + 来阿里第一年内的绝对软肋，和书面表达能力完全不在一个层面（这也是一度让我耿耿于怀的地方），那段时间特别害怕做设计Review和内部分享，很容易失语或者被挑战得语无伦次。演讲与表达能力作为对设计师非常重要的一项软技能，想提升上来也没有太多技巧，就是多练习多上台，最近一个多月来连续做了3次Presentation，虽然还是不完美（比如语速快的老毛病改不掉），但整个人的信心和气场一次比一次强，3次下来感觉和之前也完全不一样了。具体的对于做好Presentation的总结可以参考：如何做好一场设计提案的Presentation。除此之外，时间管理能力也是这段时间内个人一个比较大的提升，同样也是在紧张的项目节奏里被逼出来的，之后再遇到类似情况时心态和处理方式就老到了很多。具体参考：交互设计的优先级判断与排期协同。
关于创新的思考 最近团队内部经常提到「创新」这个词，这也是大家普遍做得相对不太好的一个地方，但我觉得如果只是停留在界面设计的表层去思考「创新」，想要引领趋势潮流、做出老板想要的「颠覆性设计」本来就是强人所难。关注体验设计趋势变化的设计师不少，但能够深入去挖掘和思考趋势变化的背后原因的设计师，恐怕就没有那么多了，而从学生时代一路关注体验设计趋势这么多年，我的一个感受是：界面与交互的更新只是最表层的体现，其本质更多是产品商业模式的变化和底层技术的成熟，如果缺少对这一层面的理解一味追求纯表现层面「与众不同」的创新，就脱离了设计「解决问题」的本质。我从实习以来接触的不少Senior级设计师，都非常主张产品设计是商业、体验与技术的平衡结果这一观念，这一观念对我的影响也很深，对商业模式的思考和对技术趋势的敏感，也是我仍然需要加强提升的。
一点无关的话 可能是因为我的工作范围早就不局限在狭义的交互设计岗内，而是一再向产品和业务端延伸的缘故，最近 PD 同学甚至都问了我一句「是不是打算转产品经理」，而我的答案依然是「并不考虑」。其实近期也看了不少交互设计师表达自己焦虑情绪的文章，但我一直清楚自己当初选择做交互，主要是考虑到它是可以把我同时喜欢的「产品」和「设计」平衡结合得最好的岗位（其实我最喜欢的是从产品到视觉全包的产品设计师岗，但是大厂里没有，自己的能力也还不达标），交互设计的延伸区域（和其他岗位的职能重叠区域）也都是我比较喜欢的（目前不想转产品/视觉/前端的重要原因之一，就是这些岗位本身还好，但一些延伸区域我不感兴趣），虽然有话语权之类的先天不足，但只要自己不被岗位束缚住，主动去争取机会，完全可以改观。或许和关注上升空间、发展前景相比，我更喜欢的是交互设计/用户体验设计本身（就是那种非上班时间也停不下来研究和思考，有了好的想法瞬间整个人都能燃起来的喜欢），在这个专业及相关领域的提升能带给我源源不断的快乐，这就够了。
