最火下载站首页
手机版
最火下载站
关注公众号
最火下载站

当前位置:首页 > 网络知识 > Web前端 > 工具与技巧> 网页设计不应该分工的原因及解决办法

网页设计不应该分工的原因及解决办法

文章作者:网友投稿 发布时间:2008-12-23 来源:网络

  烈火建站学院(LieHuo.Net)网页制作心得技巧 JunChen在最近的一篇《为何XHTML原型会失败》中说出了一个实质问题,即在快速变化的互联网公司中,非XHTML原型只是“看上去很美”而已。

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

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

  用户研究员进行用户研究,根据结果编写了研究报告(比如角色模型和使用场景);
  交互设计师按照用户研究报告,设计了线框图;
  视觉设计师拿到线框图,和交互设计师讨论并沟通后,进行视觉设计并输出高保真视觉原型;
  前端开发工程师拿到视觉原型,在和交互设计师及视觉设计师沟通后,进行编码工作,输出HTML文件;
  用户研究员开始可用性测试,并将问题反馈给交互设计师;
  回到第一步,直至用户研究员(或其他的什么人)认为质量合格。
  这一看似合理的流水线作业存在什么问题呢?让我们来仔细分析一下:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  上文讲到过分工不合适的原因,这次想和大家探讨一下我的一些关于如何解决问题的想法:

  1. “架构+设计+研究”的分工
  简单地说,就是架构组负责底层建设和方向引领,设计组负责设计和实现,研究组负责(部分的)用户研究和可用性测试。详细介绍可查看以前写的《说说互联网公司内设计师的分工》。这种分工能够解决上述的大部分问题。

  此外,正如jean.ma所说,在项目内的分工,应遵循“按模块而非角色”的方式来进行(这点我在《说说互联网公司内设计师的分工》也说过),就是不同的设计师负责产品不同的部分,然后由一名总设计师来统筹兼顾。

  2. 知识管理、文档管理和版本控制
  专门设立一台服务器,使用开源工具(比如Drupal),将所有的项目相关文档都进行集中的统一存放和管理,使任何事情有据可查,减少沟通成本,消灭“产出物发给了A部门,忘了发B部门”,或是某人说“我找不到你发的Demo了再发一次”的问题。

  如果你的部门使用Dreamweaver作为设计和开发工具,那就更好了!让架构组把最新的Dreamweaver模板和代码片断上传到服务器上,然后每个人打开Dreamweaver时第一件事情就是更新本地模板和代码片断(DW早就有此功能),这样不仅协同起来效率很高,而且质量可控性很好。可以说,这在一定程度上实现了开发使用Eclipse+SVN进行协同工作的效果。

  至于版本控制,一方面,给每一份产出指定一个唯一且明确的版本号,所有项目组成员交流时以版本号而不是“最新”一词为准,消灭歧义和不确定性。

  另一方面,如果你使用CVS或SVN进行版本控制,一定要把我们设计或开发的版本(也就是使用CVS或SVN进行版本控制的版本,以下简称trunk版)和给项目组演示的版本(采取手工方式进行版本控制,以下简称milestone版)分开,这样不仅可以加快我们的开发效率,更重要之处在于减少许多沟通成本。

  比如,假设你上午9点通知业务部门及开发部门,说某项目的Demo已经做好,访问服务器即可查看,一般情况下你并不能保证所有人都在接到你的通知后立即查看 Demo,很可能有的人是在9:30分看到,有的在10:00看到,甚至有的在第二天才看到。这期间你很可能会根据业务部门或是开发部门的反馈对Demo 进行了修改(哪怕是小修小补),那么这样一来,大家讨论的基础 - 统一的版本就不复存在了。

  我们可以借鉴程序员的做法,将trunk和milestone分开:平时在trunk上提交各类修改,如果需要展示给他人,则另外拷贝一份milestone版本(或新打一个分支,但此时意义不大)。比如你调试和预览的地址为 http://ued-server/demo/project-a/ ,当需要展示时,将project-a目录复制一份到 http://ued-server/demo/project-a/milestones/1 ,并以此作为第一个milestone。项目组成员在沟通时,都以milestone为基础。

  3. 把视图(view)交给它本来的主人-前端开发(甚至设计师)-去处理
  由于模板里常常混杂着HTML和程序语言(暂且以PHP为例),而这两种东西又分别来自于UED和开发两个部门,因此无论是编写还是调试模板,都要牵涉前端开发和程序员的精力。工作职责模糊不清,权责也很难界定。关系好的程序员曾私底下和我报怨说“如果连HTML/CSS/Javascript这些东西我们都写了,还要UED的人干吗”,虽然HTML/CSS/Javascript我都是尽可能完整产出,并且这句话也有其偏颇之处,但我仍对此深觉惭愧。

  “模型(model)-视图(view)-控制器(controller)”架构的重要目的之一,就是把视图尽可能与逻辑和数据分开。当以模板的形式把视图分出来以后,为了尽可能地降低模板的复杂性、又同时保持模板具有一定的逻辑和数据处理能力,让不那么熟悉程序的人也能够控制如何显示,人们才开发了各种模板语言,比如PHP中的Smarty和Java中的Velocity。也就是说,这种极度简化的模板语言就是专门给设计人员提供的,它甚至不会比Javascript更复杂!

  当把视图部分的工作完全交给UED后,开发和UED的合作可以以这样的方式进行:1)UED提供原型;2)开发按照原型提供所需的逻辑和数据(通常是一大堆if...else...和$username等变量);3)如果有必要,可以要开发按原型来写一个不考虑内容及样式的模板,模板里包含了所有必须的逻辑和数据;4)UED将逻辑、数据和各种前端代码编写进模板。

  这个方案我曾和系分及程序员讨论过几次,我们都认为它是可行的。出于可维护的角度考虑,他们其实也愿意将模板的编写工作交给UED。

  此方案的优点是显而易见的:开发和UED终于可以真正地各司其职,大家权责明确,从项目管理的角度来说,UED的工作时间计算也更为准确,以前那种“UED协助调试模板,花了大量时间却没有被记录进项目”的情况不会出现。

  缺点当然也不是没有,在方案实施初期,UED一定会有阵痛,尤其是对那些从没有接触过后台编程的设计师。

  4. 强调工具和规范的重要性,而非某个人的聪明才智
  天涯上前段时间流行一篇名为《做单》的小说,里面有一句话印象很深:

  “外企更像是一个集团军……民营企业都像是个游击队或者是特种部队……集团军最大的特点就是随便换掉某个人或者某几个人对整个军队没有任何影响,游击队就不能承受这种变化。

  国内的企业面临最大的问题就是从游击队向集团军的转变中,因为人意识的转变跟不上,而导致转型失败……一个民营企业要想做大,必须经历这种从游击队向集团军的转变。”

  关于规范说得够多了,还是说说工具吧。

  从团队的角度来说,工具主要的目的就是最大限度地统一和标准化产出物,提升团队的工作效率和质量。因此以下提及的工具都是与这个目的相关:

  Dreamweaver。它内建Templates和Code snippets功能,并支持从服务器上同步,如果整个部门都使用Dreamweaver的话,那么大家的Templates和Code snippets就全是规范的;
框架。无须赘言,好的框架可以让你3分钟做完原本需要10分钟的事情,并且产出物(典型如代码)高度规范;
文档库。比如前文提到的VelocityDoc,有了这东西,设计师可以在短时间内了解整个网站的模板,包括模板整体的结构、每个模板的作者、功用、所引用的CSS/Javascript,以及它所属的layout和所包含的control/element等等。对于新同事来说,文档是最好的老师;
封装。努力地将常用的东西封装成模块,避免重复劳动,同时也能降低对设计师的技能要求。比如说对于表单界面,交互设计师根据不同的错误情况,需要制作出不同的原型,费时费力,还容易出错,如果封装一下,设计师只按照一定格式提供错误提示的内容就好了,剩下的什么都不用管,全交给系统自动处理。
上面讲得有点太干巴巴了,这里有一个06年做的东西-代码助手-算是上述思想的一个集中体现吧。

  关于分工的话题暂且到此为止吧,这么枯燥冗长的内容不知有多少人可以坚持读完,呵呵。

上一篇: 使用“HR”符号在网页中插入虚线的方法

下一篇: XML学习整理之一:XML 文档语法

共有0条评论网友评论

游戏排行榜