行业关键字
UI设计UI理论和资料 → 正文
回顾我的UI设计之路
作者: 陈鑫 来源: 视觉同盟 时间: 2005年11月7日

缘起 The Genesis

之所以有这么一次回顾的原因是多方面的:
第一,在现在的项目中越深入,工作越往前推进,对于我所负责的UI工作有不少令人困惑的问题,让我亟需停下来回头反思一下;
第二,最近因为评职称的关系,要求写见习期工作小结,想想工作一年了,对于自己喜欢的这方面工作一直没好好梳理一下;
第三,看到视觉同盟做的UI大时代的专访,一篇篇看下来之后,结合自己的工作有蛮多感触的,于是就想把它们记录下来。

基于以上三方面原因,就有了这一篇回顾。尽管踏上UI设计这条路恐怕也只一年不到的时间,但是在这一篇文章里面,除了必要的工作历程描述之外,更重要的是希望发现现有工作中所存在的问题,以及对于自己未来工作的一个计划和展望。

UI之路 The Road

1.如何走上UI设计之路

大学里面的专业是信息管理与信息系统(这一点倒是和小林的专业一样的),当时基于专业原因认识更多得集中在数据库应用上面,虽然自己平时对平面设计有一点兴趣,但是一直认为自己的主业还是在程序上面,也根本就没听说过UI这个单词。

进现在这家公司也是以程序员身份进来的(就算现在的岗位定义还是程序员),公司的典型产品线就是数据库在医院信息管理中的应用,而我接触的第一个产品是一个检验信息系统,时值该系统开发升级版本,也许当时我按照程序员固有的思维专心去实现功能的话,我也就不会有机会走上UI设计之路了。

有时候自认为有点和自己的星座性格有关,因为有一点美学观念,又喜欢追求完美,而当时产品前一个版本的界面历经多个程序员开发,可谓是五花八门的风格,用色也是土得掉渣。于是在新版本开发中,我除了熟悉必要的功能结构之外,也颇花了一番心思在界面的设计上面。(现在想想,当处在学校里面做应用设计的时候也特别喜欢通过一定的GUI设计来美化界面,只不过现在回头看以前的作品,觉得还是蛮幼稚的)不过这部分工作在项目里面对于当时的我来说其实可以说是额外的工作,幸运的是,当时领导正好有心对于公司的现有产品界面进行规范化设计,于是在忙完检验产品的第一个阶段开发之后,我开始转向专职做界面设计,也因此正式踏上了UI设计这条路。

2.从程序员到UI设计的工作转变

现在回头想想,当初从程序员转向做界面设计也需要一点勇气的。

从一贯的认识来看,程序员总应该是对技术非常狂热的,从这个论断来看我的话,我应该不是一个合格的程序员。也许是因为专业知识的原因,我从一开始就认识到国内的软件更多注重在业务层面,特别是在数据库应用的行业软件领域,业务知识往往比技术来得更加重要。
或许正是因为关心应用的关系,我从一开始就没有表现出对代码的那种狂热,尽管在公司里面的主要开发工具是略显落后的PowerBuilder,但是我深深明白作为一家行业软件公司,业务积累才是其发展的基本。

但是,纯粹的界面端设计,不管是从技术层面还是业务层面,在大多数人眼里都是没有什么地位的。我想这样的认识还是存在的:做界面设计其实就是美工罢了,把界面画得好看一点就行了。从程序员这样一个有前途的岗位转而去做界面设计这样一个看似没前途的岗位,也许对于很多人来说会觉得难以理解,但是当时我还是毅然转向了。如果一定要分析原因的话,我觉得有两方面因素在:

一方面,和大多数软件公司一样,现在的公司以前是没有专职的界面设计人员的,除了必要的美工来负责软件的VI设计和图标设计之外,对于界面如何表现组织还是程序员的工作。在程序测试完之前,没有人知道这个产品整体是什么样子的,也根本不会有人去检验产品的可用性问题。

所以当时我的希望就是通过我的工作来提升产品的整体形象,同时能够表现出自己不同的工作价值。(而进一步关注到可用性和交互层面恐怕就是后话了)

另一方面,我觉得我之所以会去做UI设计,原因和小林说的一样,对于UI,从一点不了解,到感兴趣到专心做事情,再到希望自己获得更大的提高。我想我也还算是一个比较专心执著的人,对于自己感兴趣的东西,能够不断地去探索它就是最大的乐趣。所以很认同小林的这句话:“我觉得做一件事情就要单纯,热情,单纯可以让一个人专心,热情可以给事情以推动力。”

