网页设计不应该分工的原因及解决办法
烈火建站学院(LieHuo.Net)网页制作心得技巧 JunChen在最近的一篇《为何XHTML原型会失败》中说出了一个实质问题,即在快速变化的互联网公司中,非XHTML原型只是“看上去很美”而已。
究其原因。除了JunChen提到的“难以维护”以外,对设计和开发人员精力的消耗也是一个重要方面。 让我们来看一个典型的流程: 用户研究员进行用户研究,根据结果编写了研究报告(比如角色模型和使用场景); 1、困惑的交互设计师 比如,当两种交互方式都可以达到同样目的、而从已有的数据中又无法判断用户会喜欢哪种时,交互设计师就会犹豫不决。从资源的角度来考虑,请研究员再一次制订计划、招募用户并实施研究,是不太可能的;更不用说设计两种原型并分别测试了。因此此时交互设计师只能依据自己的经验,或者进行押宝。 此外,交互设计师还面临一个颇为尴尬的问题:由于处于流程中的中间环节,缺少坚实的硬性产出,他很难、甚至没办法证明自己的工作价值。一方面,交互设计是一种偏“软”的技能,它目前没有、将来也很难产生一个标准化的量尺来考量其自身的质量。可用性测试可以做到部分量化,比如完成时间、出错次数等,但十几个人(一般甚至更少)的数据在统计学上是没有任何意义的。而且,有多少用户能理解那种低保真的原型呢?另一方面,就算用Axure等软件制作可操作的原型然后拿去做测试,各个业务部门会相信测试结果么?没错,你可以强硬一些,比如采取“如果业务部门不参与观察测试,就算自动放弃决策时的发言权”这样的办法,可这只能说你有工作方法,这实在无益于专业技能的提升。而且有多少设计师可以强势到让所有的业务部门闭嘴的? 实施社会分工的目的之一,就是实施标准化的作业。而当流水线中某一环节的产出物质量,是随着其作者的经验而变化时,也就是说质量并不能定量控制时,分工的意义就不复存在,这一生产方式也就不可能按简单复制的方式扩张规模。 2、交互、视觉和前端间的沟通成本,和可能的不愉快 到了前端开发那里,问题就更复杂了。首先,前端开发需要实现所有细节,而出于资源上的考虑,这些细节未必都会由交互和视觉设计师的产出物覆盖到(比如同一页面上仅有一处文字有微小变化,那么线框图和视觉稿要分别做两份吗?),那么前端开发就需要经常和前面两者沟通;其次,如果前端开发发觉设计稿的实现难度或成本太高,那么情况就更为棘手,最麻烦的莫过于要重新设计交互原型。 当然,上述问题基本都能靠沟通解决,问题是,你愿意花多少时间去沟通呢?从这个角度来说,敏捷开发的沟通成本是最低的,因为沟通就是产出。而反过来上述流程的沟通成本很高,因为沟通是用来解释产出的,是产出成本之外的“额外成本”。 3、瀑布模型与生俱来的缺陷 我对这个问题采取过“文档管理+版本控制+减少分工”的方法,效果很好。这个后文会阐述,这里先不展开。 4、无技术含量可言的重复劳动 举一个非常常见的例子:业务部门提需求说要改某某宣传文案,如果按照上述流程,交互先做线框,给到视觉确认,然后到前端修改,往最快了说也得半小时吧。而若交互设计师直接改HTML,十分钟搞定。 有人说找到相应的模板还要时间呢,这好办,做个可搜索的模板库就好了。我们曾参考DocBlock规范做过VelocityDoc,效果很好。 5、破坏了网页设计工作本身的美感 (编辑:ASP站长网) |