设计师是一群具有艺术气质的思想家，他们以天马行空的创新、特立独行的行事风格存在于各个团队里。区别于其他工作的是，这是一个更注重“灵感”和修养的行业，在东方文化环境下，更又崇尚“顿悟”，因此，上下游的同学都知道，和设计师相处过程中，耐心是要足.

为什么要敏捷

敏捷的方法

跨专业明确分工

要想团队敏捷起来，立即理清各自的职责分工是十分紧迫的，有的同学或许会问，大家平时的分工很明确，运营、产品、设计、技术、测试都是十分精确专业的分工，还需要二次分工么？怎么分呢？

要想敏捷，所有合作者就必须跨专业思考，比如设计师要理解产品产生的原因，前端要理解设计美学的大致规则等，只有充分理解才能有诚意的合作。所以，跨专业思考是首先要解决的一点。

日常项目中，一个项目的原始沟通，要在彼此理解的前题下，非常明确地跨专业划分职责，比如让视觉和交互合一，有能力的设计师可以通吃交互视觉，交互承担部分简单的产品工作，产品承担简单的用研与分析工作，开发承担部分前端工作等等。跨专业明确分工，是敏捷的关键第一步。

除此之外，敏捷设计需要调整彼此协作的具体方法，这里总结几点：

晨会

各种kink off \评审会\沟通会在项目中会占大量的时间，但这些关键会议又在达成一致意见，大多不能省略，所以缩短会议时间、增加会议效率是必由之路，而短暂、固定的站立晨会是解决这个问题的好办法。站立晨会的时间控制在15分钟以内，只谈解决方案和核对进度，不展开讨论，有分歧的可以回后单独私聊达成一致，第二天晨会更新上来即可。

并行投入

为了敏捷起来，除了跨专业思考，理解上下游的承接方法，还必须并行投入，这是关键、并且会产生大量困难的一步。

所谓并行投入，最初沟通即要求技术、设计、产品都必须同时参与业务沟通，可以由产品或运营主导，来推动前期沟通，在这个步骤不仅产品自己理解了业务，更要让后续的技术和设计明白，产品之所以如此设计的原因和业务目标是什么，这样有利于后续协作同学更早介入业务，更早思考起来，从技术、设计角度帮助产品贡献创新思维，有时反而能事半功倍地达成所要达到业务目标。

并行产出

在产品规划阶段，ued根据业务需求，从用户视角开始前期用户体验模拟设计，并及时提供给产品、技术参考，技术根据业务需求产生技术基础解决方案，这种方案的前提是不依赖交互体验，纯粹从技术角度，按最佳技术路径来解决问题，提出解决方案供产品、ued参考。在此时，ued与技术均不用精耕细作，提供完整的大致解决方案即可，在设计中表现为“低保真的交互稿”。并且，这里的角色是互动的，产品、ued和技术提供方案的同时，也从协作方彼此获得对方的初步解决方案，并实时调整自己的对应方案，这是一个来回不断斧正的过程，最终的成果是——带交互设计的、在技术实现上论证可行的、有解决方案的产品prd。

这种prd推出时，技术和ued的进度都不会像以往那样还在0%的基础上等待，说不定已经万事具备，只欠f-prd这个东风了。

先进度，后体验

一个项目闪亮登场，当然是全部参与者的共同目标，也是最好情况。但是在大多数互联网项目中，因为要抢在某个时间点抢先发布，不断迭代、小步快跑是常态，这时设计师有必要调整好心态，同协作伙伴一起，规划体验还原度的时间表，让项目的进度不受到一些小细节上的还原度的影响，但又能保证某个时间点，体验基本实现一致。

比如可以要求一个项目进度中，在灰度测试时，实现60%的体验还原度，正式发布前实现80%，上线后第1-2次迭代后实现95%的还原度。这样的进度符合商业速度，也能在兼顾前端、开发同学的承受能力的同时，保证体验的基本水准。至于100%的还原度，那可能要过一个比较长的时间，甚至要准备永远都不会实现，因为互联网项目生命周期太短，更迭也太快，无法追求永恒的完美。

先进度，后体验，不是说放弃一部分体验，这里特别要注意前期的体验还原度时间表的严格规划，和后期的及时跟进，否则就会变成只有进度，毫无体验。