3.从界面设计到UI设计的理念蜕变

当初做检验系统的时候对于个人工作的认识恐怕还只是停留在界面设计上面,而第一次接触到UI这个单词而是来源于我们的美工所推荐的ChinaUI网站,虽然不得不说ChinaUI当时的主题(重在GUI)离我现在所理解的UI还有不小距离,但是却的确是ChinaUI把我领进了UI领域的大门。

其实就管理软件本身的特点来说,跟阿黎说的办公软件一样,同样强调“使用”,是完成工作的工具,关注的是效率,UI的设计偏向于简约。正是这样的设计风格决定了我一开始做界面设计的时候,会更多得从程序角度来考虑更多的可实现性,真正的GUI设计反而延续其一贯的辅助作用了。这个阶段里面,我更加关注在如何制订界面设计规范,统一软件界面的目标上面。(毕竟当初设立这个岗位就是这个目的)

但是,随着工作的深入开展,在和同事的交流以及具体的工程实施过程中,我开始意识到了一些其他问题,界面除了统一规范和美观之外应该还有很多东西值得关注,而这些东西是我们当时没有注意到的。谈论的时候也偶尔会冒出“可用性”这个单词,但是对于“Usability”还没有完整的概念。

给我的UI设计之路带来最大提升和转变的恐怕还就是UIG(UI Garden)了,在这里通过和大家的交流(鱼鱼,Ryana,白鸦,petpest,无名,Digi,第五传媒……等等),我对于UI设计的认识才真正扩展到了一个新的层面,完成了从单纯的关注界面设计到全面的考虑界面可用性问题的蜕变。

4.UI设计的规范化之路

从当下的实际情况来看,甚少有一开始就专门做UI设计的,大多数是从GUI转过来的,另一部分则是程序员的工作独立出来之后形成的,我想我正好属于后者。不管是前者还是后者,我觉得到了UI设计这条路,最需要关注的都是流程和规范。相对来说,做GUI设计的会比较感性,而写代码的更加理性,逻辑性也会强一点,可能后者在遵循规范和流程上更有优势一点。

一开始负责界面设计的时候,就比较注重规范性问题,也在参考业界某些设计规范的基础上完成了检验产品的界面设计规范,直至最后扩展成公司特有的界面设计规范。存在的问题则是因规范而规范,忽视了一定的可操作性。

当独立出来做UI设计的时候,由于在几个项目中都是中间插入的形式,所以甚少考虑到一个流程问题,而最后的操作下来结果也并不尽如人意。直到最近开始完整的介入公司的一个大型项目做专职UI设计时候,在面对项目的规范设计流程的时候,开始重点考虑UI设计流程的规范化问题。很明显的,如果直接套用其他公司流程的话无法符合实际情况,所以在搭建起流程框架之后还在继续摸索这样一个流程,而其间也出现了不少问题。

现有问题 The Problem

这里所说的问题主要是近期在公司一个系统级的项目中开展UI设计所遇到的,不过与其说是问题,更多的是困惑。

项目在UI设计上的现状可以认为和阿黎说的国内现状有所类似:

“按照国外来说,UI就是指界面设计,国内来说其实是把UI、UE (UE是usability engineer的简拼,可用性设计工程师)等方面都糅合到UI设计身上了,做UI要考虑交互,但是做UI不能把交互完全包容的,比如说一个项目的交互设计,UI人员可以去参与,程序员可以去参与,需求分析大家都可以去参与,最后定需求的时候是由产品经理去定的。消费型的小型项目来说,UI可以去定,对于系统级的项目不是UI这个角色能定的,而是产品经理组定的,目前像金山和微软都有专门的产品需求及策划组。对于UI和UE来讲是一种类似开发和测试的关系,可用性的分析和调查,都是UE来完成的。目前我看到很多UI设计师在聊天的时候,很多人在说做UI很痛苦,我不能去做交互,不能做UE,不能定需求,实际按科学的管理,需求、UI 、UE是完全分开的,大家还没有分明白。造成这个问题,应该是目前国内项目的管理对UI和UE的投入是不够的,所以往往把一个角色多重化。”

