为什么网页设计不应强调分工 1

| 13 comments 2008-12-15 12:22:49

JunChen在最近的一篇《为何XHTML原型会失败》中说出了一个实质问题,即在快速变化的互联网公司中,非XHTML原型只是“看上去很美”而已。

究其原因。除了JunChen提到的“难以维护”以外,对设计和开发人员精力的消耗也是一个重要方面。

让我们来看一个典型的流程:

  1. 用户研究员进行用户研究,根据结果编写了研究报告(比如角色模型和使用场景);
  2. 交互设计师按照用户研究报告,设计了线框图;
  3. 视觉设计师拿到线框图,和交互设计师讨论并沟通后,进行视觉设计并输出高保真视觉原型;
  4. 前端开发工程师拿到视觉原型,在和交互设计师及视觉设计师沟通后,进行编码工作,输出HTML文件;
  5. 用户研究员开始可用性测试,并将问题反馈给交互设计师;
  6. 回到第一步,直至用户研究员(或其他的什么人)认为质量合格。

这一看似合理的流水线作业存在什么问题呢?让我们来仔细分析一下:

1. 困惑的交互设计师

用户研究是一个渐进式接近真相的过程,其结果不可能一步到位。尤其在研究初期,哪些因素会对产品设计有较大影响,哪些因素实际无足轻重,这是没有办法事先准确预估的。这就造成当交互设计师在依照研究结果设计时,发现研究结果不能给自己的设计以有力的支撑。

比如,当两种交互方式都可以达到同样目的、而从已有的数据中又无法判断用户会喜欢哪种时,交互设计师就会犹豫不决。从资源的角度来考虑,请研究员再一次制订计划、招募用户并实施研究,是不太可能的;更不用说设计两种原型并分别测试了。因此此时交互设计师只能依据自己的经验,或者进行押宝。

此外,交互设计师还面临一个颇为尴尬的问题:由于处于流程中的中间环节,缺少坚实的硬性产出,他很难、甚至没办法证明自己的工作价值。一方面,交互设计是一种偏“软”的技能,它目前没有、将来也很难产生一个标准化的量尺来考量其自身的质量。可用性测试可以做到部分量化,比如完成时间、出错次数等,但十几个人(一般甚至更少)的数据在统计学上是没有任何意义的。而且,有多少用户能理解那种低保真的原型呢?另一方面,就算用Axure等软件制作可操作的原型然后拿去做测试,各个业务部门会相信测试结果么?没错,你可以强硬一些,比如采取“如果业务部门不参与观察测试,就算自动放弃决策时的发言权”这样的办法,可这只能说你有工作方法,这实在无益于专业技能的提升。而且有多少设计师可以强势到让所有的业务部门闭嘴的?

实施社会分工的目的之一,就是实施标准化的作业。而当流水线中某一环节的产出物质量,是随着其作者的经验而变化时,也就是说质量并不能定量控制时,分工的意义就不复存在,这一生产方式也就不可能按简单复制的方式扩张规模。

2. 交互、视觉和前端间的沟通成本,和可能的不愉快

在交互设计师和视觉设计师交接工作时,沟通不可避免。视觉设计师要充分领会交互设计师的意图,这需要沟通;反过来视觉设计师给交互设计师的线框图提意见,这也需要沟通。尤其在整个部门缺乏UI规范时,沟通成本可能会高得吓人。比如交互设计师认为某处需要用3级标题(比如h3),到了视觉这里直接用了一行红字。所以常常觉得“有那时间费力沟通,还不如直接改了算了”。结果改完了交互设计师心里会想“你怎么也不和我打声招呼就改了”,不愉快就这么来了。

到了前端开发那里,问题就更复杂了。首先,前端开发需要实现所有细节,而出于资源上的考虑,这些细节未必都会由交互和视觉设计师的产出物覆盖到(比如同一页面上仅有一处文字有微小变化,那么线框图和视觉稿要分别做两份吗?),那么前端开发就需要经常和前面两者沟通;其次,如果前端开发发觉设计稿的实现难度或成本太高,那么情况就更为棘手,最麻烦的莫过于要重新设计交互原型。

当然,上述问题基本都能靠沟通解决,问题是,你愿意花多少时间去沟通呢?从这个角度来说,敏捷开发的沟通成本是最低的,因为沟通就是产出。而反过来上述流程的沟通成本很高,因为沟通是用来解释产出的,是产出成本之外的“额外成本”。

3. 瀑布模型与生俱来的缺陷

