敏捷设计，让设计更高效

　　设计师是一群具有艺术气质的思想家，他们以天马行空的创新、特立独行的行事风格存在于各个团队里。区别于其他工作的是，这是一个更注重“灵感”和修养的行业，在东方文化环境下，更又崇尚“顿悟”，因此，上下游的同学都知道，和设计师相处过程中，耐心是要足。
　　为什么要敏捷
　　设计师是一群具有艺术气质的思想家，他们以天马行空的创新、特立独行的行事风格存在于各个团队里。区别于其他工作的是，这是一个更注重“灵感”和修养的行业，在东方文化环境下，更又崇尚“顿悟”，因此，上下游的同学都知道，和设计师相处过程中，耐心是要足够的，好像也是必须的。
　　而对于企业来说，运营的效率是性命攸关的事情，时间就是生命。说到底，生存在社会中的设计师无法不受商业规律的影响，无法超脱世外地艺术化生活，也就说同任何工作一样，效率和质量也是设计师必须面对的、永恒的难题。
　　作为在广告创意公司工作过的设计师来说，加班永远是主题，我曾经有过三天三夜不睡觉，设计一本书，被抬上飞机的经历。踏入互联网的领域后才发现，命是天定的，人性化的bta企业也有那么多的加班。对于像设计师这种习惯创新的族群，自然地会寻求，天底下是否有一条撒满鲜花的舒适坦途？企业则也会去思考，有设计参与的项目是否可以一样敏捷高效？
　　在深圳工作的这6个多月里，我们同技术、产品等伙伴尝试了一种新型的工作方式，这种工作方式令我们在1个月的时间里，完成了通常需要3个月、甚至需要更多时间花费的工作，同样的高质高量，同样的快乐活泼。这种方式我们暂称“敏捷设计”方法。
　　这种敏捷设计方法的是挑项目的，因为它需要更早地规划好项目日程，且配合的团队需要结构稳定、预留好想对固定的资源。我们无法让一个个朝生夕灭的临时项目系统化地敏捷起来。
　　且敏捷设计的参与人员要有创业精神，不纠结于流程和职位级别，一切以推动项目进展为准则。
　　敏捷的方法
　　跨专业明确分工
　　要想团队敏捷起来，立即理清各自的职责分工是十分紧迫的，有的同学或许会问，大家平时的分工很明确，运营、产品、设计、技术、测试都是十分精确专业的分工，还需要二次分工么？怎么分呢？
　　要想敏捷，所有合作者就必须跨专业思考，比如设计师要理解产品产生的原因，前端要理解设计美学的大致规则等，只有充分理解才能有诚意的合作。所以，跨专业思考是首先要解决的一点。
　　日常项目中，一个项目的原始沟通，要在彼此理解的前题下，非常明确地跨专业划分职责，比如让视觉和交互合一，有能力的设计师可以通吃交互视觉，交互承担部分简单的产品工作，产品承担简单的用研与分析工作，开发承担部分前端工作等等。跨专业明确分工，是敏捷的关键第一步。
　　除此之外，敏捷设计需要调整彼此协作的具体方法，这里总结几点：
　　晨会
　　各种kinkoff评审会沟通会在项目中会占大量的时间，但这些关键会议又在达成一致意见，大多不能省略，所以缩短会议时间、增加会议效率是必由之路，而短暂、固定的站立晨会是解决这个问题的好办法。站立晨会的时间控制在15分钟以内，只谈解决方案和核对进度，不展开讨论，有分歧的可以回后单独私聊达成一致，第二天晨会更新上来即可。
　　并行投入
　　为了敏捷起来，除了跨专业思考，理解上下游的承接方法，还必须并行投入，这是关键、并且会产生大量困难的一步。
　　所谓并行投入，最初沟通即要求技术、设计、产品都必须同时参与业务沟通，可以由产品或运营主导，来推动前期沟通，在这个步骤不仅产品自己理解了业务，更要让后续的技术和设计明白，产品之所以如此设计的原因和业务目标是什么，这样有利于后续协作同学更早介入业务，更早思考起来，从技术、设计角度帮助产品贡献创新思维，有时反而能事半功倍地达成所要达到业务目标。
　　并行产出
　　在产品规划阶段，ued根据业务需求，从用户视角开始前期用户体验模拟设计，并及时提供给产品、技术参考，技术根据业务需求产生技术基础解决方案，这种方案的前提是不依赖交互体验，纯粹从技术角度，按最佳技术路径来解决问题，提出解决方案供产品、ued参考。在此时，ued与技术均不用精耕细作，提供完整的大致解决方案即可，在设计中表现为“低保真的交互稿”。并且，这里的角色是互动的，产品、ued和技术提供方案的同时，也从协作方彼此获得对方的初步解决方案，并实时调整自己的对应方案，这是一个来回不断斧正的过程，最终的成果是带交互设计的、在技术实现上论证可行的、有解决方案的产品prd。
　　这种prd推出时，技术和ued的进度都不会像以往那样还在0的基础上等待，说不定已经万事具备，只欠fprd这个东风了。
　　先进度，后体验
　　一个项目闪亮登场，当然是全部参与者的共同目标，也是最好情况。但是在大多数互联网项目中，因为要抢在某个时间点抢先发布，不断迭代、小步快跑是常态，这时设计师有必要调整好心态，同协作伙伴一起，规划体验还原度的时间表，让项目的进度不受到一些小细节上的还原度的影响，但又能保证某个时间点，体验基本实现一致。
　　比如可以要求一个项目进度中，在灰度测试时，实现60的体验还原度，正式发布前实现80，上线后第12次迭代后实现95的还原度。这样的进度符合商业速度，也能在兼顾前端、开发同学的承受能力的同时，保证体验的基本水准。至于100的还原度，那可能要过一个比较长的时间，甚至要准备永远都不会实现，因为互联网项目生命周期太短，更迭也太快，无法追求永恒的完美。
　　先进度，后体验，不是说放弃一部分体验，这里特别要注意前期的体验还原度时间表的严格规划，和后期的及时跟进，否则就会变成只有进度，毫无体验。
　　产出物
　　一般来说，协同作战容易误伤，不注意的话，一不小心就给自己合作伙伴挖了个小坑。所以大家的协同时，一定要先商定最后产出的形式，在上下游都能接受的情况下再协作。
　　首先，设计师的体验流程要与产品经理的商业流程一起产出，并及时核对，这一步基本就确定了大致的页面数量、交互路径，也确定了前端工程师在页面这块的工作量。所以，必须在体验流程图与商业流程图都要具备的情况下，并且这个流程是经过业务方确认的，才进行设计工作。
　　其次，除了并行产出的“低保真的交互稿”和“带prd的视觉稿”外，设计师应与前端工程师达成一个关键性的“合同”前端在实现视觉稿时，把通用的部分，如按钮、输入框、弹出框等等组建，全部模块化，像一个个盒子一样封装起来，后续不仅前端不需重复开发，设计师不需重复设计，甚至能实现让产品经理自己组装页面结构，这对整个项目敏捷度的影响将是革命性的。
　　当然，搭积木一样的模块化操作，必然会对用户体验指数有一些负面影响，这里就要求设计师注重最后对最终产出物的验证，在上线前必须的用户走查，上线后可以通过真实用户测试、或者ABtest研究来检验模块化组装的页面，并由设计师做后续设计修正。
　　敏捷化的设计师
　　了解商业和技术
　　达到商用路径的方法，往往在专业上有好几条不同的路径，设计师理解了项目的商业诉求，更有利于找到一条对项目来说最合适的设计之路。
　　设计师大多数对商业规则和原理不感冒，对商业设计之类关注更多，现在提倡设计师了解商业也是流行话语，不过，商业这个名词太大，我们设计师究竟要了解商业的哪个部分呢？我的主张是从目前做的项目入手，先理解这些具体项目的相关的商业，比如项目目标和未来规划是什么？生命周期多久？影响项目的商业数据是哪些？弄明白这些，基本能保证设计方向不会有错。
　　跨专业的工作
　　大家的专业都是从学生时代就确立的，往往跟个人爱好、能力倾向有关。进入公司后，一般都会提倡复合型人才，你会的越多，解决问题的能力越强，最好几个不同的问题，无需再跑几个部门，找你一个人就解决了。然而对设计师来说这是巨大的挑战，视觉兼顾部分交互，要解决自身逻辑和结构化思考能力问题，交互兼顾视觉，则有美学培养的要求在。然而，这些能力培养是长期的，跨专业工作也不是要求培养通才，只是希望在原有的知识框架边上，做少许延展，方便上下游的接驳，当然，在紧急重大的项目中，更提倡有能力的设计师一肩承担，更能加快项目进程，节省大量沟通成本和转接项目的资源损失。
　　沟通与谈判能力
　　沟通和谈判能力中语言表述只是一个方面，更为重要的是对项目背景、上下游情况、商业目标的透彻理解，可以说台上一刻钟，台下十年功，一个对项目基本背景都不深入了解的人，是无法站在谈判桌上的，更不要提向对方推介自己的设计了。所以，沟通和谈判能力是建立在对项目深度理解的基础上的，设计师不应做没有准备的设计评审和讨论。
　　另外，注重对会议管理学习，通常沟通就时一场小的会议，沟通之前必须知道自己要得到什么（会议目标），可以放弃什么，底线在哪里，做好部分妥协的准备。