问题综合起来看,其实是人员不足和自身工作定位失准两方面原因。

在人员上,因为项目中只有我一个人负责UI设计工作,所以和UI相关的主要工作其实都落在我头上,而我也很想把这些事情做好。
而我的工作定位却也因此出现了失准,我过大的估计了自己的能力,我曾经设想在每个阶段做UI的都应该介入,从需求分析到原型设计再到可用性测试,但是实际情况是项目恰恰是一个系统级的项目,很多东西按照规范流程走下来远不是我能参与的。很多事情也会因为项目资源的限制和个人能力的不足而无法开展。

于是问题就演变成了我想做的事情太多,但是却做不了,自己给自己加了很大压力。

仔细分析一下问题产生的原因,我想我对于两个方面的认识还不够:

首先,UI设计不是一个人的工作。不管负责UI工作的人员有多少,在一个项目里面UI设计也需要配合其他设计人员来开展工作,在当前UI专职人员紧缺的时候,更应该考虑通过发挥设计组整体的力量来达到UI设计工作的目标。而且很多工作也并不是一个人或者一个团队能够解决的,就像确定交互设计原型这样的工作,UI人员要参与,用户专家要参与,系统设计人员要参与,并不是某一个角色所能主导的。

其次,结合实际情况,打造符合个人能力的UI工作。完整的UI设计工作应该包含什么内容这一点自己需要了解,但是在当前条件下什么能做什么还做不了也是需要自己明确的。罗马不是一天建成的,我也无法一口气吃成一个大胖子,UI设计之路与我来说还是很漫长的一段路,一步步来

未来之路 The Future

基于以上问题的分析,在UI设计的未来之路上有了不少新的计划和设想。

首先,结合专业理论和实际情况,对于UI工作进行进一步的细分,将包括以下四个方面:
1.用户研究
一般来说,用户研究的工作内容类似于产品策略:研究目标用户是谁,目标用户在设计方面喜欢什么,需要什么样的东西,用户的使用产品习惯如何等等。
从我们的项目来说,目标用户群相对比较固定,所以用户研究的工作职责将包括:采集用户使用需求,竞争产品的特点分析。

2.交互设计
交互设计的工作职责包括:系统的角色设计,参与功能原型的设计和编写系统交互设计准则。

3.界面设计
界面设计的工作职责包括:编写系统界面设计规范,界面风格设计,系统VI设计和图标设计。

4.可用性测试和验证
可用性测试的工作职责包括:负责并组织原型的可用性测试,发现可用性问题并提出修改意见,组织试点过程中的用户验证。

然后,基于以上的工作内容,对UI设计人员划分出如下分工:
1.UE:可用性设计工程师
负责用户研究和交互设计两个部分;

2.界面设计师
负责界面设计;

3.可用性测试
负责可用性测试和验证;

4.UI设计负责人
对于UI设计工作整体进行统筹规划。

如果按照如此分工的话,发现我还真的是身兼数职呀,UE也算,界面设计师也算,说负责人也可以说(只不过是个光杆司令)
但是,前面也说了,UI无法由一个人来完成,除开和项目的配合,同样需要一个有效的团队来完成工作。而对于我自己来说,我希望首先还是专注在UE层面,重点关注于可用性设计上面来开展工作,一步步得将其他一些工作分担开去。虽然还无法做到像小林那样建立起一支完整的UI开发团队,但是那是我的目标。

当然了,UI设计在传统软件行业中,特别是一对一的项目型软件中还无法起到更加决定性的作用,但是其还是可以有所作为的。就我现在所处的医疗信息系统行业来说,在国外其实也已经有不少的可用性优化案例,而我也希望通过自己的努力能够先将其在公司内部推展开来。

更多文章请访问视觉同盟UI大时代专题

(责任编辑: fape

作品欣赏

欢迎关注视觉同盟微信公众号:
微信公众平台:搜索“vudn2004”或扫描下面二维码:
English | 关于我们 | 站点地图 | 联系热线 | 合作伙伴 | 艺术顾问 | 订阅 | 手机版
版权所有 © 2004-2024 视觉同盟 visionUnion.com)
Copyright © 2004-2024 VisionUnion.com Incorporated. All rights reserved
京ICP备09005192号
视觉同盟旗下子站:品牌专区 | 创意设计人才网 | 视觉同盟社区 | 视觉同盟论坛 | 英文版