<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>AVENIR.ZHENG 郑焕义 &#187; 视觉设计师</title>
	<atom:link href="http://caib.me/tag/%e8%a7%86%e8%a7%89%e8%ae%be%e8%ae%a1%e5%b8%88/feed/" rel="self" type="application/rss+xml" />
	<link>http://caib.me</link>
	<description>从平凡到卓越</description>
	<lastBuildDate>Wed, 07 Sep 2011 18:47:16 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>{ Division of labor } 为什么网页设计不应强调分工[摘]</title>
		<link>http://caib.me/division-of-labor-in-web-design-area/</link>
		<comments>http://caib.me/division-of-labor-in-web-design-area/#comments</comments>
		<pubDate>Mon, 15 Dec 2008 17:36:31 +0000</pubDate>
		<dc:creator></dc:creator>
				<category><![CDATA[前端]]></category>
		<category><![CDATA[Felix]]></category>
		<category><![CDATA[JunChen]]></category>
		<category><![CDATA[XHTML]]></category>
		<category><![CDATA[交互设计师]]></category>
		<category><![CDATA[分工]]></category>
		<category><![CDATA[前端开发工程师]]></category>
		<category><![CDATA[瀑布模型]]></category>
		<category><![CDATA[用户研究员]]></category>
		<category><![CDATA[网页设计]]></category>
		<category><![CDATA[视觉设计师]]></category>

		<guid isPermaLink="false">http://blog.adriancheng.name/index.php/2008/12/16/division-of-labor-%e4%b8%ba%e4%bb%80%e4%b9%88%e7%bd%91%e9%a1%b5%e8%ae%be%e8%ae%a1%e4%b8%8d%e5%ba%94%e5%bc%ba%e8%b0%83%e5%88%86%e5%b7%a5%e6%91%98/</guid>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160; 基本的观点都挺认同的，特别是说到“瀑布模型”和重复劳动这两个点上。