上述流程是一个典型的瀑布模型,一旦在可用性测试阶段发现问题,就需要重新再走整个流程,其效率之低可想而知。此外,由于涉及到的环节和人员不少,流程走得次数越多,出问题的机会也越多。最常见的是各个环节的产出物版本控制困难,甚至根本没有版本控制,结果往往造成项目组中每个人拿到的产出物(如Demo)都不一样,这是一个非常可怕的风险,会给项目过程和质量带来非常严重的影响。

我对这个问题采取过“文档管理+版本控制+减少分工”的方法,效果很好。这个后文会阐述,这里先不展开。

4. 无技术含量可言的重复劳动

在一些页面调整不大的日常项目中,交互设计师用2小时做的原型,到了前端那里可能半个小时就把HTML搞定了,如果用CSSEdit那样的工具,实现过程甚至更快、更惬意。那么,为什么要把原本一件很小的工作硬生生地拆成两部分来做呢?

举一个非常常见的例子:业务部门提需求说要改某某宣传文案,如果按照上述流程,交互先做线框,给到视觉确认,然后到前端修改,往最快了说也得半小时吧。而若交互设计师直接改HTML,十分钟搞定。

有人说找到相应的模板还要时间呢,这好办,做个可搜索的模板库就好了。我们曾参考DocBlock规范做过VelocityDoc,效果很好。

5. 破坏了网页设计工作本身的美感

网页设计是技术和艺术的结合,一个优秀的设计师不仅大量吸收传统的设计知识(如平面设计),更懂得如何利用合适的技术去带来艺术上的创新。这个过程是相辅相成的,硬性拆开只会限制设计师的创造力。

这就好像搞油画的必须要掌握不同染料和画布的性质,搞雕塑的既要有创意又有能动手(你能想象出一个雕塑家只管创意而从不亲自去实现吗)一样,使用技术来展现艺术,借助艺术去探究可能的技术。

据说Apple的工业设计师都要清楚地理解各种材料的特点的,如果只让他们画图,Unibody这样的杰作又如何诞生?

 

说了半天问题,下篇中我们来看怎么解决。

