敏捷设计,让设计更高效

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

1a0

为什么要敏捷

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

而对于企业来说,运营的效率是性命攸关的事情,时间就是生命。说到底,生存在社会中的设计师无法不受商业规律的影响,无法超脱世外地艺术化生活,也就说同任何工作一样,效率和质量也是设计师必须面对的、永恒的难题。

作为在广告创意公司工作过的设计师来说,加班永远是主题,我曾经有过三天三夜不睡觉,设计一本书,被抬上飞机的经历。踏入互联网的领域后才发现,命是天定的,人性化的bta企业也有那么多的加班。对于像设计师这种习惯创新的族群,自然地会寻求,天底下是否有一条撒满鲜花的舒适坦途?企业则也会去思考,有设计参与的项目是否可以一样敏捷高效?

在深圳工作的这6个多月里,我们同技术、产品等伙伴尝试了一种新型的工作方式,这种工作方式令我们在1个月的时间里,完成了通常需要3个月、甚至需要更多时间花费的工作,同样的高质高量,同样的快乐活泼。这种方式我们暂称“敏捷设计”方法。

这种敏捷设计方法的是挑项目的,因为它需要更早地规划好项目日程,且配合的团队需要结构稳定、预留好想对固定的资源。我们无法让一个个朝生夕灭的临时项目系统化地敏捷起来。

且敏捷设计的参与人员要有创业精神,不纠结于流程和职位级别,一切以推动项目进展为准则。

2w

敏捷的方法

跨专业明确分工

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

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

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

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

晨会

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

并行投入

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

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

并行产出

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

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

先进度,后体验

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

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

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

产出物

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

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

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

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

w356

敏捷化的设计师

了解商业和技术

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

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

跨专业的工作

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

沟通与谈判能力

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

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

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

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

作者:tomyidea

文章来源:站酷

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中