UI/UX 设计师在小团队内的工作流程

July 09, 2015 / leiwaa

工作时间也不短了,一直在一个不大的团队内当设计师,也慢慢摸索出了一套适合当前团队的协作流程,由于团队不大,而且目前只有自己一人负责设计方面的工作,所以流程中的部分细节可能并不一定适用。

1. 需求确认

从拿到 PM 的需求文档开始。除了了解需求外,通常还会找出需求不明确或者细节缺失的地方,以及对具体的需求内容提出自己的想法或者建议。需求的细节会直接关系到之后设计能否顺利进行,如果没有查漏补缺,实际设计过程中再一个一个的发现问题就很麻烦了。在对完需求之后还会在整个团队内一起过一遍,确保没有问题遗漏,确保大家对需求的理解是一致的。

2. 设计基调确立

需求确定下来之后,具体的设计工作之前,会根据产品的定位以及目标用户确立一个整体的设计基调与原则,类似一个风格指导,在后面遇到疑惑或者方案选用有争议时,这就是决策的依据。这一个环节可能与常规作法并不一致,由于分工、xx等问题,常见的做法里设计风格的确立这一步骤通常是在视觉设计时进行的,尤其是特指视觉风格,而这里的基调指的是在视觉风格之上的、当用户使用 APP 的时候对 APP 产生的整体印象,例如简洁、活泼这样的风格当然也需要在交互上体现出来。

3. 草图、原型

接着是构思主要功能的交互方式,通过纸笔草图快速表达,部分草图难以体现的功能与交互方式会通过可操作原型的方式表达,有时候也需要找内部外部的人做一下调研或者测试来验证想法是否可行。在此期间,会定时的与 PM 等主要负责人讨论,确认,当然,这是一个频繁的、来回的、多次的过程。

4. 线框图

当主要功能的交互达成共识之后,需要在电脑上把所有页面的线框图与跳转流程画出来。待大多线框图都设计出来之后,会在团队内再次评审,讨论,修改定稿。

5. 视觉设计

把线框图确定之后,开发方面此时一般也会由技术调研等工作切换到实际的功能开发,等到视觉设计完成后开始界面的开发。由于在交互设计之前已经确立了一个整体的设计基调,所以在视觉设计时并不需要再次设定,通常以简单的 MoodBoard 以及「关键页面视觉样稿」的形式达成共识之后就可以开始详细的页面设计。因为前面的交互也是自己做的,所以很大一部分的分类的控件,复用的样式等在交互阶段已经有规划与准备了,所以做起来相当流畅,另外视觉稿也不一定会全部画出,一般会将主要的页面画出,然后整理出一套 UIKit 。部分页面由于可以直接通过 UIKit 以及 线框图表达,例如包含一个基本的 ListView 的「设置」就不一定会画出来。完成视觉高,之后便是切图标注了。

6. 动效与原型

视觉设计完成后,视项目具体情况而定,有时还需要把一些无法表达出来的动效与效果通动画或高保真原型的形式表达出来,为开发提供参考。与静态效果图的尺寸标注一样,动效也需要参数去描述,easings.net , cubic-bezier.com 等网站提供了很好的参考。

7. 跟进界面实现

尽管现在也有了 Zeplin 这样的神器,但实际过程中仍然会有很多的问题导致最终的界面与效果图的差距,这个时候就没办法了,只能和开发协调时间,搬个凳子坐到旁边,把元素间不对的间距,字体过大的行距,少了个回弹的动效一次干掉。

8. 验证与迭代

产品上线之后,收集用户反馈,以及查看 APP 内埋点的(尤其是用于验证当时有争议的设计方案的埋点)的数据,验证设计,也为之后的迭代提供支撑。

9. 总结

总结的重要性相信大家都明白,事实上我在总结流程、写下本文时也发现了一些在没写之前根本没有发现的问题。项目中遇到的了什么问题,技术细节等问题需要如何解决?后期如何避免类似的事情发生?另外,如果是等项目结束后才总结,很多问题可能已遗忘,一个比较好的作法,是项目开始阶段,即建立起一个随项目而动的文档,项目进行中时遇到的问题与想法随时记下来,后面总结时再统一整理。

本文采用 Creative Commons BY-NC-ND 授权,转载请注明出处

Comments
Write a Comment