13 comments so far

  1. taine 2008-12-15 20:41:30

    说的都没错,但至少有两个前提:

    1 其中的每个人都是高手,比如既能写代码,又能做设计;

    2 每个人对问题的理解基本一致。

    光第二条就不可能,很多时候问题理解不一致,并不是谁理解的不对,而是站得角度不同,得出的结论就不同,沟通难以避免。小型项目,身兼数职还行,大型项目绝无可能,大型项目业务需求太多,谁有那个精力能把所有业务需求都看一边,都理解一下?

    “比如交互设计师认为某处需要用3级标题(比如h3),到了视觉这里直接用了一行红字。所以常常觉得“有那时间费力沟通,还不如直接改了算了”。结果改完了交互设计师心里会想“你怎么也不和我打声招呼就改了”,不愉快就这么来了。”

    这纯粹是权责不明,就是你说的UI没有规范。所以流水线反而不能发挥作用。

  2. 丁宇 2008-12-15 21:35:02

    其它都没问题,唯独“大型项目业务需求太多,谁有那个精力能把所有业务需求都看一边,都理解一下?”这句没看懂。

    我理解你的意思是,大型项目工作量很大,一个人从头做到尾太累。如果我理解没错的话,这个和我的方法完全不冲突的-既然项目够大,那就多安排几个人从头做到尾,哈哈。glasses.gif

    哦,此时别忘了在这些设计师里面,也要有人来做管理,此时就是用户体验架构师发挥的时机了。

  3. 丁宇 2008-12-16 13:41:24

    不知有多少朋友无法留言?

    SPAM防火墙是我自己写的,现在的过滤规则比较严格,遇到可能的SPAM一律阻止发表,而非将其标记为SPAM。我会尽快完善这部分设计。

    这条留言既为说明,又为测试。

  4. taine 2008-12-16 13:48:54

    ask.gif

  5. 丁宇 2008-12-16 14:00:26

    哈,刚才千鸟来信说他的评论被挡住了,所以特此说明一下。

    以下是他的评论内容:

    关于此问题实践有部分心得,欢迎参考。

    互联网设计瀑布递推

    http://blog.rexsong.com/?p=2633

    互联网设计敏捷迭代

    http://blog.rexsong.com/?p=2365

  6. 蹲在街角狂笑 2008-12-16 14:06:22

    这些问题确实困扰,说实话真不觉得应该分工太细致。

  7. 蹲在街角狂笑 2008-12-16 14:07:50

    为什么我的头像不见了?难道是邮箱留错了?wave.gif

  8. Aaron.Liu 2008-12-16 15:08:18

    你好!博主,可以留一个msn或gmail的联系方式给我吗?

    我这里不能访问邮箱,我想请教你一个userbility的问题ya!多谢!

  9. jean.ma 2008-12-17 11:25:12

    个人认为在大部分企业里,都很难做到如此细的分工。我所在的企业,目前最多分两人做,一人做交互一人做实现,就这样两人的合作团队里,即使是明确了权责、并讨论确认所有的细节,实现出来的东西都会有差异。第一:同样一句话,不同人的认识不同、理解不同,有些时候即使已经确认含义,也不代表真正达成一致。第二,每个人沟通都有自己的局限性,难免会有信息传递的失误。一个人完成某种角度上确实是会减少这部分的成本。但部分大项目需要合作的,我认为,多人合作的团队,可以考虑设计与实现部分可以由一个人全程完成,任务已模块化的方式分配给不同成员。团队成员互相测试,以评测设计的合理性与有效性。一方面减少沟通的成本,另一方面又可以避免一人进大项目无法应付的局面,同时每个人的权责变得更加清晰。

    不清楚,国内有多少公司严格安装标准化的方式来进行软件开发,如何定制与协调不同角色间的衔接,说实话并没有很深刻的认识。个人觉得,方法合适团队最重要。一个大项目经理同我说过一句话,在大项目里,如果你的精力有限,而事情有很多,那你应该抓住最核心的部分去坚持、完善,有些时候可能只需要坚持那几个点,项目就算是成功了。呵呵扯远了。。在我处的公司的现状,我同意心弦gg的合并做法。

  10. Cynthia 2008-12-20 14:57:07

    很有建设性的题目,我设计,困惑,沟通...累了,也许就不沟通了...也许很多工作确实不需要分那么细,但其实还是需要,看管理的了吧...

  11. azero 2009-01-14 17:26:50

    这看起来是个有趣的话题。。

    如果不分工,那么我想至少在管理上会出问题。

    比如,前端把交互的某处细节无视了。

    角色是交互时,我能构想出许多能够实现且优美的交互。

    角色是前端时,我本能地有些拒绝着某些交互的设计,因为它导致我需要一大堆臃肿的代码。

    事实上,观念、时间、成本才是个问题。

    如果有较好的观念(我YY的前端懂交互、交互懂前端),能把产品当成自家孩子一样,我想,在足够的时间做出成本控制合适的产品才是高效的。

    分工,细化了,有句话叫专业的人做专业的事。

    不分工,效率也许提高了,但质量这个难说。

    所以,分不分工,要看企业,要看项目。lang_2.gif

  12. 丁宇 2009-01-14 23:20:18

    @azero: 其实你举的例子和分工与否没什么关系,而是工作态度的问题。即使有分工,前端在面对一个需求时,同样可以选择对他来说成本最低、但对部门来说成本较高的实现方式(最简单的,把js/css写在html里)。我不完全反对分工,你让交互设计师成天搞gmail/bindows的前端开发,这显然也不符合实际。只不过对于一些(可能是大部分)公司来说,不分工比分工好。另外我标题里面也留余地了-“不应强调”,呵呵。big_smile.gif

  13. lightsaber 2009-11-25 12:13:16

    我认为分工也是需要的,不过不同分工的人,需要加强自己的素质和能力。

    理由要写出来,就一大堆了,呵呵。

    有空和你讨论,反正我们都在上海,上次活动那天我们聊过。

    angel.gif

(Support Gravatar)
  • angel.gif
  • glasses.gif
  • hum.gif
  • sad.gif
  • caresse.gif
  • sick.gif
  • angry.gif
  • zip.gif
  • gun.gif
  • emu.gif
  • big_smile.gif
  • clin_oeil.gif
  • devil.gif
  • wahou.gif
  • confus.gif
  • mad.gif
  • larme.gif
  • wave.gif
  • scare.gif
  • lang_1.gif
  • ask.gif
  • xd.gif
  • eye_up.gif
  • mdr.gif
  • smile_1.gif
  • lang_2.gif
  • zzz.gif
  • bad_smile.gif
  • jet.gif
  • smile_2.gif
  • love.gif

About

我在厦门拍的照片

丁宇(Felix Ding),电脑Geek,狂热的爱书和爱乐分子,99年迷上网页设计,并从此一发不可收。现在在上海做用户体验/产品设计咨询。Email: felixding[AT]gmail.com。

订阅到RSS