&#160;&#160;&#160;&#160;&#160; 在中小型的网站项目上，也许强调分工真得没有必要，看现在的... ]]></description>
			<content:encoded><![CDATA[<p><img title="Division of labor" style="display: inline" height="143" alt="Division of labor" src="http://cai13.info/blog_pic/2008/12/divisionoflabor.jpg" width="500" border="0" />&#160;&#160;&#160;&#160;&#160;&#160; 基本的观点都挺认同的，特别是说到“瀑布模型”和重复劳动这两个点上。</p>
<p>&#160;&#160;&#160;&#160;&#160; 在中小型的网站项目上，也许强调分工真得没有必要，看现在的网络科技公司，不都只配置美工和程序员。不过在大型项目上，真得不需要明确分工么？</p>
<p>&#160;&#160;&#160;&#160;&#160; 期待着<a href="http://heartstringz.net/about" target="_blank">Felix</a>的下一篇作品，学习学习。</p>
<p> <span id="more-790"></span>
<p>&#160;</p>
<p>&#160;&#160;&#160;&#160;&#160; JunChen在最近的一篇<a href="http://www.junchenwu.com/2008/12/why_xhtml_fails.html">《为何XHTML原型会失败》</a>中说出了一个实质问题，即在快速变化的互联网公司中，非XHTML原型只是“看上去很美”而已。</p>
<p>&#160;&#160;&#160;&#160;&#160; 究其原因。除了JunChen提到的“难以维护”以外，对设计和开发人员精力的消耗也是一个重要方面。</p>
<p>&#160;&#160;&#160;&#160;&#160; 让我们来看一个典型的流程：</p>
<ol>
<li>用户研究员进行用户研究，根据结果编写了研究报告（比如角色模型和使用场景）； </li>
<li>交互设计师按照用户研究报告，设计了线框图； </li>
<li>视觉设计师拿到线框图，和交互设计师讨论并沟通后，进行视觉设计并输出高保真视觉原型； </li>
<li>前端开发工程师拿到视觉原型，在和交互设计师及视觉设计师沟通后，进行编码工作，输出HTML文件； </li>
<li>用户研究员开始可用性测试，并将问题反馈给交互设计师； </li>
<li>回到第一步，直至用户研究员（或其他的什么人）认为质量合格。 </li>
</ol>
<p>&#160;&#160;&#160;&#160;&#160; 这一看似合理的流水线作业存在什么问题呢？让我们来仔细分析一下：</p>
<p>&#160;</p>
<h5>1. 困惑的交互设计师</h5>
<p>&#160;&#160;&#160;&#160;&#160; 用户研究是一个渐进式接近真相的过程，其结果不可能一步到位。尤其在研究初期，哪些因素会对产品设计有较大影响，哪些因素实际无足轻重，这是没有办法事先准确预估的。这就造成当交互设计师在依照研究结果设计时，发现研究结果不能给自己的设计以有力的支撑。</p>
<p>&#160;&#160;&#160;&#160;&#160; 比如，当两种交互方式都可以达到同样目的、而从已有的数据中又无法判断用户会喜欢哪种时，交互设计师就会犹豫不决。从资源的角度来考虑，请研究员再一次制订计划、招募用户并实施研究，是不太可能的；更不用说设计两种原型并分别测试了。因此此时交互设计师只能依据自己的经验，或者进行押宝。</p>
<p>&#160;&#160;&#160;&#160;&#160; 此外，交互设计师还面临一个颇为尴尬的问题：由于处于流程中的中间环节，缺少坚实的硬性产出，他很难、甚至没办法证明自己的工作价值。一方面，交互设计是一种偏“软”的技能，它目前没有、将来也很难产生一个标准化的量尺来考量其自身的质量。可用性测试可以做到部分量化，比如完成时间、出错次数等，但十几个人（一般甚至更少）的数据在统计学上是没有任何意义的。而且，有多少用户能理解那种低保真的原型呢？另一方面，就算用Axure等软件制作可操作的原型然后拿去做测试，各个业务部门会相信测试结果么？没错，你可以强硬一些，比如采取“如果业务部门不参与观察测试，就算自动放弃决策时的发言权”这样的办法，可这只能说你有工作方法，这实在无益于专业技能的提升。而且有多少设计师可以强势到让所有的业务部门闭嘴的？</p>
<p>&#160;&#160;&#160;&#160;&#160; 实施社会分工的目的之一，就是实施标准化的作业。而当流水线中某一环节的产出物质量，是随着其作者的经验而变化时，也就是说质量并不能定量控制时，分工的意义就不复存在，这一生产方式也就不可能按简单复制的方式扩张规模。</p>
<p>&#160;</p>
<h5>2. 交互、视觉和前端间的沟通成本，和可能的不愉快</h5>
<p>&#160;&#160;&#160;&#160;&#160; 在交互设计师和视觉设计师交接工作时，沟通不可避免。视觉设计师要充分领会交互设计师的意图，这需要沟通；反过来视觉设计师给交互设计师的线框图提意见，这也需要沟通。尤其在整个部门缺乏UI规范时，沟通成本可能会高得吓人。比如交互设计师认为某处需要用3级标题（比如h3），到了视觉这里直接用了一行红字。所以常常觉得“有那时间费力沟通，还不如直接改了算了”。结果改完了交互设计师心里会想“你怎么也不和我打声招呼就改了”，不愉快就这么来了。</p>
<p>&#160;&#160;&#160;&#160;&#160; 到了前端开发那里，问题就更复杂了。首先，前端开发需要实现所有细节，而出于资源上的考虑，这些细节未必都会由交互和视觉设计师的产出物覆盖到（比如同一页面上仅有一处文字有微小变化，那么线框图和视觉稿要分别做两份吗？），那么前端开发就需要经常和前面两者沟通；其次，如果前端开发发觉设计稿的实现难度或成本太高，那么情况就更为棘手，最麻烦的莫过于要重新设计交互原型。</p>
<p>&#160;&#160;&#160;&#160;&#160; 当然，上述问题基本都能靠沟通解决，问题是，你愿意花多少时间去沟通呢？从这个角度来说，敏捷开发的沟通成本是最低的，因为沟通就是产出。而反过来上述流程的沟通成本很高，因为沟通是用来解释产出的，是产出成本之外的“额外成本”。</p>
<p>&#160;</p>
<h5>3. 瀑布模型与生俱来的缺陷</h5>
<p>&#160;&#160;&#160;&#160;&#160; 上述流程是一个典型的<a href="http://zh.wikipedia.org/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B">瀑布模型</a>，一旦在可用性测试阶段发现问题，就需要重新再走整个流程，其效率之低可想而知。此外，由于涉及到的环节和人员不少，流程走得次数越多，出问题的机会也越多。最常见的是各个环节的产出物版本控制困难，甚至根本没有版本控制，结果往往造成项目组中每个人拿到的产出物（如Demo）都不一样，这是一个非常可怕的风险，会给项目过程和质量带来非常严重的影响。</p>
<p>&#160;&#160;&#160;&#160;&#160; 我对这个问题采取过“文档管理＋版本控制＋减少分工”的方法，效果很好。这个后文会阐述，这里先不展开。</p>
<p>&#160;</p>
<h5>4. 无技术含量可言的重复劳动</h5>
<p>&#160;&#160;&#160;&#160;&#160; 在一些页面调整不大的日常项目中，交互设计师用2小时做的原型，到了前端那里可能半个小时就把HTML搞定了，如果用<a href="http://heartstringz.net/blog/posts/view/web-design-tools">CSSEdit</a>那样的工具，实现过程甚至更快、更惬意。那么，为什么要把原本一件很小的工作硬生生地拆成两部分来做呢？</p>
<p>&#160;&#160;&#160;&#160;&#160; 举一个非常常见的例子：业务部门提需求说要改某某宣传文案，如果按照上述流程，交互先做线框，给到视觉确认，然后到前端修改，往最快了说也得半小时吧。而若交互设计师直接改HTML，十分钟搞定。</p>
<p>&#160;&#160;&#160;&#160;&#160; 有人说找到相应的模板还要时间呢，这好办，做个可搜索的模板库就好了。我们曾参考<a href="http://phpdoc.org/">DocBlock规范</a>做过VelocityDoc，效果很好。</p>
<p>&#160;</p>
<h5>5. 破坏了网页设计工作本身的美感</h5>
<p>&#160;&#160;&#160;&#160;&#160; 网页设计是技术和艺术的结合，一个优秀的设计师不仅大量吸收传统的设计知识（如平面设计），更懂得如何利用合适的技术去带来艺术上的创新。这个过程是相辅相成的，硬性拆开只会限制设计师的创造力。</p>
<p>&#160;&#160;&#160;&#160;&#160; 这就好像搞油画的必须要掌握不同染料和画布的性质，搞雕塑的既要有创意又有能动手（你能想象出一个雕塑家只管创意而从不亲自去实现吗）一样，使用技术来展现艺术，借助艺术去探究可能的技术。</p>
<p>&#160;&#160;&#160;&#160;&#160; 据说Apple的工业设计师都要清楚地理解各种材料的特点的，如果只让他们画图，Unibody这样的杰作又如何诞生？</p>
<p>&#160;&#160;&#160;&#160;&#160; 说了半天问题，下篇中我们来看怎么解决。</p>
<p>&#160;</p>
<p>原文：<a title="http://heartstringz.net/blog/posts/view/why-no-division-in-web-design-1" href="http://heartstringz.net/blog/posts/view/why-no-division-in-web-design-1">http://heartstringz.net/blog/posts/view/why-no-division-in-web-design-1</a></p>
<p>转至：<a href="http://heartstringz.net/blog/" target="_blank">心弦</a></p>
]]></content:encoded>
			<wfw:commentRss>http://caib.me/division-of-labor-in-web-design-area/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>{ Desinger } 视觉设计师扛起UE大旗？[摘]</title>
		<link>http://caib.me/desinger-%e8%a7%86%e8%a7%89%e8%ae%be%e8%ae%a1%e5%b8%88%e6%89%9b%e8%b5%b7ue%e5%a4%a7%e6%97%97%ef%bc%9f%e6%91%98/</link>
		<comments>http://caib.me/desinger-%e8%a7%86%e8%a7%89%e8%ae%be%e8%ae%a1%e5%b8%88%e6%89%9b%e8%b5%b7ue%e5%a4%a7%e6%97%97%ef%bc%9f%e6%91%98/#comments</comments>
		<pubDate>Mon, 08 Dec 2008 17:03:50 +0000</pubDate>
		<dc:creator></dc:creator>
				<category><![CDATA[前端]]></category>
		<category><![CDATA[Angela]]></category>
		<category><![CDATA[Personas]]></category>
		<category><![CDATA[UE]]></category>
		<category><![CDATA[UE团队]]></category>
		<category><![CDATA[视觉设计师]]></category>

		<guid isPermaLink="false">http://blog.adriancheng.name/?p=776</guid>
		<description><![CDATA[
      在UE未流行前，做网站也就需要两类人，逻辑思维的工程师、感性思维的设计师，而作为最直观接受用户和客户的视觉设计师，免不了需要多考虑用户感受，揣摩用户心理。
      在网上看... ]]></description>
			<content:encoded><![CDATA[<p><img class="alignnone size-full wp-image-777" title="visual-designer" src="http://cai13.info/blog_pic/2008/12/visual-designer.jpg" alt="" width="500" height="143" /></p>
<p>      在UE未流行前，做网站也就需要两类人，逻辑思维的工程师、感性思维的设计师，而作为最直观接受用户和客户的视觉设计师，免不了需要多考虑用户感受，揣摩用户心理。</p>
<p>      在网上看到<span style="font-size: x-small; font-family: Arial;"><a title="视觉设计师扛起UE大旗？" href="http://angela.ucdchina.com/?p=16" target="_self">Angela</a>大大的文章，也算更认清了方向。</span></p>
<p><span id="more-776"></span></p>
<p>      最近我在翻译一本Steve Mulder写的关于人物角色的书。人物角色（Personas）是UCD中的一个工具，是通过基于用户研究数据创建几个有名有姓有经历的人物来进行产品设计的一种方法。</p>
<p>      写到这儿，我突然想起我认识的同行中有那么几个自视清高，不屑于解释类似UI和UCD有什么区别之类的问题，因为他们觉得如果你真的想干这行的话，你得自己找到办法学习，比如Google一下什么的。</p>
<p>      可事实是，现在对这些满世界乱飞的“UXX”一头雾水的人多的是，其中有正在从事或有志从事这个行业的人，也有正在或即将和我们合作的人。要是我们自己都不去讲清楚这个事，又怎么能让别人理解并帮助我们呢？“<strong>很多不错的商业策略最后失败都是由于缺乏统一认识而导致的低劣的执行</strong>”，Steve Mulder在他的书中这么说。我们可以想想，有多少时间花在了说服开发人员或产品经理认同我们的观点上？</p>
<p>      言归正传，这几年来，随着我对这个行业越是深入的了解，我就越是迷惑：用户体验怎么就成了视觉设计师的工作了呢？</p>
<p>      如果不是的话，为什么UI行业聚会上的“业内人士”以及主题关于UE的博客作者们，大部分是原来从事外观/美术设计的网页设计师呢？</p>
<p>      我能想出来的原因就是，视觉设计是所有的产品设计工作中最直观的一个工种，是唯一直接与用户接触的最外沿。你会说信息架构和交互设计也是和用户直接产生交互的，可是你再仔细想想看，如果没有视觉上的表达，它们如何工作？</p>
<p>      正是由于这个原因，视觉设计师在工作过程中发现产品设计漏洞的机率就远远大于其它工种，也就顺理成章地成为扛起UE大旗的先行者。</p>
<p>      但是我仍然认为视觉设计师承担不起UE的重量（具体原因请见《<a title="http://ucdchina.com/angela/article.asp?id=9" href="http://ucdchina.com/angela/article.asp?id=9" target="_blank">用户体验：设计不能承受之重</a>》），不仅仅是由于用户体验的综合性和复杂性，还因为设计师本身的局限。</p>
<p>      关于视觉设计师，大家多少都有一些印象。这是一群追求与众不同，喜欢出其不意和推陈出新的家伙，他们极富创意和想法，敏感而尖锐，是典型的感情动物。你能想象得出让他们去设计用户调查问卷、主持可用性测试、分析网站流量数据的情形吗？</p>
<p>      我没有一点贬低设计师的意思，到目前为止，我仍然只是一个对交互设计充满好奇和激情的视觉设计师。客观情况是，除了少数的几个天才以外，人的天份是有限的，如果你是一个对颜色、形状、比例很敏感的人，你一定对数字和图表具有天生的免疫力，除非这是你自己的电话账单和股票走势图。也许经过后天的努力你能成为一个文理兼修的人，但那必须要付出加倍的心血和汗水（我至今仍然在看到“统计变量”的时候会发上那么一会儿呆）。</p>
<p>      可是现在情形是，大部分公司里所谓的UE部门，几乎就是曾经的设计部门的原班人马，原来满口色彩和对比的家伙，开始大谈特谈用户需求和产品方向。于是大家就认为所谓UI和以用户为中心的设计也就是那么回事。这些自认为已经是合格UI设计师的家伙们信口雌黄的结果，就是坏掉了整个行业的口碑。</p>
<p>      也难怪IBM的赵晨在某次会议上谈到关于对这个行业的未来的担扰。我也一直记得她不断地强调：“我们之所以成为专家不是因为我们知道的比别人多，而是因为我们掌握了方法。”而她说的方法，就是包括用户调查、可用性测试、人物角色、场景设计、数据分析等等在内的一系列被认为科学有效的方法，有多少网站在产品设计流程中哪怕真正实施过一两个这样的方法呢？又有多少人真正知道如何有效运用这些方法呢？</p>
<p>      我希望这篇文章给现在热得烫手的“UE行业”加入一点冷静的声音，在我心目中，视觉设计师应该是UE的受益者而不是倡议者，因为UCD的介入使视觉设计有了客观依据，而不是像现在这样凭感觉做事。</p>
<p>      这才是我们应该额首相庆的事。</p>
<p>原文：<a href="http://angela.ucdchina.com/?p=16">http://angela.ucdchina.com/?p=16</a></p>
<p>作者：<a title="angela" href="http://angela.ucdchina.com/" target="_self">Angela</a></p>
]]></content:encoded>
			<wfw:commentRss>http://caib.me/desinger-%e8%a7%86%e8%a7%89%e8%ae%be%e8%ae%a1%e5%b8%88%e6%89%9b%e8%b5%b7ue%e5%a4%a7%e6%97%97%ef%bc%9f%e6%91%98/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>

