如果通过组队接设计外包学习这4个经验

UI / UI设计教程 / UI教程 /      

uimaker
UI设计师 / 江苏 南京

来源:jianshu   作者:Yeah秋强

关键词

这段时间和朋友接了一个设计外包项目,我是交互设计师,其他两个负责视觉设计,第一次组团队,无论团队内部还是合作公司那边,都是边磨合边工作,进行不是很顺利。磕磕碰碰做完后,回顾这次项目经验,有4点经验想跟大家分享一下。

一、项目需要一张数据表

这次算是一个全新的项目,从零开始,但是实际上第一版出来的功能已经非常多了。产品那边没有一个完整的功能列表给我,需求也是时不时进行改动。所以,在做设计的时候,总感觉会遗漏某些状态的变化,所以,针对这一点,我觉得可以有一张数据表。这张表就是工程师后台的数据记录,产品在规划功能的时候就需要把这张表格给罗列出来,然后在设计交互流程的时候,每进行一个步骤,都需要考虑这个步骤对于这个数据表格的影响,然后把这些变化完整地写进交互文档里面。

举个例子,由于我们的平台是一个优惠券发放的平台,那么这个时候涉及到两个主体:优惠券和领券的人,优惠券的数据就是一个数量的问题。不过对于领券人,数据表有如下:1、未使用的券;2、已使用的券;3、已过期的券;4、待付款的订单;5、已付款的订单;6、已退款的订单;7、积分;8、返利。

罗列了一下,这些是最主要的数据,然后比如说订单的数据,因为订单是进行购买优惠券的活动的,所以订单的数据也会影响优惠券的数据。优惠券消费会有返积分或者返利,所以,优惠券的状态也会影响积分或者返利的数据。那么也就是说订单的变化也会影响积分或者返利。这些数据之间关系错综复杂,如果有一张详细的表格,可以把这些变化写进交互设计文档里面,我觉得逻辑会更加完整,对于开发人员来说也比较便捷。只是可惜,这些都是做完了才发现的,所以当时就没有做。

如果通过组队接设计外包学习这4个经验

二、将功能模块化

这次的项目是我有史以来接到的最大的项目,项目功能比较多也比较杂乱,特别是后期加入了一个支付功能,导致整个交互逻辑的复杂度大大增加了。复杂度变大的坏处有三个:①难以梳理逻辑;②容易遗忘一些逻辑;③难以恰当地阐述设计。针对这三个缺点,我在做的过程中尝试将功能进行模块化。模块化的意思是将一些功能进行打包,然后只梳理这些功能之间的关系。梳理完之后,这些功能就形成了一个整体,然后其他功能只和这个整体进行交互而不和其中的功能进行交互。

这么说有点不形象,举个例子吧,就说电脑吧,电脑可以看成是由显示器、CPU、内存、硬盘等部件构成的,而其实显示器里面又是由各种零件构成的,显示器里面的零件就相当于我的功能,我所做的就是先把一部分打包成“显示器”,一部分打包成“CPU”,然后把他们当成一个整体来考虑。

显而易见就是,这么做首先每次处理都只是一部分问题,逻辑比较容易梳理,也不容易遗忘逻辑。当然,更重要的就是表达的问题。如果不进行模块化的话,我真的不知道该如何在一张画布上把这些逻辑流程表达出来,所以,模块化之后,我可以在每张画布只表达其中一个模块,当我把所有模块都阐述清楚了,整个项目也就清楚了。

当然,除了以上的种种优点之外,模块化还有一个优点就是方便复用。一些常见的模块,比如注册登录模块,消息通知模块,个人中心模块,这些模块在当今的APP里基本都存在,也就是说他们的复用率都比较高。如果在设计的过程中就已经将这些功能进行模块化了,之后如果需要设计新产品的功能时,这些模块就可以直接拿过来复用,省时省力。这个省时省力节约的是功能规划、界面设计、逻辑推演等等这些时间和精力,所以还是相当可观的。

如果通过组队接设计外包学习这4个经验

三、定义公共交互

