参加大型项目时,设计师应该学会的最优工作流程!

2016-10-19    周周

如果您想订阅本博客内容,每天自动发到您的邮箱中, 请点这里

咚咚咚:前段时间参与设计一个较大的线上活动,包含十个奥运相关小游戏及一些相关界面,前后历时几个月。奥运后活动下线,设计工作完结后,我整理了这过程中的收获及工作方式,和大家分享下。

立项前信息收集与准备

有些大型项目是很早就规划了要做的,只是具体哪天立项发邮件或哪些人参与还没确定,如果知道要自己要参与这件事,可以做些准备工作,提前了解一些信息:

  • 项目人员。了解各个职能的接口人是谁,运营、产品、视觉、前端、后端、测试等有谁参与,有些人可能之前都不认识,大家的工作方式和性格也不一样,提前了解认识下,对后期合作和方案推进会有帮助。
  • 信息。保证自己了解到的信息是一手资料很重要。和各方沟通过程中收集下项目的背景、目标、投入的资源、方案的思路及活动体量、以及可能的用户利益点、项目时间点(通常deadline是确定的)等等等等。这些信息可以通过产品和运营了解到。如果是公司的例行活动,能够拿到以往活动的数据和资料当然是最好,如果没有的话也尽量找到以前做过类似活动的人员了解一些前人的方法和经验。
  • 别人的想法。项目组人员总会有自己的想法和方案,有时候甚至方案是比较确定的。尽早的了解到产品或者运营的想法可以预估个大概的时间节点和需求,做到心中有数。如果有好的想法这个时候提出来也最容易被采纳,毕竟时间上一切来得及。

立项时信息确认

从接触到正式立项这段时间免不了会有些因素变动,当然也有确定下来的,确定的东西越多对设计做规划也就更有帮助。

  • 确认人员
  • 确认目标
  • 确认方向
  • 确认时间
uisdc-ep-20161018-3

控制节奏

项目启动后是不可能立马有方案的,但是项目的目标和方向通常是有的。基于当下的目标、方向和资源是可以安排工作节奏。

  • 拆分任务。拿这次奥运活动来说,项目立项后知道的是要做大概十个游戏独立售卖,然后整个活动期间要为客户端拉新。所以思路是先总后分,先将活动架子搭建起来,考虑如何整体包装这十个游戏,然后再分别设计每个游戏。
  • 排优先级。根据拆分的各个任务模块考虑设计的先后顺序。大项目不可能同时设计,一次性输出全部的设计方案,时间上一般是来不及的,所以只能分批次设计输出。这样还有一个好处是,在一部分设计确定输出后,项目的其他人员也能够尽早的展开工作,不用等全部设计输出就可以动起来,项目时间上更加充裕。
  • 时间预估。设计任务安排好后需要给自己设定个大概时间点,到什么节点输出哪一部分内容有个规划。一是督促自己快速思考有效产出,二是保证项目整体时间可控,减少风险。

方案设计

具体的方案设计是个比较长的过程,可以用的方法也很多,每个人通常也都有自己的方法。这个过程中会出现很多的争执,有一点很重要,在围绕着某个细节争执不休的时候,要记得跳出来想想项目的目标是什么,很多争执点在放回项目目标这个点的时候,答案往往就清晰了。此外还有以下几点体会:

  • 方案共建。想法谁提出的不重要,有好想法才重要。当没有好想法的时候可以拉上项目组其他成员一起脑爆,大家坐下来一起讨论出来的方案往往推进起来异常容易。
  • 更好的方案。时刻提醒自己,除了眼前这个方案一定还存在一个更好的方案,时间允许的情况下不妨再逼自己一把,这个过程很痛苦但是结果往往也很令人满意。
  • 统一布局。虽然这个活动包含十个游戏,但是可以根据每个游戏的特点抽离出一些共性统一来设计。比如我的做法是将页面分为了三块,顶部统一放成绩相关的元素,中间为游戏主画面,底部防止操作相关元素。然后在这样的布局原则下针对每个游戏设计。这样一是可以给用户树立较为统一的认识,体验一致;二是可以提高设计效率,同时也没有对某个做出细致的限制,不影响单个游戏的创新空间。
uisdc-ep-20161018-2

方案输出与跟进

交互评审完毕并不表示设计工作就结束了,后续的跟进与走查仍然属于设计的一部分,而且很重要。

  • 查漏补缺。即使再有经验的设计师也不可能把所有的情况都考虑到,所以开发过程中补充一些细节是正常的,但是这种情况越少越好。前期考虑清楚规划好和临时打补丁效果肯定不一样。心态很重要,态度也很重要。
  • 保证设计还原度。交互评审后仍然需要不断的跟进视觉设计和后续的开发,除了了解项目进度外,还有一个重要的原因是通过不断的沟通保证你的设计方案是被充分理解并被严格执行,否则难免会出现因为误解方案而造成上线效果打折情况。关键词,推动方案落地。

数据埋点与测试

做完一个项目如果只是增长了一些项目经验是不够的,我们还需要知道我们的经验是对还是错。所以对方案的验证和数据收集就非常重要了。

  • 真实的用户测试。并不是每个项目都有时间和资源进行用户测试的。但是如果有时间的话,能够进行一次真实的可用性测试绝对是值得的。这也是解决方案争议的一个有效办法。我们不可能完全了解我们的用户,而且设计过程中与其他人的pk也不会每次都胜出。在我做的这十个小游戏中,上线前用了一周时间借助用研找了十几个真实的用户进行了测试,结果发现对其中两个竞猜的游戏用户比较方案,而且会影响到对整个活动满意度。最后经过慎重考虑还是忍痛砍掉了一个,并对整个活动其他部分做了一次优化。
  • 数据埋点。数据能很大程度上反映一个活动的效果,通常运营和产品也都会督促前端的同学进行埋点。但是不同的角色看的数据指标和范围不一样,如果要检验设计的好坏最好是设计将需要埋点的地方单独标记出来输出给前端,以便后续的整理和总结。

活动总结

活动结束后及时的收集数据,并分析总结。趁着对活动还有印象,通过数据分析自己设计中哪些地方做的合适,哪些地方做的不合适,总结经验和教训。至此一项比较完整的活动设计算是结束了。

日历

链接

个人资料

蓝蓝设计的小编 http://www.lanlanwork.com

存档