<?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>风中飞行 &#187; 交互设计</title>
	<atom:link href="http://blog.moligu.com/category/%e4%ba%a4%e4%ba%92%e8%ae%be%e8%ae%a1/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.moligu.com</link>
	<description>在网络里一起吹吹风</description>
	<lastBuildDate>Wed, 02 Jun 2010 13:03:33 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>今日读网：交互设计</title>
		<link>http://blog.moligu.com/15</link>
		<comments>http://blog.moligu.com/15#comments</comments>
		<pubDate>Sun, 17 Jun 2007 19:01:43 +0000</pubDate>
		<dc:creator>风中飞行</dc:creator>
				<category><![CDATA[互联网]]></category>
		<category><![CDATA[交互设计]]></category>

		<guid isPermaLink="false">http://blog.moligu.com/15</guid>
		<description><![CDATA[以用户为中心的设计
这个博客很不错，看上去是个小组，文章质量都很高， 下面是摘录的一些文章。
管理者不应直接参与产品的开发与设计
管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。不然估计程序员也会起来抗议。为什么？因为他们对于设计的一知半解。如果一点都不了解，那倒也罢了。问题是设计相对于程序来说，更容易让人觉得自己很懂。
刘邦曾说“夫运筹策帷帐之中，决胜于千里之外，吾不如子房。镇国家，抚百姓，给馈饟，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。此三者，皆人杰也，吾能用之，此吾所以取天下也。”功能结构和页面结构的设计
功能结构和页面结构的设计
经验丰富的设计师一起合作时，我们会在一块块的纸上绘制简单的原型，然后再通过反复的讨论来决定把他们摆到什么位置。通常情况下和不是很熟练的设计师合作时，我们会用PPT或者PS去一步步的落实这些内容，先把内容都给列出来、接着考虑他们放到哪里去，然后考虑他们占多大空间，最后具体落实到主要模块的具体展现方式是什么样的。
合理构建了信息结构，为何还去扰乱？
本文用一个模拟的过程场景，谈了打乱信息架构的因素等，在构建信息结构的过程中的一些问题，下面是摘录的一段文字：
就这样，信息架构被改了又改，不但架构的合理性无从考证，随之而来的是：修改，返工……
且不说为了运营是否应该这样做，起码大家可以看到：在后期设计实施阶段，改变信息结构的代价是惨重的，返工也成了必然！对于信息架构，牵一发而动全身…
越减越妙
优秀的设计往往源于巧妙的减法。尤其在产品功能越做越多，越做越复杂的当今，通过简洁高效的界面设计，保证用户能正确地、轻松地使用产品，越发显得重要。
]]></description>
			<content:encoded><![CDATA[<h2><a target="_blank" href="http://ucdchina.com/blog/">以用户为中心的设计</a></h2>
<p>这个博客很不错，看上去是个小组，文章质量都很高， 下面是摘录的一些文章。</p>
<h2><a target="_blank" href="http://ucdchina.com/blog/?p=4">管理者不应直接参与产品的开发与设计</a></h2>
<p>管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。不然估计程序员也会起来抗议。为什么？因为他们对于设计的一知半解。如果一点都不了解，那倒也罢了。问题是设计相对于程序来说，更容易让人觉得自己很懂。</p>
<p>刘邦曾说“夫运筹策帷帐之中，决胜于千里之外，<strong>吾不如子房</strong>。镇国家，抚百姓，给馈饟，不绝粮道，<strong>吾不如萧何</strong>。连百万之军，战必胜，攻必取，<strong>吾不如韩信</strong>。此三者，皆人杰也，吾能用之，此吾所以取天下也。”功能结构和页面结构的设计</p>
<h2><a target="_blank" href="http://ucdchina.com/blog/?p=89">功能结构和页面结构的设计</a></h2>
<p>经验丰富的设计师一起合作时，我们会在一块块的纸上绘制简单的原型，然后再通过反复的讨论来决定把他们摆到什么位置。通常情况下和不是很熟练的设计师合作时，我们会用PPT或者PS去一步步的落实这些内容，先把内容都给列出来、接着考虑他们放到哪里去，然后考虑他们占多大空间，最后具体落实到主要模块的具体展现方式是什么样的。</p>
<h2><a target="_blank" href="http://ucdchina.com/blog/?p=87">合理构建了信息结构，为何还去扰乱？</a></h2>
<p>本文用一个模拟的过程场景，谈了打乱信息架构的因素等，在构建信息结构的过程中的一些问题，下面是摘录的一段文字：</p>
<p>就这样，信息架构被改了又改，不但架构的合理性无从考证，随之而来的是：修改，返工……</p>
<p>且不说为了运营是否应该这样做，起码大家可以看到：在后期设计实施阶段，改变信息结构的代价是惨重的，返工也成了必然！对于信息架构，牵一发而动全身…</p>
<h2><a target="_blank" href="http://ucdchina.com/angela/article.asp?id=14">越减越妙</a></h2>
<p>优秀的设计往往源于巧妙的减法。尤其在产品功能越做越多，越做越复杂的当今，通过简洁高效的界面设计，保证用户能正确地、轻松地使用产品，越发显得重要。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.moligu.com/15/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