如果说前面的模块化是为以后的设计做准备,那么公共交互这一块其实就是贯穿整个设计的过程。在做设计的过程中,其实会发现很多小流程的处理,之前已经做过了,做过了我当然不会再画一遍,再写一遍逻辑,我一般只会写“此处XX逻辑参考XX页的XX图”,不过慢慢地,这些一多,就发现自己也会乱掉。当出现次数超过四次时,我就每次写那句话都有点不太放心,怕自己引用的那个地方也是缺省的,所以每次都要把交互稿翻一下,然后才能信心满满地写下这句“此处XX逻辑参考XX页的XX图”。

碰巧之前在一家公司遇到过他们的交互稿,一个公司的产品那就是相当复杂了,所以他们会把一些公共的交互给罗列出来,放在交互稿的前面部分,然后每次引用的时候就是引用公共交互的东西。我觉得这个可以借鉴到小项目的交互稿里面。也就是说,交互稿除了一开始的说明以及后面的线框图之外,中间再加入一张画布“公共交互”,然后把所有出现过两次以上的交互都可以总结到这张图上,这个公共交互当然是自己一边做一边维护的,不过想来,这样子做,既可以保证自己画图的质量和效率,对于开发来说也是很有裨益的吧。

一些常见的公共交互有:删除操作、编辑操作、分享操作。只要把这些操作流程在公共交互里完整地写一遍,后面的就可以大胆地复用这些公共交互了。

如果通过组队接设计外包学习这4个经验

四、沟通方式

正如我一开始说的,我们是一个新的团队,大家彼此之间都没有合作过,也不清楚各自的工作方式,导致在设计过程中会暴露出很多问题。我是交互设计师,可能对于整体的把控会更加良好一些,视觉设计师天生比较浪漫主义一些,所以一些事情需要我为他们考虑到,如果没有考虑到,他们可能就会耽误项目的进度。

说两点在沟通方式上出现的问题,供大家参考一下。

第一点出现在进度安排上,在我做完交互稿之后,发现页面的数量大大超出了预期,结果他们一听到就开始信心大受打击。虽然我一直反复跟他们说,增加的页面都比较简单,但是他们完全都听不进去,直到后面他们两个人的分工出现了问题。所以这时候我就只能跳出来做协调人。首先当然是统计页面的数量,,然后给页面分级,分为“主-次-送”三个等级,主要页面当然是比较复杂的页面,次要页面是简单页面,考虑到有一些页面实在太简单了,就当作赠送给公司的。分级的好处就是,他们对于项目的难度有一个较为良好的认识,压力没有那么大。然后我根据他们的工作能力(一个工作经验较为丰富,另一个经验稍显欠缺)、剩余的时间以及他们之前的协商结果,把整个计划表表做出来,计划表一是可以方面地查看进度,更加重要的是对视觉设计师的一种“束缚”,束缚他们的浪漫主义。所以计划表一出来,整个项目才得以顺利实施下去。

第二点出现在成果交付上,首先就是他们的视觉稿。他们习惯用Photoshop作图,然后也比较随性,随性的结果就是虽然界面看起来很干净整洁,但是图层的管理就一坨shit,各种“组1”、“图层1”、“方块1”的命名层出不穷,外人根本没法看。你要问为什么这会是沟通的问题?因为我也要审核他们的视觉稿,有些小问题我自己就改掉了,但是面对这么杂乱的图层结构,真的是没什么改动的欲望。

接着,就是视觉稿PSD的命名了。我在做交互稿的时候已经将功能模块化了,每个模块都会有各自的命名和编号,注意这里的编号才是最重要的,因为可以方便地回溯。但是他们在命名的时候恰恰忘了把这个编号加到每一张PSD上,所以后面整理的时候出了纠纷,还是在我的强烈要求下,他们才全部改了一遍。然后是这么一堆PSD文件,不可能就随便打个包吧,至少按每个模块建立一个文件夹吧。然后如果PSD文件有改动,要怎么命名吧。这些问题都是一开始没有想到的,也没有协商好,结果导致合作上出现了问题。虽然都是小问题的,但是这些都是会在项目的末尾暴露出来,说实话,影响最大的其实是心情,真的是心好累。

 收藏