<?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>Shimu design - 设计&#38;产品&#38;前端&#38;wordpress &#187; UCD</title>
	<atom:link href="http://www.shimuuu.com/tag/ucd/feed" rel="self" type="application/rss+xml" />
	<link>http://www.shimuuu.com</link>
	<description>诗沐的设计博客和作品集。提供网页设计/开发/用户体验咨询/wordpress博客主题设计等服务。记录网页设计&#38;开发教程，发布wordpress主题。</description>
	<lastBuildDate>Fri, 02 Sep 2011 02: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://www.shimuuu.com/blog/interaction-design-easy-to-use-and-light-weight</link>
		<comments>http://www.shimuuu.com/blog/interaction-design-easy-to-use-and-light-weight#comments</comments>
		<pubDate>Mon, 10 May 2010 12:31:48 +0000</pubDate>
		<dc:creator>shimu</dc:creator>
				<category><![CDATA[blog]]></category>
		<category><![CDATA[思索]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[interaction design]]></category>
		<category><![CDATA[UCD]]></category>
		<category><![CDATA[user experience]]></category>
		<category><![CDATA[交互]]></category>
		<category><![CDATA[用户体验]]></category>
		<category><![CDATA[用户需求]]></category>
		<category><![CDATA[设计]]></category>

		<guid isPermaLink="false">http://www.shimuuu.com/?p=802</guid>
		<description><![CDATA[交互设计不是在控件库里挑选合适的控件，这是我最近工作中的一个感受。线上应用的环境复杂多变，不一而足，很多在书本或别人的实践中看起来合理的方法，放在自己具体的环境中就会出问题。下面分享一个交互设计的小案例，这个案例很好地说明了我们在具体工作中怎么样去追求“易用”并且“轻量级”的设计，而这是影响用户体验的两个关键因素。


原设计方案中，历史记录这块是一个添加联系人控件
上图中的联系人控件功能很强大，交互设计得也不错，看图便知。用户可以在这个widget里面直接选择保存的联系人（有分组），亦可即时搜索；同时还记录最近交易的，方便有连续交易行为的用户。抛开具体环境不谈，联系人控件在这里是一个很有用的工具，它帮助用户选择转账的对象；用户不需要记忆复杂的银行账户信息，只用记得对方的用户名就可以，用户体验应该是不错的。
但是在具体应用环境中呢？
文章开头的那张图是一个刚上线的新产品截图。我们来分析一下，用户在使用一个刚上线的新产品的时候，是否有从联系人中选择的需求呢？实际情况很可能就是大部分用户在两三个星期内只使用过一次这个产品，因为它不是普通用户日常所必须的。少数用户会使用过至多4-5次，如果到了10次，那这个产品无疑收获了巨大的成功，显然在短期内这是不可能的。因而，在可以预见的时期内，用户的联系人控件中只有1-2个联系人，之多4-5个，这样的话联系人控件在这里还有必要么？
如果结论是没有必要的话，联系人控件放在这里其实在交互上并没有消极的影响（用户只不过从有限的几个联系人中选择了一个而已，一样可以不需记忆复杂信息来完成任务）。但它对页面性能（载入速度）却是有影响的，这样一个联系人控件其实是调用了好几个js文件，而对于一个刚出生的新产品来说，页面性能是很关键的一个指标，太多的例子表明，页面载入速度如果提高个一两秒，用户的感受会好许多，自然而然商业价值也会提升。
有没有替代方案？
替代方案就是文章开头的那张图中的历史记录下拉框。这个方案在记录不超过10条的时候会很好用，轻量级且明显，没有多余的（用户在还处于初级阶段时候用不到的功能，比如：联系人分组，搜索等）。如果不考虑安全因素的话，这个历史记录的方案可以非常方便地用cookie来实现；在实际情况中，为了避免银行卡信息泄漏所用到的解决方案也是相当轻量级的。在用户第一次使用时，可以隐去历史记录；而用户下次再来的时候，则把历史记录放出来。等到用户成为“高级用户”了，拥有许多联系人（至少10+），并且将联系人分组了，这时我们可以对产品进行升级，将强大无比的联系人控件放出来供用户使用，这样的用户体验会是很好的。而这也是产品迭代的敏捷开发思想的体现。
本文的小例子绝对不是best practice。交互设计绝不是很多人看来画画白板，选选控件这样机械的活。书本上的知识运用到实践中，需要相当的经验积累以及敏锐的洞察力，这些才是交互设计师的财富。大家如果有好的交互设计经验，也请分享给大家哦。类似的网志，挑你喜欢的看：

从需求到功能再到实现
网页设计师也该关注页面性能
设记系列：Draware手机界面设计
Draware概念手机界面的flash演示
设计中的边际效应


]]></description>
			<content:encoded><![CDATA[<p>交互设计不是在控件库里挑选合适的控件，这是我最近工作中的一个感受。线上应用的环境复杂多变，不一而足，很多在书本或别人的实践中看起来合理的方法，放在自己具体的环境中就会出问题。下面分享一个交互设计的小案例，这个案例很好地说明了我们在具体工作中怎么样去追求“易用”并且“轻量级”的设计，而这是影响用户体验的两个关键因素。</p>
<p><a class="imglink" rel="attachment wp-att-803" href="http://www.shimuuu.com/blog/interaction-design-easy-to-use-and-light-weight/attachment/history_record"><img class="hasimg" title="history_record" src="http://www.shimuuu.com/wp-content/uploads/2010/05/history_record.jpg" alt="history_record" width="489" height="122" /></a></p>
<p><span id="more-802"></span></p>
<h4>原设计方案中，历史记录这块是一个添加联系人控件</h4>
<p>上图中的联系人控件功能很强大，交互设计得也不错，看图便知。用户可以在这个widget里面直接选择保存的联系人（有分组），亦可即时搜索；同时还记录最近交易的，方便有连续交易行为的用户。抛开具体环境不谈，联系人控件在这里是一个很有用的工具，它帮助用户选择转账的对象；用户不需要记忆复杂的银行账户信息，只用记得对方的用户名就可以，用户体验应该是不错的。</p>
<h4>但是在具体应用环境中呢？</h4>
<p>文章开头的那张图是一个刚上线的新产品截图。我们来分析一下，用户在使用一个刚上线的新产品的时候，是否有从联系人中选择的需求呢？实际情况很可能就是大部分用户在两三个星期内只使用过一次这个产品，因为它不是普通用户日常所必须的。少数用户会使用过至多4-5次，如果到了10次，那这个产品无疑收获了巨大的成功，显然在短期内这是不可能的。因而，在可以预见的时期内，用户的联系人控件中只有1-2个联系人，之多4-5个，这样的话联系人控件在这里还有必要么？</p>
<p>如果结论是没有必要的话，联系人控件放在这里其实在交互上并没有消极的影响（用户只不过从有限的几个联系人中选择了一个而已，一样可以不需记忆复杂信息来完成任务）。但它对页面性能（载入速度）却是有影响的，这样一个联系人控件其实是调用了好几个js文件，而对于一个刚出生的新产品来说，页面性能是很关键的一个指标，太多的例子表明，页面载入速度如果提高个一两秒，用户的感受会好许多，自然而然商业价值也会提升。</p>
<h4>有没有替代方案？</h4>
<p>替代方案就是文章开头的那张图中的历史记录下拉框。这个方案在记录不超过10条的时候会很好用，轻量级且明显，没有多余的（用户在还处于初级阶段时候用不到的功能，比如：联系人分组，搜索等）。如果不考虑安全因素的话，这个历史记录的方案可以非常方便地用cookie来实现；在实际情况中，为了避免银行卡信息泄漏所用到的解决方案也是相当轻量级的。在用户第一次使用时，可以隐去历史记录；而用户下次再来的时候，则把历史记录放出来。等到用户成为“高级用户”了，拥有许多联系人（至少10+），并且将联系人分组了，这时我们可以对产品进行升级，将强大无比的联系人控件放出来供用户使用，这样的用户体验会是很好的。而这也是产品迭代的敏捷开发思想的体现。</p>
<p>本文的小例子绝对不是<abbr title="最佳实践">best practice</abbr>。交互设计绝不是很多人看来画画白板，选选控件这样机械的活。书本上的知识运用到实践中，需要相当的经验积累以及敏锐的洞察力，这些才是交互设计师的财富。大家如果有好的交互设计经验，也请<a href="#comment">分享</a>给大家哦。<strong>类似的网志，挑你喜欢的看：</strong>
<ul class="similar-posts">
<li><a href="http://www.shimuuu.com/blog/%e4%bb%8e%e9%9c%80%e6%b1%82%e5%88%b0%e5%8a%9f%e8%83%bd%e5%86%8d%e5%88%b0%e5%ae%9e%e7%8e%b0" rel="bookmark" title="07/31/2009">从需求到功能再到实现</a></li>
<li><a href="http://www.shimuuu.com/blog/web-designer-should-focus-on-page-speed" rel="bookmark" title="06/12/2010">网页设计师也该关注页面性能</a></li>
<li><a href="http://www.shimuuu.com/blog/design-series-draware-concept-mobile-ui-design-brief" rel="bookmark" title="07/27/2009">设记系列：Draware手机界面设计</a></li>
<li><a href="http://www.shimuuu.com/blog/draware-concept-mobile-ui-flash" rel="bookmark" title="04/23/2010">Draware概念手机界面的flash演示</a></li>
<li><a href="http://www.shimuuu.com/blog/magrginal-utility-in-design" rel="bookmark" title="07/09/2010">设计中的边际效应</a></li>
</ul>
<p><!-- Similar Posts took 11.573 ms --></p>
]]></content:encoded>
			<wfw:commentRss>http://www.shimuuu.com/blog/interaction-design-easy-to-use-and-light-weight/feed</wfw:commentRss>
		<slash:comments>18</slash:comments>
		</item>
		<item>
		<title>从需求到功能再到实现</title>
		<link>http://www.shimuuu.com/blog/%e4%bb%8e%e9%9c%80%e6%b1%82%e5%88%b0%e5%8a%9f%e8%83%bd%e5%86%8d%e5%88%b0%e5%ae%9e%e7%8e%b0</link>
		<comments>http://www.shimuuu.com/blog/%e4%bb%8e%e9%9c%80%e6%b1%82%e5%88%b0%e5%8a%9f%e8%83%bd%e5%86%8d%e5%88%b0%e5%ae%9e%e7%8e%b0#comments</comments>
		<pubDate>Fri, 31 Jul 2009 15:38:49 +0000</pubDate>
		<dc:creator>shimu</dc:creator>
				<category><![CDATA[blog]]></category>
		<category><![CDATA[思索]]></category>
		<category><![CDATA[UCD]]></category>
		<category><![CDATA[UED]]></category>
		<category><![CDATA[交互]]></category>
		<category><![CDATA[用户体验]]></category>
		<category><![CDATA[用户需求]]></category>

		<guid isPermaLink="false">http://iamfrompluto.cn/?p=42</guid>
		<description><![CDATA[最近挤出一点时间来回味了一下自己这半年来做的设计，除了毕设之外，就是Zozoc的项目了。
一，背景
在Trilogy实习的时候，在Zozoc这个项目中做设计。事实上当时这个项目的business goal已经很迫在眉睫了。当时Zozoc还没有收费，通过viral提高的UV每周在60%左右，下载产品的用户只占UV的20%，但用户流失率却在50%以上，可以说用户黏度是非常之低。
而项目可以利用的资源也是不容乐观，当时我们有web/wap/sms几个可以利用的资源，其中web方面由于人力原因，项目老大就排除了这个资源。也就是说，我们需要赶在Zozoc收费之前，近1个月的时间，将UV的增长率提高到50%以上，conversion rate要到60%，而用户流失率降低为10%以下，而能利用的资源是wap和sms。

二，前期的挫折
可以说自从我开始接触项目实践以来，这次是压力最大的。每天都在与PM和老大沟通。Goal是非常的清晰了，基本的用户需求其实早已明确，就是用“免费”的短信，或者是说比传统短信通道资费更便宜的短信。但何以用户来到我们的web或者wap之后下载的却不多？而下载产品后流失的却这么多？
如果我们的产品足够好，用户也有这样的需求，按照道理是不会出现这样的问题。毛病在哪？一开始我们认为用户可能不了解我们的产品，对Zozoc的优势并没有清晰的认识，因而都成了inactive user。所以通过brain storming，我们制定了一份通过sms来推广的plan。这份plan具体内容是通过短信通道向下载过Zozoc的用户发送软广告，内容多种多样，极尽勾引之能事。
同时，我也负责改进我们的wap站点，显然，原有的版本并没有基于用户更多的考虑，而是站在我们产品本身的角度来设计的。但这时由于时间紧迫，并没有很多时间来改进设计，只能在原有的基础上增加一些可用性，而这些可用性实际上仍然是架空在用户会花上5秒停留的前提上。
结果很显然，第一次改进并没有取得多少实质上的进展。UV只提高了3%，conversion data维持不变，用户流失率略有下降。
三，反思
事后分析，我们应该是从一开始需求定位上就有错误。的确，我们的目标用户是喜欢免费短信的。相当数量的人在使用各种各样的免费短信软件（当然，随着当时SNS的热潮，很多软件公司也挺进，我当时也头脑很热，认为这是提高我们用户黏性的一个好办法，还向PM提出过，现在看来，这很荒谬）。对于免费短信相关的网关质量、通道质量和客服服务等，用户都有相当的需求。但这些仍然是大的需求，用户为什么会不用我们的软件？这恐怕曾经困扰过很多互联网业从业者。一个产品做出来，设计开发的人自信满满，这么优秀的软件肯定能得到用户们的喜欢！然而结果却很让人失望和伤心，甚至是委屈。究其原因，是我们并没有真正明白用户的需求。
用户的需求80%以上都不是问出来的。我试过问很多身边的朋友和同学，用哪些免费短信软件，即便飞信发其他运营商的手机要收钱，你们为什么仍然要用？答案让我大吃一惊，除去网关、通道质量这些正常的原因之外，很多人都不出个所以然来，为什么自己会执着于飞信。而我向他们介绍Zozoc时，他们更是吃惊的说，原来不同运营商之间发短信也是可以免费的！
问题到这里，实际上有些明白了，原来我们并没有找到细化之后的用户需求来进行改进。还有很多细化的需求：用户可能并不知道自己的手机应该安装哪个Zozoc版本；如果下错了安装包，安装过程中出现了问题，用户可能就会认为这是个骗子软件等等等等。站在产品架构的角度上，对用户的经过细分的需求进行分析，才是可行的出发点。
四，执行
新的plan比起原来的要进步很多，在sms软广告上面，针对很多不同用户的需求，设计了很多短信内容。也提出了用户等级系统，积分奖励等等。用户其实很好玩，虚拟头衔一直是吸引用户的一个大因素，而积分，就算在当前没有多大用处，但是在广告中提到众多用户爱好的东西（从BBS上的帖子搜刮而来），用户也是相当喜欢。而对于那些从来没有用过Zozoc的用户，我们也设置了很多应用情景，通过短信发给他们，让他们尝试着使用。
在wap改进设计方面，更是细化了很多用户的需求。用户不知道自己手机该装哪个version的Zozoc，在经过数据分析后是个大头（从选择版本安装的页面跳出的用户占70%以上）。于是我们决定开发一个automatic-installation的功能，这也是非常符合Zozoc特色的功能，真正care users。同时这个功能的exception handlement也是设计得相当完善，考虑到了不同的场景。这个功能开发出来后，用户只需要访问wap站点，就能自动提示安装正确版本的Zozoc到自己的手机上，中间如果出了一系列问题，则会有向导帮助用户完成版本的手动选择。
同时也在wap站点上加入了很多为用户需求设计的功能，broadcast sms/blessing sms/joke sms/special contact，这些功能都是在这段时间集体爆发出来的点子，给了用户更多的发免费短信的理由。
在设计的过程中，也在不断的和工程师沟通，确保这些功能都能开发出来。实现应用环境的限制实际上也削去了很多不必要的设计累赘，我感觉这种经验是弥足珍贵的。我们往往可以设计出功能不错的产品，但最简洁最符合用户使用习惯的产品却不多。
五，总结
以前总说以用户为中心的设计，而我感觉UCD更应该是从用户需求开始的设计，用户这个中心点不应该靠后，而应该在产品设计最前端的位置，从一开始就指导整个产品设计的流程。
比较让人遗憾的是我由于毕业设计的原因，在项目目标未完成的情况下不得不离开了Trilogy。幸而在后来听PM说，这个plan成功完成了预期的目标，这简直让我下巴掉地上去了。之前我经常挂在口上的是这项目肯定完成不了，Zozoc可能要完了。我非常高兴，同时也带点儿自豪，为这个项目付出了相当多的精力，有此回报，我也很满足。现在Zozoc再次改版，因为开始收费了，我也帮忙做一下visual design。希望Zozoc能就此成熟起来，毕竟一个有“收入”的软件才是真正给用户高质量服务的，才是真正运转的。
P.S. 有兴趣的可以手机登录wap.zozoc.com来看看wap页面，或者用http://a1.timewe.net这个地址来在电脑上浏览类似的网志，挑你喜欢的看：

易用且轻量级的交互设计
QQ2010beta3内置的腾讯微博体验感受
Draware概念手机界面的flash演示
设计系列：Draware是怎么炼成的（1）
网页设计师也该关注页面性能


]]></description>
			<content:encoded><![CDATA[<p>最近挤出一点时间来回味了一下自己这半年来做的设计，除了毕设之外，就是Zozoc的项目了。</p>
<p><strong>一，背景</strong></p>
<p>在Trilogy实习的时候，在<a href="http://www.zozoc.com">Zozoc</a>这个项目中做设计。事实上当时这个项目的business goal已经很迫在眉睫了。当时Zozoc还没有收费，通过viral提高的UV每周在60%左右，下载产品的用户只占UV的20%，但用户流失率却在50%以上，可以说用户黏度是非常之低。</p>
<p>而项目可以利用的资源也是不容乐观，当时我们有web/wap/sms几个可以利用的资源，其中web方面由于人力原因，项目老大就排除了这个资源。也就是说，我们需要赶在Zozoc收费之前，近1个月的时间，将UV的增长率提高到50%以上，conversion rate要到60%，而用户流失率降低为10%以下，而能利用的资源是wap和sms。</p>
<p><span id="more-42"></span></p>
<p><strong>二，前期的挫折</strong></p>
<p>可以说自从我开始接触项目实践以来，这次是压力最大的。每天都在与PM和老大沟通。Goal是非常的清晰了，基本的用户需求其实早已明确，就是用“免费”的短信，或者是说比传统短信通道资费更便宜的短信。但何以用户来到我们的web或者wap之后下载的却不多？而下载产品后流失的却这么多？</p>
<p>如果我们的产品足够好，用户也有这样的需求，按照道理是不会出现这样的问题。毛病在哪？一开始我们认为用户可能不了解我们的产品，对Zozoc的优势并没有清晰的认识，因而都成了inactive user。所以通过brain storming，我们制定了一份通过sms来推广的plan。这份plan具体内容是通过短信通道向下载过Zozoc的用户发送软广告，内容多种多样，极尽勾引之能事。</p>
<p>同时，我也负责改进我们的wap站点，显然，原有的版本并没有基于用户更多的考虑，而是站在我们产品本身的角度来设计的。但这时由于时间紧迫，并没有很多时间来改进设计，只能在原有的基础上增加一些可用性，而这些可用性实际上仍然是架空在用户会花上5秒停留的前提上。</p>
<p>结果很显然，第一次改进并没有取得多少实质上的进展。UV只提高了3%，conversion data维持不变，用户流失率略有下降。</p>
<p><strong>三，反思</strong></p>
<p>事后分析，我们应该是从一开始需求定位上就有错误。的确，我们的目标用户是喜欢免费短信的。相当数量的人在使用各种各样的免费短信软件（当然，随着当时SNS的热潮，很多软件公司也挺进，我当时也头脑很热，认为这是提高我们用户黏性的一个好办法，还向PM提出过，现在看来，这很荒谬）。对于免费短信相关的网关质量、通道质量和客服服务等，用户都有相当的需求。但这些仍然是大的需求，用户为什么会不用我们的软件？这恐怕曾经困扰过很多互联网业从业者。一个产品做出来，设计开发的人自信满满，这么优秀的软件肯定能得到用户们的喜欢！然而结果却很让人失望和伤心，甚至是委屈。究其原因，是我们并没有真正明白用户的需求。</p>
<p>用户的需求80%以上都不是问出来的。我试过问很多身边的朋友和同学，用哪些免费短信软件，即便飞信发其他运营商的手机要收钱，你们为什么仍然要用？答案让我大吃一惊，除去网关、通道质量这些正常的原因之外，很多人都不出个所以然来，为什么自己会执着于飞信。而我向他们介绍Zozoc时，他们更是吃惊的说，原来不同运营商之间发短信也是可以免费的！</p>
<p>问题到这里，实际上有些明白了，原来我们并没有找到细化之后的用户需求来进行改进。还有很多细化的需求：用户可能并不知道自己的手机应该安装哪个Zozoc版本；如果下错了安装包，安装过程中出现了问题，用户可能就会认为这是个骗子软件等等等等。站在产品架构的角度上，对用户的经过细分的需求进行分析，才是可行的出发点。</p>
<p><strong>四，执行</strong></p>
<p>新的plan比起原来的要进步很多，在sms软广告上面，针对很多不同用户的需求，设计了很多短信内容。也提出了用户等级系统，积分奖励等等。用户其实很好玩，虚拟头衔一直是吸引用户的一个大因素，而积分，就算在当前没有多大用处，但是在广告中提到众多用户爱好的东西（从BBS上的帖子搜刮而来），用户也是相当喜欢。而对于那些从来没有用过Zozoc的用户，我们也设置了很多应用情景，通过短信发给他们，让他们尝试着使用。</p>
<p>在wap改进设计方面，更是细化了很多用户的需求。用户不知道自己手机该装哪个<span id="SenderName">version的Zozoc，在经过数据分析后是个大头（从选择版本安装的页面跳出的用户占70%以上）。于是我们决定开发一个automatic-installation的功能，这也是非常符合Zozoc特色的功能，真正care users。同时这个功能的exception handlement也是设计得相当完善，考虑到了不同的场景。这个功能开发出来后，用户只需要访问wap站点，就能自动提示安装正确版本的Zozoc到自己的手机上，中间如果出了一系列问题，则会有向导帮助用户完成版本的手动选择。</span></p>
<p><span>同时也在wap站点上加入了很多为用户需求设计的功能，broadcast sms/blessing sms/joke sms/special contact，这些功能都是在这段时间集体爆发出来的点子，给了用户更多的发免费短信的理由。</span></p>
<p><span>在设计的过程中，也在不断的和工程师沟通，确保这些功能都能开发出来。实现应用环境的限制实际上也削去了很多不必要的设计累赘，我感觉这种经验是弥足珍贵的。我们往往可以设计出功能不错的产品，但最简洁最符合用户使用习惯的产品却不多。</span></p>
<p><span><strong>五，总结</strong></span></p>
<p><span>以前总说以用户为中心的设计，而我感觉UCD更应该是从用户需求开始的设计，用户这个中心点不应该靠后，而应该在产品设计最前端的位置，从一开始就指导整个产品设计的流程。</span></p>
<p><span>比较让人遗憾的是我由于毕业设计的原因，在项目目标未完成的情况下不得不离开了Trilogy。幸而在后来听PM说，这个plan成功完成了预期的目标，这简直让我下巴掉地上去了。之前我经常挂在口上的是这项目肯定完成不了，Zozoc可能要完了。我非常高兴，同时也带点儿自豪，为这个项目付出了相当多的精力，有此回报，我也很满足。现在Zozoc再次改版，因为开始收费了，我也帮忙做一下visual design。希望Zozoc能就此成熟起来，毕竟一个有“收入”的软件才是真正给用户高质量服务的，才是真正运转的。</span></p>
<p><span>P.S. 有兴趣的可以手机登录wap.zozoc.com来看看wap页面，或者用</span><a href="http://a1.timewe.net" target="_blank">http://a1.timewe.net</a>这个地址来在电脑上浏览<strong>类似的网志，挑你喜欢的看：</strong>
<ul class="similar-posts">
<li><a href="http://www.shimuuu.com/blog/interaction-design-easy-to-use-and-light-weight" rel="bookmark" title="05/10/2010">易用且轻量级的交互设计</a></li>
<li><a href="http://www.shimuuu.com/blog/qq2010beta3-built-in-t-qq-com" rel="bookmark" title="04/26/2010">QQ2010beta3内置的腾讯微博体验感受</a></li>
<li><a href="http://www.shimuuu.com/blog/draware-concept-mobile-ui-flash" rel="bookmark" title="04/23/2010">Draware概念手机界面的flash演示</a></li>
<li><a href="http://www.shimuuu.com/blog/design-series-draware-concept-mobile-ui-design" rel="bookmark" title="08/06/2009">设计系列：Draware是怎么炼成的（1）</a></li>
<li><a href="http://www.shimuuu.com/blog/web-designer-should-focus-on-page-speed" rel="bookmark" title="06/12/2010">网页设计师也该关注页面性能</a></li>
</ul>
<p><!-- Similar Posts took 13.107 ms --></p>
]]></content:encoded>
			<wfw:commentRss>http://www.shimuuu.com/blog/%e4%bb%8e%e9%9c%80%e6%b1%82%e5%88%b0%e5%8a%9f%e8%83%bd%e5%86%8d%e5%88%b0%e5%ae%9e%e7%8e%b0/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->
