<?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>hoowow &#187; 规范</title>
	<atom:link href="http://hoowow.com/blog/tag/%e8%a7%84%e8%8c%83/feed/" rel="self" type="application/rss+xml" />
	<link>http://hoowow.com/blog</link>
	<description>Knew nothing</description>
	<lastBuildDate>Sun, 18 Jul 2010 16:45:04 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>设计规范有谱么?</title>
		<link>http://hoowow.com/blog/2008/12/12/%e8%ae%be%e8%ae%a1%e8%a7%84%e8%8c%83%e6%9c%89%e8%b0%b1%e4%b9%88/</link>
		<comments>http://hoowow.com/blog/2008/12/12/%e8%ae%be%e8%ae%a1%e8%a7%84%e8%8c%83%e6%9c%89%e8%b0%b1%e4%b9%88/#comments</comments>
		<pubDate>Fri, 12 Dec 2008 19:36:47 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[杂谈]]></category>
		<category><![CDATA[网页]]></category>
		<category><![CDATA[规范]]></category>
		<category><![CDATA[设计]]></category>

		<guid isPermaLink="false">http://hoowow.cn/blog/?p=114</guid>
		<description><![CDATA[(转载,来自lytous)从业这几年，自己写过的和帮人参谋的所谓“设计规范”不少了，这个东西大概在中国的决策层眼里是这么回事儿&#8211;一帮农民在一块田里种粮食，起先天气不错，土地肥沃，但是不久天气变差了，虫子多了，土地沙化严重，还有几个缺心眼的内鬼偷粮食，这下必须立定一个规范，挑头的告诉他们该在哪儿种，收多少麦子算合格，哪部分的地是留到下一季种的，种出什么样的麦子给奖金，偷懒不干活的怎么处理…… 但我理解的规范不是简单的把一个设计做成一个“行业套路”的量化指标，而是一个综合的品质评估的参考，甚至是一个设计能否面市的决定因素。为此，我们需要拟定一些表格，文档备案，图形参考，交互模板。 同时，设计规范还要成为设计部门或者一个公司对于设计品质的共同价值观，让大家伙都知道这样做出来的是好设计，通过这样的规范教育和交流，形成对设计品质的统一认识。设计规范不是规定要做什么，而是提出这样做是正确的，但是有更好的地方可以改进。 国外设计师管这种做法叫设计工具，是模板化应用的方法（Stencil），我们称之为规范，更多的偏向于规则（Regulation），却只学习到了量化指标的简单部分。说的严重点吧，我们中国人向来就特别擅长给自己搞个框架（紧箍咒），来约束人的作为与想法，可能有三个原因： 我们不太擅长找到解决问题的严谨逻辑，甚至是已有现成教训的； 我们始终缺乏对于团队成员之间的信任，哪怕是共同合作了多年的； 我们的企业无法承担某些错误带来的后果，甚至是很小风险的。 我们一开始就把一个工具性的东西变成了制度，因此问题便出来了。对于成长期的设计团队来说，建立设计规范需要的是确立一套可用工具，然后在工具的基础上发展成为部门设计品质建设的road map，如果只是弄个“导航按钮间距不得超过10px”这样的规范，就跟小时候尿尿要听到“嘘~~~~”声一样，尿得更快。 我不是跟这儿扯谈，在我看来咱们现在行业里面瞧得见摸得着的优秀的设计规范不多，现在来说说，和大家交流一下： 1. 设计规范达不到预期效果的原因 总是出现问题和错误后才开始拟定和修改规范，缺乏预见性； 规范制定出来后，执行不到位，缺乏力度和奖惩措施，监督控制节奏拖沓缓慢； 在产品设计过程中，不对设计规范做进一步的修订，甚至之前出现的错误也不去改正； 完全教条的根据设计规范设计，比如有些团队做的还是通用设计规范，很多设计师就照着里面的要求重复设计类似的页面，类似的广告，类似的动画，完全豪无特色，没有差异化。&#8211;用心的话，你可以看看现在各个互联网产品的相似程度有多少？我不得不说，那些恶劣的设计规范要负一定的责任。 2. 设计规范最常见的错误 让部门领导者制定设计规范&#8211;设计规范是共同讨论出来的，在迭代中改进修正，由于国内设计师大多数有“领导恐惧症”，因此这样的规范就算制定出来也是空头支票，甚至有不少领导是很少参与一线工作的。 照搬国外成功团队的设计规范&#8211;这样的事情多半发生在喜欢“洋为中用”的设计团队中，国内外的设计环境差异很大，产品差异很大，面对的市场差异也很大，所以不要照搬，更不要直接翻译。 把设计规范打印出来贴在座位旁边&#8211;这是“大字报”，还是“表决心”啊？从我认识的设计师朋友来说，经常看座位旁边的东西只有2种，一是日程表，二是检查手机电池是否充满了。 3. 设计规范的本质是做好人的工作 在我看来，中国的企业只要是有设计部门的，做这个设计规范，最重要的是要和企业管理，团队文化建设绑定到一起，做人的发展建设工作。我们的设计师老实说没那么成熟，也没有过多的设计锻炼，整个不良的规范在哪儿杵着只会让设计师更加不愿意沟通&#8211;“有啥好聊的？不是有规范么，照着做就行了” 设计部门如果真的沟通紧密，在设计过程中有共同价值观，这一个设计的流程是顺水推舟的，也是自然就形成的“规范”，不需要过多的文字描述。我还见过某些公司的设计规范中赫然写着：“一旦出现上述设计制作中A-C问题，设计师个人考评-5分”，OMG，原来你家的产品原来就值5分。 4. 优秀的设计规范要达到什么目的 量化指标： 确定一般可用性原则和审美常识下的避免犯错的方法，以及一旦出现错误后的补救方案。规范的第一个目的是减少设计过程中出错的次数，一般这是针对新手设计师的，好的量化指标是告诉他经验，比如：建议html文件输出后在ie6,ie7,firefox,safari中做至少2次不同分辨率测试，并将结果添加到《设计规范-参考数据》中；而不是规定他方向，比如：根据产品部要求进行测试修改。 确认设计关键点： 获得该设计规范针对范围内的关键点，包括设计方向和设计元素，以通过项目设计的过程，达到团队成员的更加密切的配合效果。它是一份检验文件，记录过程中的错误，留作以后的经验。并在此可以做出项目和产品设计的里程碑。 规范设计原则： 这个原则有可能是针对单个项目的，也有可能是整个设计团队的指导原则，这个原则要被反复强调，反复实施，团队人员要共同为这个原则负责，比如：“确保在任何项目结束时间前4小时，完成设计输出”，“绝不允许设计粗糙的界面方案，如下图所示说明：XXXXX”等。 设计规范本身也需要可用性： 描述同一个设计要求，可以说：“S级设计师针对该项目Phase1部分工作，可控时间不超过2.5循环周期，输出交付件供ISO000459号程序评审”；但这样描写，能够明白的人会更多“界面设计师 XXX 设计该项目界面高保真原型，需在10个工作日内完成，5月22日下午14：00在5号会议室评审”。 千万不要把事情搞复杂，能把事情做简单的人是伟大的，设计规范也是如此。]]></description>
			<content:encoded><![CDATA[<p><strong>(转载,来自lytous)</strong>从业这几年，自己写过的和帮人参谋的所谓“设计规范”不少了，这个东西大概在中国的决策层眼里是这么回事儿&#8211;一帮农民在一块田里种粮食，起先天气不错，土地肥沃，但是不久天气变差了，虫子多了，土地沙化严重，还有几个缺心眼的内鬼偷粮食，这下必须立定一个规范，挑头的告诉他们该在哪儿种，收多少麦子算合格，哪部分的地是留到下一季种的，种出什么样的麦子给奖金，偷懒不干活的怎么处理……<span id="more-114"></span></p>
<p>但我理解的规范不是简单的把一个设计做成一个“行业套路”的量化指标，而是一个综合的品质评估的参考，甚至是一个设计能否面市的决定因素。为此，我们需要拟定一些表格，文档备案，图形参考，交互模板。</p>
<p>同时，设计规范还要成为设计部门或者一个公司对于设计品质的共同价值观，让大家伙都知道这样做出来的是好设计，通过这样的规范教育和交流，形成对设计品质的统一认识。设计规范不是规定要做什么，而是提出这样做是正确的，但是有更好的地方可以改进。</p>
<p>国外设计师管这种做法叫设计工具，是模板化应用的方法（Stencil），我们称之为规范，更多的偏向于规则（Regulation），却只学习到了量化指标的简单部分。说的严重点吧，我们中国人向来就特别擅长给自己搞个框架（紧箍咒），来约束人的作为与想法，可能有三个原因：</p>
<ul>
<li>我们不太擅长找到解决问题的严谨逻辑，甚至是已有现成教训的；</li>
<li>我们始终缺乏对于团队成员之间的信任，哪怕是共同合作了多年的；</li>
<li>我们的企业无法承担某些错误带来的后果，甚至是很小风险的。</li>
</ul>
<p>我们一开始就把一个工具性的东西变成了制度，因此问题便出来了。对于成长期的设计团队来说，建立设计规范需要的是确立一套可用工具，然后在工具的基础上发展成为部门设计品质建设的road map，如果只是弄个“导航按钮间距不得超过10px”这样的规范，就跟小时候尿尿要听到“嘘~~~~”声一样，尿得更快。</p>
<p>我不是跟这儿扯谈，在我看来咱们现在行业里面瞧得见摸得着的优秀的设计规范不多，现在来说说，和大家交流一下：</p>
<p><strong>1. 设计规范达不到预期效果的原因</strong></p>
<p>总是出现问题和错误后才开始拟定和修改规范，缺乏预见性；<br />
规范制定出来后，执行不到位，缺乏力度和奖惩措施，监督控制节奏拖沓缓慢；<br />
在产品设计过程中，不对设计规范做进一步的修订，甚至之前出现的错误也不去改正；</p>
<p>完全教条的根据设计规范设计，比如有些团队做的还是通用设计规范，很多设计师就照着里面的要求重复设计类似的页面，类似的广告，类似的动画，完全豪无特色，没有差异化。&#8211;用心的话，你可以看看现在各个互联网产品的相似程度有多少？我不得不说，那些恶劣的设计规范要负一定的责任。</p>
<p><strong>2. 设计规范最常见的错误</strong></p>
<p>让部门领导者制定设计规范&#8211;设计规范是共同讨论出来的，在迭代中改进修正，由于国内设计师大多数有“领导恐惧症”，因此这样的规范就算制定出来也是空头支票，甚至有不少领导是很少参与一线工作的。</p>
<p>照搬国外成功团队的设计规范&#8211;这样的事情多半发生在喜欢“洋为中用”的设计团队中，国内外的设计环境差异很大，产品差异很大，面对的市场差异也很大，所以不要照搬，更不要直接翻译。</p>
<p>把设计规范打印出来贴在座位旁边&#8211;这是“大字报”，还是“表决心”啊？从我认识的设计师朋友来说，经常看座位旁边的东西只有2种，一是日程表，二是检查手机电池是否充满了。</p>
<p><strong>3. 设计规范的本质是做好人的工作</strong></p>
<p>在我看来，中国的企业只要是有设计部门的，做这个设计规范，最重要的是要和企业管理，团队文化建设绑定到一起，做人的发展建设工作。我们的设计师老实说没那么成熟，也没有过多的设计锻炼，整个不良的规范在哪儿杵着只会让设计师更加不愿意沟通&#8211;“有啥好聊的？不是有规范么，照着做就行了”</p>
<p>设计部门如果真的沟通紧密，在设计过程中有共同价值观，这一个设计的流程是顺水推舟的，也是自然就形成的“规范”，不需要过多的文字描述。我还见过某些公司的设计规范中赫然写着：“一旦出现上述设计制作中A-C问题，设计师个人考评-5分”，OMG，原来你家的产品原来就值5分。</p>
<p><strong>4. 优秀的设计规范要达到什么目的</strong></p>
<ul>
<li>量化指标：<br />
确定一般可用性原则和审美常识下的避免犯错的方法，以及一旦出现错误后的补救方案。规范的第一个目的是减少设计过程中出错的次数，一般这是针对新手设计师的，好的量化指标是告诉他经验，比如：建议html文件输出后在ie6,ie7,firefox,safari中做至少2次不同分辨率测试，并将结果添加到《设计规范-参考数据》中；而不是规定他方向，比如：根据产品部要求进行测试修改。</li>
<li>确认设计关键点：<br />
获得该设计规范针对范围内的关键点，包括设计方向和设计元素，以通过项目设计的过程，达到团队成员的更加密切的配合效果。它是一份检验文件，记录过程中的错误，留作以后的经验。并在此可以做出项目和产品设计的里程碑。</li>
<li>规范设计原则：<br />
这个原则有可能是针对单个项目的，也有可能是整个设计团队的指导原则，这个原则要被反复强调，反复实施，团队人员要共同为这个原则负责，比如：“确保在任何项目结束时间前4小时，完成设计输出”，“绝不允许设计粗糙的界面方案，如下图所示说明：XXXXX”等。</li>
<li>设计规范本身也需要可用性：<br />
描述同一个设计要求，可以说：“S级设计师针对该项目Phase1部分工作，可控时间不超过2.5循环周期，输出交付件供ISO000459号程序评审”；但这样描写，能够明白的人会更多“界面设计师 XXX 设计该项目界面高保真原型，需在10个工作日内完成，5月22日下午14：00在5号会议室评审”。</li>
</ul>
<p>千万不要把事情搞复杂，能把事情做简单的人是伟大的，设计规范也是如此。</p>
]]></content:encoded>
			<wfw:commentRss>http://hoowow.com/blog/2008/12/12/%e8%ae%be%e8%ae%a1%e8%a7%84%e8%8c%83%e6%9c%89%e8%b0%b1%e4%b9%88/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