产出物

一般来说，协同作战容易误伤，不注意的话，一不小心就给自己合作伙伴挖了个小坑。所以大家的协同时，一定要先商定最后产出的形式，在上下游都能接受的情况下再协作。

首先，设计师的体验流程要与产品经理的商业流程一起产出，并及时核对，这一步基本就确定了大致的页面数量、交互路径，也确定了前端工程师在页面这块的工作量。所以，必须在体验流程图与商业流程图都要具备的情况下，并且这个流程是经过业务方确认的，才进行设计工作。

其次，除了并行产出的“低保真的交互稿”和“带prd的视觉稿”外，设计师应与前端工程师达成一个关键性的“合同”——前端在实现视觉稿时，把通用的部分，如按钮、输入框、弹出框等等组建，全部模块化，像一个个盒子一样封装起来，后续不仅前端不需重复开发，设计师不需重复设计，甚至能实现让产品经理自己组装页面结构，这对整个项目敏捷度的影响将是革命性的。

当然，搭积木一样的模块化操作，必然会对用户体验指数有一些负面影响，这里就要求设计师注重最后对最终产出物的验证，在上线前必须的用户走查，上线后可以通过真实用户测试、或者AB-test研究来检验模块化组装的页面，并由设计师做后续设计修正。

敏捷化的设计师

了解商业和技术

达到商用路径的方法，往往在专业上有好几条不同的路径，设计师理解了项目的商业诉求，更有利于找到一条对项目来说最合适的设计之路。

设计师大多数对商业规则和原理不感冒，对商业设计之类关注更多，现在提倡设计师了解商业也是流行话语，不过，商业这个名词太大，我们设计师究竟要了解商业的哪个部分呢？我的主张是从目前做的项目入手，先理解这些具体项目的相关的商业，比如项目目标和未来规划是什么？生命周期多久？影响项目的商业数据是哪些？弄明白这些，基本能保证设计方向不会有错。

跨专业的工作

大家的专业都是从学生时代就确立的，往往跟个人爱好、能力倾向有关。进入公司后，一般都会提倡复合型人才，你会的越多，解决问题的能力越强，最好几个不同的问题，无需再跑几个部门，找你一个人就解决了。然而对设计师来说这是巨大的挑战，视觉兼顾部分交互，要解决自身逻辑和结构化思考能力问题，交互兼顾视觉，则有美学培养的要求在。然而，这些能力培养是长期的，跨专业工作也不是要求培养通才，只是希望在原有的知识框架边上，做少许延展，方便上下游的接驳，当然，在紧急重大的项目中，更提倡有能力的设计师一肩承担，更能加快项目进程，节省大量沟通成本和转接项目的资源损失。

沟通与谈判能力

沟通和谈判能力中语言表述只是一个方面，更为重要的是对项目背景、上下游情况、商业目标的透彻理解，可以说台上一刻钟，台下十年功，一个对项目基本背景都不深入了解的人，是无法站在谈判桌上的，更不要提向对方推介自己的设计了。所以，沟通和谈判能力是建立在对项目深度理解的基础上的，设计师不应做没有准备的设计评审和讨论。

另外，注重对会议管理学习，通常沟通就时一场小的会议，沟通之前必须知道自己要得到什么（会议目标），可以放弃什么，底线在哪里，做好部分妥协的准备。

设计沟通时还有一个情况是，设计师需要发挥自己的优势，以图形化的方式直观的展现自己的见解，或帮助对方梳理清楚他的见解。必要时的写写画画，胜过千言万语。并且这个方法的好处是，设计师可以把用户需求直接植入讨论中，植入最终结果中，讨论的图像也可以作为一个存档，化解以后理解分歧，以备长期查验。

设计的敏捷化是根据互联网产品的日新月异的更新速度，新时代用户纷繁复杂的用户体验场景做出的设计方法优化，用于化解设计创意时间长，与项目商业需求紧急之间矛盾。很多资深的设计师都有一套自己的“独门秘籍”，大家可以在这个问题上展开多次专业讨论，以利于我们设计的最终成功。这里说的敏捷设计，只是一个引子。

作者：tomyidea

文章来源：站酷