<?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; Planning</title>
	<atom:link href="http://blog.planism.com/archives/category/my/planning/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.planism.com</link>
	<description>當人文超越了科技，我們的夢想才能駕馭未來</description>
	<lastBuildDate>Fri, 13 Jan 2012 02:43:16 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>[摘錄] Feature 和 Function的差別</title>
		<link>http://blog.planism.com/archives/2012/01/02/3727/%e6%91%98%e9%8c%84-feature-%e5%92%8c-function%e7%9a%84%e5%b7%ae%e5%88%a5</link>
		<comments>http://blog.planism.com/archives/2012/01/02/3727/%e6%91%98%e9%8c%84-feature-%e5%92%8c-function%e7%9a%84%e5%b7%ae%e5%88%a5#comments</comments>
		<pubDate>Mon, 02 Jan 2012 03:11:00 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>
		<category><![CDATA[prd]]></category>
		<category><![CDATA[spec]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2012/01/02/3727/%e6%91%98%e9%8c%84-feature-%e5%92%8c-function%e7%9a%84%e5%b7%ae%e5%88%a5</guid>
		<description><![CDATA[出處：English Vincent feature,本意還是特點，指有鮮明特徵的方面。function則強調產品目的和用途。你上面所據的例子其實還是在描述ipad的特點。只是很多產品，特別是消費數字產品，它的特點也正好是其所包含的多種功能。其實，在傳統產品中是很容易區分feature和function的。比如說自行車，它的功能很少有人再描述，而特點不外乎foldable, serviceable,alloy wheels之類的東西。 我個人覺得，為什麼在介紹產品時很少看到用function，是因為日常產品的基本功能無人不知，只是特點有所不同。比如買手機，我當然知道是用來打電話的，我想知道的只是與眾不同的features，這時一般的問題是&#34;what&#8217;s the difference?&#34;。但假設你在介紹一個全新開發的又沒人認識的東西時，我想function是必須要先予說明的，這時的問題是&#34;what&#8217;s this?&#34;。 Feature：特點、特徵，What’s the difference? Function：功能、用途，What’s this? 其實，硬要區分兩者的不同，是沒什麼必要。但在寫網站企劃的文件時，兩者分一下，不僅有助於企劃者撰寫，也有助於閱讀者理解。]]></description>
			<content:encoded><![CDATA[<blockquote><p>出處：<a href="http://www.englishvincent.com/?p=171">English Vincent</a></p>
<p>feature,本意還是特點，指有鮮明特徵的方面。function則強調產品目的和用途。你上面所據的例子其實還是在描述ipad的特點。只是很多產品，特別是消費數字產品，它的特點也正好是其所包含的多種功能。其實，在傳統產品中是很容易區分feature和function的。比如說自行車，它的功能很少有人再描述，而特點不外乎foldable, serviceable,alloy wheels之類的東西。</p>
<p>我個人覺得，為什麼在介紹產品時很少看到用function，是因為日常產品的基本功能無人不知，只是特點有所不同。比如買手機，我當然知道是用來打電話的，我想知道的只是與眾不同的features，這時一般的問題是&quot;what&#8217;s the difference?&quot;。但假設你在介紹一個全新開發的又沒人認識的東西時，我想function是必須要先予說明的，這時的問題是&quot;what&#8217;s this?&quot;。</p>
</blockquote>
<ul>
<li>Feature：特點、特徵，What’s the difference? </li>
<li>Function：功能、用途，What’s this? </li>
</ul>
<p>其實，硬要區分兩者的不同，是沒什麼必要。但在寫網站企劃的文件時，兩者分一下，不僅有助於企劃者撰寫，也有助於閱讀者理解。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2012/01/02/3727/%e6%91%98%e9%8c%84-feature-%e5%92%8c-function%e7%9a%84%e5%b7%ae%e5%88%a5/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 學習騰訊的產品管理之道</title>
		<link>http://blog.planism.com/archives/2009/12/03/2788/%e6%91%98%e9%8c%84-%e5%ad%b8%e7%bf%92%e9%a8%b0%e8%a8%8a%e7%9a%84%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86%e4%b9%8b%e9%81%93</link>
		<comments>http://blog.planism.com/archives/2009/12/03/2788/%e6%91%98%e9%8c%84-%e5%ad%b8%e7%bf%92%e9%a8%b0%e8%a8%8a%e7%9a%84%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86%e4%b9%8b%e9%81%93#comments</comments>
		<pubDate>Thu, 03 Dec 2009 01:00:00 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2009/12/03/2788/%e6%91%98%e9%8c%84-%e5%ad%b8%e7%bf%92%e9%a8%b0%e8%a8%8a%e7%9a%84%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86%e4%b9%8b%e9%81%93</guid>
		<description><![CDATA[出處：cnBeta.com 馬化騰帶著一大批產品高管自上而下，持之以恆地推動產品本位的管理體制規範化，並不斷地創新和優化這套體制，使得整個公司上上下下融入了「產品的基因」，最終成就了「產品的騰訊」。 1、設置一個質量監控小組，由經驗非常豐富的高Level的產品人員構成，賦予他們很大的權力，去監控和規範所有的產品項目。並且用KPI來制約產品項目服從這些規範。為了不搞教條主義，很多規範都是在立項之初，由項目經理和這個小組共同確認的，未必是硬性指派，一經確認就受到嚴格監控。確保好的規範不流於空喊口號。 2、每個產品都設置公開的反饋論壇，突出外部入口，積極徵詢用戶意見，並以內部輪班方式回覆「每一條」有價值的反饋，要求以「人對人，面對面」的溝通態度來進行解答，禁止機械問答。公司高層（包括小馬哥）不定期巡查每一個產品論壇，一旦發現有不認真回覆用戶的情況，立即予以訓誡。確保產品人員與用戶長期保持近距離接觸。 3、每個產品都設置內部的交流平台，分為兩部分，一塊類似留言板，由產品主管發佈項目的進度、動態；另一塊是論壇，向公司內部所有人開放，接納反饋。在騰訊內部已經形成了非常活躍的氛圍，甚至以該平台人氣高漲為榮（至少你主管會喜歡這個），利用這個平台跨項目提意見，或是項目組內部交流思維碎片都很常見，達到了群策群力，內部監督的效果。 4、設置產品架構師這樣一個職位，由少數幾個技術精英，負責所有項目的系統架構搭建，只搭架構，確保每個項目的底層合理性。 5、執行項目總結制度，在每個版本上線後，由相應的策劃-開發-測試人員開一個會，每個人都總結在這個版本過程裡，有什麼心得，有什麼失誤，可以怎麼改善，尤其注意改進三方人員的配合過程。用制度的方式來強制反省，強制跨職能溝通。幾個版本下來，項目效率就會有明顯的提高。 6、執行灰度發佈政策非常之徹底，一個版本會經過若干級的內部測試，再向外部用戶逐步放量升級，不斷修正問題之後，最後進行大規模發佈。確保提前發現問題，受影響的用戶面儘可能小。與此同時，騰訊異常活躍的內部交流氛圍，也能讓產品在內部測試時得到較多專業反饋。 7、擁有背靠客戶端，強大的數據挖掘功能，具體描述起來比較複雜，總之非常強大，數據細緻到令人吃驚的地步。數據挖掘部門的地位也是相當高的。我以前說過「統計數據太單薄無法推導出可靠結果」這樣的話，但在騰訊的數據挖掘機能面前，這句話恐怕要改口。 8、設置對新人和新項目的風險管理機制，比如3個老程序員帶1個新程序員，將技術管理和具體開發的工作徹底分離，每週進行代碼走讀，對新產品採取格外嚴格的測試安排等等，使得缺乏經驗帶來的技術損害被降至最低。 滿不可思議的~]]></description>
			<content:encoded><![CDATA[<blockquote><p>出處：<a href="http://www.cnbeta.com/articles/95745.htm">cnBeta.com</a></p>
<p>馬化騰帶著一大批產品高管自上而下，持之以恆地推動產品本位的管理體制規範化，並不斷地創新和優化這套體制，使得整個公司上上下下融入了「產品的基因」，最終成就了「產品的騰訊」。</p>
<p>1、設置一個質量監控小組，由經驗非常豐富的高Level的產品人員構成，賦予他們很大的權力，去監控和規範所有的產品項目。並且用KPI來制約產品項目服從這些規範。為了不搞教條主義，很多規範都是在立項之初，由項目經理和這個小組共同確認的，未必是硬性指派，一經確認就受到嚴格監控。確保好的規範不流於空喊口號。</p>
<p>2、每個產品都設置公開的反饋論壇，突出外部入口，積極徵詢用戶意見，並以內部輪班方式回覆「每一條」有價值的反饋，要求以「人對人，面對面」的溝通態度來進行解答，禁止機械問答。公司高層（包括小馬哥）不定期巡查每一個產品論壇，一旦發現有不認真回覆用戶的情況，立即予以訓誡。確保產品人員與用戶長期保持近距離接觸。</p>
<p>3、每個產品都設置內部的交流平台，分為兩部分，一塊類似留言板，由產品主管發佈項目的進度、動態；另一塊是論壇，向公司內部所有人開放，接納反饋。在騰訊內部已經形成了非常活躍的氛圍，甚至以該平台人氣高漲為榮（至少你主管會喜歡這個），利用這個平台跨項目提意見，或是項目組內部交流思維碎片都很常見，達到了群策群力，內部監督的效果。</p>
<p>4、設置產品架構師這樣一個職位，由少數幾個技術精英，負責所有項目的系統架構搭建，只搭架構，確保每個項目的底層合理性。</p>
<p>5、執行項目總結制度，在每個版本上線後，由相應的策劃-開發-測試人員開一個會，每個人都總結在這個版本過程裡，有什麼心得，有什麼失誤，可以怎麼改善，尤其注意改進三方人員的配合過程。用制度的方式來強制反省，強制跨職能溝通。幾個版本下來，項目效率就會有明顯的提高。</p>
<p>6、執行灰度發佈政策非常之徹底，一個版本會經過若干級的內部測試，再向外部用戶逐步放量升級，不斷修正問題之後，最後進行大規模發佈。確保提前發現問題，受影響的用戶面儘可能小。與此同時，騰訊異常活躍的內部交流氛圍，也能讓產品在內部測試時得到較多專業反饋。</p>
<p>7、擁有背靠客戶端，強大的數據挖掘功能，具體描述起來比較複雜，總之非常強大，數據細緻到令人吃驚的地步。數據挖掘部門的地位也是相當高的。我以前說過「統計數據太單薄無法推導出可靠結果」這樣的話，但在騰訊的數據挖掘機能面前，這句話恐怕要改口。</p>
<p>8、設置對新人和新項目的風險管理機制，比如3個老程序員帶1個新程序員，將技術管理和具體開發的工作徹底分離，每週進行代碼走讀，對新產品採取格外嚴格的測試安排等等，使得缺乏經驗帶來的技術損害被降至最低。</p>
</blockquote>
<p>滿不可思議的~</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2009/12/03/2788/%e6%91%98%e9%8c%84-%e5%ad%b8%e7%bf%92%e9%a8%b0%e8%a8%8a%e7%9a%84%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86%e4%b9%8b%e9%81%93/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] Linkedin創始人霍夫曼：成功的三個秘訣</title>
		<link>http://blog.planism.com/archives/2009/12/02/2787/%e6%91%98%e9%8c%84-linkedin%e5%89%b5%e5%a7%8b%e4%ba%ba%e9%9c%8d%e5%a4%ab%e6%9b%bc%ef%bc%9a%e6%88%90%e5%8a%9f%e7%9a%84%e4%b8%89%e5%80%8b%e7%a7%98%e8%a8%a3</link>
		<comments>http://blog.planism.com/archives/2009/12/02/2787/%e6%91%98%e9%8c%84-linkedin%e5%89%b5%e5%a7%8b%e4%ba%ba%e9%9c%8d%e5%a4%ab%e6%9b%bc%ef%bc%9a%e6%88%90%e5%8a%9f%e7%9a%84%e4%b8%89%e5%80%8b%e7%a7%98%e8%a8%a3#comments</comments>
		<pubDate>Wed, 02 Dec 2009 02:00:00 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2009/12/02/2787/%e6%91%98%e9%8c%84-linkedin%e5%89%b5%e5%a7%8b%e4%ba%ba%e9%9c%8d%e5%a4%ab%e6%9b%bc%ef%bc%9a%e6%88%90%e5%8a%9f%e7%9a%84%e4%b8%89%e5%80%8b%e7%a7%98%e8%a8%a3</guid>
		<description><![CDATA[出處：新浪科技 我意識到未來的世界將受到兩股力量的作用。 一股力量是工作環境將如何變化——從某種程度上說，每個人都可以成為創業者。 另外一股力量則是互聯網，這些人都可以在網上建立資料，以便其他人可以找到他們。你可以通過網絡，和人進行溝通，更好地規劃你的發展道路。 分享成功秘密 1、合理高效安排時間 當人們問我如何在工作和生活之間實現平衡時，我只會微笑置之。我會高效安排我的時間，安排會議時間不超過15分鐘。我還努力著讓人們瞭解，一封簡短的電子郵件並不是冷漠的表現。 2、靈活調整計劃 企業家總是認為，「嗯，我已經做了決定，那就堅持到底，絕不放棄。」但我建議他們認真考慮一下，他們的商業計劃是否真的無可指摘，他們是否需要作出改變。根據現實靈活調整計劃，你才不會盲目從事一個項目五年，最後才無奈接受失敗。 3、別做完美主義者 我經常對互聯網企業家說，「如果你總是對產品吹毛求疵，那麼你的產品肯定已經推出的太晚了。」作為一家企業，你有必要盡快推出產品，和消費者進行溝通，瞭解他們的意見反饋。這有助於指引你的發展。 別做完美主義者，嗯~ 看狀況。]]></description>
			<content:encoded><![CDATA[<blockquote><p>出處：<a href="http://tech.sina.com.cn/i/2009-08-25/22163383126.shtml">新浪科技</a></p>
<p>我意識到未來的世界將受到兩股力量的作用。</p>
<p>一股力量是工作環境將如何變化——從某種程度上說，每個人都可以成為創業者。</p>
<p>另外一股力量則是互聯網，這些人都可以在網上建立資料，以便其他人可以找到他們。你可以通過網絡，和人進行溝通，更好地規劃你的發展道路。</p>
<p><strong>分享成功秘密</strong></p>
<p>1、合理高效安排時間</p>
<p>當人們問我如何在工作和生活之間實現平衡時，我只會微笑置之。我會高效安排我的時間，安排會議時間不超過15分鐘。我還努力著讓人們瞭解，一封簡短的電子郵件並不是冷漠的表現。</p>
<p>2、靈活調整計劃</p>
<p>企業家總是認為，「嗯，我已經做了決定，那就堅持到底，絕不放棄。」但我建議他們認真考慮一下，他們的商業計劃是否真的無可指摘，他們是否需要作出改變。根據現實靈活調整計劃，你才不會盲目從事一個項目五年，最後才無奈接受失敗。</p>
<p>3、別做完美主義者</p>
<p>我經常對互聯網企業家說，「如果你總是對產品吹毛求疵，那麼你的產品肯定已經推出的太晚了。」作為一家企業，你有必要盡快推出產品，和消費者進行溝通，瞭解他們的意見反饋。這有助於指引你的發展。</p>
</blockquote>
<p>別做完美主義者，嗯~ 看狀況。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2009/12/02/2787/%e6%91%98%e9%8c%84-linkedin%e5%89%b5%e5%a7%8b%e4%ba%ba%e9%9c%8d%e5%a4%ab%e6%9b%bc%ef%bc%9a%e6%88%90%e5%8a%9f%e7%9a%84%e4%b8%89%e5%80%8b%e7%a7%98%e8%a8%a3/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>[摘錄] 產品管理 vs. 項目管理</title>
		<link>http://blog.planism.com/archives/2008/12/24/1822/%e6%91%98%e9%8c%84-%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86vs-%e9%a0%85%e7%9b%ae%e7%ae%a1%e7%90%86</link>
		<comments>http://blog.planism.com/archives/2008/12/24/1822/%e6%91%98%e9%8c%84-%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86vs-%e9%a0%85%e7%9b%ae%e7%ae%a1%e7%90%86#comments</comments>
		<pubDate>Wed, 24 Dec 2008 05:34:42 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/?p=1822</guid>
		<description><![CDATA[* 原文：&#8221;Jeff Lash&#8221;:http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/?PHPSESSID=ca265820eef17812d1c37c6e6682a28a * 翻譯：&#8221;hawking&#8221;:http://www.2tan.net/article.asp?id=29 項目經理的職責是在一定的目標、範圍、時間期限、預算以及其他制約條件下，試圖一次性完成一個成功的項目。一個項目經理需要分配資源，管理問題與風險，並且主要協調所有的各種必要因素以完成項目。當把他們跟產品聯繫起來時，項目也可能被要求承擔起創建一個產品，為產品提供新的特徵，或者是為產品創建新的版本或擴展的任務。當項目完成時，項目經理通常會被轉移到一個新的項目，甚至有可能是服務於一個完全不同的產品。 產品經理的職責是從頭到尾的服務一個產品，並使得產品持續成功。一旦創建產品的項目完成，而且項目經理轉移到下一個工作，產品經理依然會留下來管理產品，直至產品的整個生命週期。其他項目被聯繫到產品可能是由於產品經理的發起，產品經理會始終在產品生命週期，定義項目的目標，並帶領團隊完成擬定的商業目標。 大陸稱「項目經理」，台灣叫「專案經理」。 我負責專案，但我是產品經理。]]></description>
			<content:encoded><![CDATA[<blockquote><p>
* 原文：&#8221;Jeff Lash&#8221;:http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/?PHPSESSID=ca265820eef17812d1c37c6e6682a28a<br />
* 翻譯：&#8221;hawking&#8221;:http://www.2tan.net/article.asp?id=29</p>
<p>項目經理的職責是在一定的目標、範圍、時間期限、預算以及其他制約條件下，試圖一次性完成一個成功的項目。一個項目經理需要分配資源，管理問題與風險，並且主要協調所有的各種必要因素以完成項目。當把他們跟產品聯繫起來時，項目也可能被要求承擔起創建一個產品，為產品提供新的特徵，或者是為產品創建新的版本或擴展的任務。當項目完成時，項目經理通常會被轉移到一個新的項目，甚至有可能是服務於一個完全不同的產品。</p>
<p>產品經理的職責是從頭到尾的服務一個產品，並使得產品持續成功。一旦創建產品的項目完成，而且項目經理轉移到下一個工作，產品經理依然會留下來管理產品，直至產品的整個生命週期。其他項目被聯繫到產品可能是由於產品經理的發起，產品經理會始終在產品生命週期，定義項目的目標，並帶領團隊完成擬定的商業目標。</p></blockquote>
<p>大陸稱「項目經理」，台灣叫「專案經理」。</p>
<p>我負責專案，但我是產品經理。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2008/12/24/1822/%e6%91%98%e9%8c%84-%e7%94%a2%e5%93%81%e7%ae%a1%e7%90%86vs-%e9%a0%85%e7%9b%ae%e7%ae%a1%e7%90%86/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>[摘錄] 擁有專案團隊最快的方式</title>
		<link>http://blog.planism.com/archives/2008/11/08/1763/%e6%91%98%e9%8c%84-%e6%93%81%e6%9c%89%e5%b0%88%e6%a1%88%e5%9c%98%e9%9a%8a%e6%9c%80%e5%bf%ab%e7%9a%84%e6%96%b9%e5%bc%8f</link>
		<comments>http://blog.planism.com/archives/2008/11/08/1763/%e6%91%98%e9%8c%84-%e6%93%81%e6%9c%89%e5%b0%88%e6%a1%88%e5%9c%98%e9%9a%8a%e6%9c%80%e5%bf%ab%e7%9a%84%e6%96%b9%e5%bc%8f#comments</comments>
		<pubDate>Sat, 08 Nov 2008 07:42:04 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/?p=1763</guid>
		<description><![CDATA[&#8220;給新手PM之3 &#8211; 配置資源&#8221;:http://userxper.com/blog/archives/53 @ 悠識數位 by Richard Tsai 擁有專案團隊 (Team) 最快的方式，你知道是什麼方式嗎? 很簡單，只要僱用一個英文名字叫做 Tim 的人，就可以跟客戶宣稱我們有 Team 了。 這是一位好友在非常無奈的情境下，想出來的冷笑話，當時他就在沒有 Team 的情況下苦中作樂，才想得出這種冷笑話。 太好笑了]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;給新手PM之3 &#8211; 配置資源&#8221;:http://userxper.com/blog/archives/53 @ 悠識數位 by Richard Tsai</p>
<p>擁有專案團隊 (Team) 最快的方式，你知道是什麼方式嗎? 很簡單，只要僱用一個英文名字叫做 Tim 的人，就可以跟客戶宣稱我們有 Team 了。</p>
<p>這是一位好友在非常無奈的情境下，想出來的冷笑話，當時他就在沒有 Team 的情況下苦中作樂，才想得出這種冷笑話。</p></blockquote>
<p>太好笑了 <img src='http://blog.planism.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> </p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2008/11/08/1763/%e6%91%98%e9%8c%84-%e6%93%81%e6%9c%89%e5%b0%88%e6%a1%88%e5%9c%98%e9%9a%8a%e6%9c%80%e5%bf%ab%e7%9a%84%e6%96%b9%e5%bc%8f/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>[摘錄] web 2.0 設計指導之一：簡單</title>
		<link>http://blog.planism.com/archives/2008/10/14/1754/%e6%91%98%e9%8c%84-web-20-%e8%a8%ad%e8%a8%88%e6%8c%87%e5%b0%8e%e4%b9%8b%e4%b8%80%ef%bc%9a%e7%b0%a1%e5%96%ae</link>
		<comments>http://blog.planism.com/archives/2008/10/14/1754/%e6%91%98%e9%8c%84-web-20-%e8%a8%ad%e8%a8%88%e6%8c%87%e5%b0%8e%e4%b9%8b%e4%b8%80%ef%bc%9a%e7%b0%a1%e5%96%ae#comments</comments>
		<pubDate>Tue, 14 Oct 2008 02:56:07 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Diary]]></category>
		<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/?p=1754</guid>
		<description><![CDATA[&#8220;wowbox blog (網頁設計知識庫) &#8220;:http://www.wowbox.com.tw/blog/article.asp?id=3068 2.0風格設計代表著聚焦、乾淨和簡單，但那並不代表著要極簡主義，我們應該用少量但必需的元素去達到我們的目標； 有個原則是我一直堅持的：假如解決某個問題有兩種方案，那麼更簡單的就是更好的。 為什麼簡單更好 1. 網站和每個頁面都有目標； 2. 用戶的注意點是有限的資源； 3. 幫助用戶找到他們想要的（或讓用戶注意我們希望他們看的內容）是設計師的職責； 4. 屏幕上的元素吸引眼球，元素越多，用戶去關注的各種不同的事情就越多，同時他去關注重要內容的幾率就下降了； 5. 所以我們需要很確定的交流方式，也需要把信息噪音減少到最少，那代表著我們要找到一個盡可能少用元素的解決方案，那就是節約元素即簡單。 何時/如何讓你的設計簡單 1. 何時 始終如此 2. 如何做 有兩個方面能讓你成功做到簡單 &#8212; 在不影響效果的情況下，去掉多餘的元素 &#8212; 能達到同樣效果的可行方案中，選擇更簡單的 看起來達到完美的結果，不是沒有東西可再添加，而是沒有任何東西可被去除的時候，每當你設計的時候，有意識的把去除多餘的視覺元素作為準則。 不要把注意力特別集中在和頁面目標相關性比較小的區域，因為用戶視線在關注這些時會分散在主要內容和導航的注意力。利用視覺細節如線條、文字、形狀和顏色去傳達信息，而不僅僅是為了裝飾。 並不反對網站設計的豐富、複雜或美感性 簡單的意思：無論採用什麼方式，只要是為了讓信息傳達更順利的元素是越多越好，當然，通常你要傳達的不是硬數據，而是軟數據； 硬數據：指事實，如新聞、股票價格、列車時間或你銀行賬戶的存款…… 軟數據：涉及信息傳達的質量，如公司給人的第一印象，服務提供者是否親切，一種產品是否適合你……這些都是同樣重要的。 無論你要傳達的是硬數據還是軟數據，你都應該有意識並謹慎的使用元素數量。 原文網址：http://www.webdesignfromscratch.com/web-2.0-design-style-guide.cfm]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;wowbox blog (網頁設計知識庫) &#8220;:http://www.wowbox.com.tw/blog/article.asp?id=3068</p>
<p>2.0風格設計代表著聚焦、乾淨和簡單，但那並不代表著要極簡主義，我們應該用少量但必需的元素去達到我們的目標； 有個原則是我一直堅持的：假如解決某個問題有兩種方案，那麼更簡單的就是更好的。</p>
<p>為什麼簡單更好</p>
<p>1. 網站和每個頁面都有目標；<br />
2. 用戶的注意點是有限的資源；<br />
3. 幫助用戶找到他們想要的（或讓用戶注意我們希望他們看的內容）是設計師的職責；<br />
4. 屏幕上的元素吸引眼球，元素越多，用戶去關注的各種不同的事情就越多，同時他去關注重要內容的幾率就下降了；<br />
5. 所以我們需要很確定的交流方式，也需要把信息噪音減少到最少，那代表著我們要找到一個盡可能少用元素的解決方案，那就是節約元素即簡單。</p>
<p>何時/如何讓你的設計簡單</p>
<p>1. 何時 始終如此<br />
2. 如何做 有兩個方面能讓你成功做到簡單<br />
&#8212; 在不影響效果的情況下，去掉多餘的元素<br />
&#8212; 能達到同樣效果的可行方案中，選擇更簡單的</p>
<p>看起來達到完美的結果，不是沒有東西可再添加，而是沒有任何東西可被去除的時候，每當你設計的時候，有意識的把去除多餘的視覺元素作為準則。</p>
<p>不要把注意力特別集中在和頁面目標相關性比較小的區域，因為用戶視線在關注這些時會分散在主要內容和導航的注意力。利用視覺細節如線條、文字、形狀和顏色去傳達信息，而不僅僅是為了裝飾。</p>
<p>並不反對網站設計的豐富、複雜或美感性</p>
<p>簡單的意思：無論採用什麼方式，只要是為了讓信息傳達更順利的元素是越多越好，當然，通常你要傳達的不是硬數據，而是軟數據；</p>
<p>硬數據：指事實，如新聞、股票價格、列車時間或你銀行賬戶的存款……</p>
<p>軟數據：涉及信息傳達的質量，如公司給人的第一印象，服務提供者是否親切，一種產品是否適合你……這些都是同樣重要的。</p>
<p>無論你要傳達的是硬數據還是軟數據，你都應該有意識並謹慎的使用元素數量。</p></blockquote>
<p>原文網址：http://www.webdesignfromscratch.com/web-2.0-design-style-guide.cfm</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2008/10/14/1754/%e6%91%98%e9%8c%84-web-20-%e8%a8%ad%e8%a8%88%e6%8c%87%e5%b0%8e%e4%b9%8b%e4%b8%80%ef%bc%9a%e7%b0%a1%e5%96%ae/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>[摘錄] 內容設計，初始內容</title>
		<link>http://blog.planism.com/archives/2008/03/06/1531/%e6%91%98%e9%8c%84-%e5%85%a7%e5%ae%b9%e8%a8%ad%e8%a8%88%ef%bc%8c%e5%88%9d%e5%a7%8b%e5%85%a7%e5%ae%b9</link>
		<comments>http://blog.planism.com/archives/2008/03/06/1531/%e6%91%98%e9%8c%84-%e5%85%a7%e5%ae%b9%e8%a8%ad%e8%a8%88%ef%bc%8c%e5%88%9d%e5%a7%8b%e5%85%a7%e5%ae%b9#comments</comments>
		<pubDate>Thu, 06 Mar 2008 03:00:51 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2008/03/06/1531/</guid>
		<description><![CDATA[&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=719 Content Design(內容設計)即涉及產品需求也涉及到(產品和用戶)互動過程中的具體環節。大多數團隊中只有PM才會涉及到相關工作，一般情況下不是基於用戶需求就是如何展現，很少涉及具體的互動環節也很少會有人整體上去綜合思考內容的設計。 事實上沒有什麼產品是「難用」的，只要用戶有了使用的需求興趣，基本上所有產品都會變得容易。但，也沒有任何產品是「好用」的，如果用戶沒有使用樂趣怎麼做都難用。 一切的根本在於需求和興趣，滿足用戶需求的是內容，引導用戶用戶興趣靠「初始內容」。 關於「初始內容」的設計，主要是指在用戶未正式使用（不只是「未登錄」，登錄了但沒有深入使用也算）前給他們展示什麼，讓他們可以(不可以)做什麼。其主要設計原則與用戶的認知積累、目的性有著非常直接的關係。 有些產品把「內容」做的很早讓用戶有了一定的認知。於是，他們可以讓用戶進來後直奔主題。 有些領域用戶進來就帶著強烈的需求，或者已經有了足夠的認知積累。於是，需要讓用戶進來後直奔主題，而無須設計過多的「初始內容」來干擾用戶。 在更多用戶沒有「認知積累」的時候，「未正式使用」之前整個產品只是一本又厚又難懂的「說明書」。很多用戶進入一個新網站時，會先「看看」然後「逛逛」，再後才是深入去用。 在「未正式使用」之前讓他看到什麼、逛什麼？ 直接影響新用戶的轉化率。如何讓用戶「有興趣」並「快速」讀懂，然後「產生使用的慾望和興趣」，是所有產品設計過程中都會遇到的問題。 受教了~ 有興趣的話，建議回讀原文，寫得很詳細，也舉了一些網站當作範例。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=719</p>
<p>Content Design(內容設計)即涉及產品需求也涉及到(產品和用戶)互動過程中的具體環節。大多數團隊中只有PM才會涉及到相關工作，一般情況下不是基於用戶需求就是如何展現，很少涉及具體的互動環節也很少會有人整體上去綜合思考內容的設計。</p>
<p>事實上沒有什麼產品是「難用」的，只要用戶有了使用的需求興趣，基本上所有產品都會變得容易。但，也沒有任何產品是「好用」的，如果用戶沒有使用樂趣怎麼做都難用。</p>
<p>一切的根本在於需求和興趣，滿足用戶需求的是內容，引導用戶用戶興趣靠「初始內容」。</p>
<p>關於「初始內容」的設計，主要是指在用戶未正式使用（不只是「未登錄」，登錄了但沒有深入使用也算）前給他們展示什麼，讓他們可以(不可以)做什麼。其主要設計原則與用戶的認知積累、目的性有著非常直接的關係。</p>
<p>有些產品把「內容」做的很早讓用戶有了一定的認知。於是，他們可以讓用戶進來後直奔主題。</p>
<p>有些領域用戶進來就帶著強烈的需求，或者已經有了足夠的認知積累。於是，需要讓用戶進來後直奔主題，而無須設計過多的「初始內容」來干擾用戶。</p>
<p>在更多用戶沒有「認知積累」的時候，「未正式使用」之前整個產品只是一本又厚又難懂的「說明書」。很多用戶進入一個新網站時，會先「看看」然後「逛逛」，再後才是深入去用。</p>
<p>在「未正式使用」之前讓他看到什麼、逛什麼？ 直接影響新用戶的轉化率。如何讓用戶「有興趣」並「快速」讀懂，然後「產生使用的慾望和興趣」，是所有產品設計過程中都會遇到的問題。</p></blockquote>
<p>受教了~</p>
<p>有興趣的話，建議回讀<a href="http://uicom.net/blog/?p=719">原文</a>，寫得很詳細，也舉了一些網站當作範例。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2008/03/06/1531/%e6%91%98%e9%8c%84-%e5%85%a7%e5%ae%b9%e8%a8%ad%e8%a8%88%ef%bc%8c%e5%88%9d%e5%a7%8b%e5%85%a7%e5%ae%b9/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 跟著用戶走到溝裡</title>
		<link>http://blog.planism.com/archives/2008/03/05/1530/%e6%91%98%e9%8c%84-%e8%b7%9f%e8%91%97%e7%94%a8%e6%88%b6%e8%b5%b0%e5%88%b0%e6%ba%9d%e8%a3%a1</link>
		<comments>http://blog.planism.com/archives/2008/03/05/1530/%e6%91%98%e9%8c%84-%e8%b7%9f%e8%91%97%e7%94%a8%e6%88%b6%e8%b5%b0%e5%88%b0%e6%ba%9d%e8%a3%a1#comments</comments>
		<pubDate>Wed, 05 Mar 2008 03:00:55 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2008/03/05/1530/</guid>
		<description><![CDATA[&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=718 交互設計大師、「Macintosh」之父 Jaf Raskin 曾說：好的設計不會讓使用者養成對今後工作不利的習慣，但設計人員卻經常有意無意地給用戶設下壞習慣的陷阱。事實上，良好的設計應該在給用戶帶來幫助的同時，把對其未來可能出現的限制性障礙降到最低， 保持使用者自由的可擴展性。這說的是交互設計。放在產品上亦然。 當浴缸裡只有一碗水的時候點一滴墨就會使整個浴缸變得骯髒，當浴缸裝滿以後偶爾一兩滴墨水根本無所謂，而且那個時候看著乾淨的一缸水也沒人「道德敗壞」的去滴墨進去。 這些很有技巧性的「引導」我們很難在國內的模仿者那裡看到，能有意識去做「限制」或者「刪除」的網站已經算是很不錯了… 確定方向是什麼、搞清楚什麼東西對用戶才有真正的價值，實在很難但也實在很重要。 「我們完全是根據用戶需求的演變而發展產品的，用戶需要什麼我們就滿足什麼」其實都是成功後騙人的鬼話。 雖然有人說顧客永遠是對的，但顧客卻不一定知道他要的是什麼。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=718</p>
<p>交互設計大師、「Macintosh」之父 Jaf Raskin 曾說：好的設計不會讓使用者養成對今後工作不利的習慣，但設計人員卻經常有意無意地給用戶設下壞習慣的陷阱。事實上，良好的設計應該在給用戶帶來幫助的同時，把對其未來可能出現的限制性障礙降到最低， 保持使用者自由的可擴展性。這說的是交互設計。放在產品上亦然。</p>
<p>當浴缸裡只有一碗水的時候點一滴墨就會使整個浴缸變得骯髒，當浴缸裝滿以後偶爾一兩滴墨水根本無所謂，而且那個時候看著乾淨的一缸水也沒人「道德敗壞」的去滴墨進去。</p>
<p>這些很有技巧性的「引導」我們很難在國內的模仿者那裡看到，能有意識去做「限制」或者「刪除」的網站已經算是很不錯了…</p>
<p>確定方向是什麼、搞清楚什麼東西對用戶才有真正的價值，實在很難但也實在很重要。</p>
<p>「我們完全是根據用戶需求的演變而發展產品的，用戶需要什麼我們就滿足什麼」其實都是成功後騙人的鬼話。</p></blockquote>
<p>雖然有人說顧客永遠是對的，但顧客卻不一定知道他要的是什麼。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2008/03/05/1530/%e6%91%98%e9%8c%84-%e8%b7%9f%e8%91%97%e7%94%a8%e6%88%b6%e8%b5%b0%e5%88%b0%e6%ba%9d%e8%a3%a1/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 創業公司沒有固定設計團隊，很好。</title>
		<link>http://blog.planism.com/archives/2007/12/28/1478/%e6%91%98%e9%8c%84-%e5%89%b5%e6%a5%ad%e5%85%ac%e5%8f%b8%e6%b2%92%e6%9c%89%e5%9b%ba%e5%ae%9a%e8%a8%ad%e8%a8%88%e5%9c%98%e9%9a%8a%ef%bc%8c%e5%be%88%e5%a5%bd%e3%80%82</link>
		<comments>http://blog.planism.com/archives/2007/12/28/1478/%e6%91%98%e9%8c%84-%e5%89%b5%e6%a5%ad%e5%85%ac%e5%8f%b8%e6%b2%92%e6%9c%89%e5%9b%ba%e5%ae%9a%e8%a8%ad%e8%a8%88%e5%9c%98%e9%9a%8a%ef%bc%8c%e5%be%88%e5%a5%bd%e3%80%82#comments</comments>
		<pubDate>Fri, 28 Dec 2007 02:00:21 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/12/28/1478/</guid>
		<description><![CDATA[&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=701 不用在公司大張旗鼓的搞個「設計部」，往往搞一個團隊並冠上「設計部」以後，你會發現你的產品設計反倒更糟糕了。最主要還是調動所有人一起來參與設計。再說，你們也沒有那麼多錢請鳳毛麟角般的「好設計師」。 重申那個老掉牙的觀點：不是只有設計部門才應該去做設計。參與產品的用戶體驗設計是所有團隊成員的責任和義務，設計師首先要做好的應該是設計的統一協調和管理，然後才是去做設計本身。 這篇文章裡面，敘述的一些故事，讓我感同身受、感觸良多，值得閱讀 / 玩味。 &#8220;不是只有設計部門才應該去做設計&#8221;:http://uicom.net/blog/?p=514 @ 白鴉，以用戶為中心的設計 產品設計差易用性差確實跟設計人員有關係，而且有直接的關係；但並不是說所有的責任都在於你們的設計部門弱！ 一個產品的UE設計工作不只是UE部門要做，不是只有設計部門才能去做UE設計。你們的PM和RD甚至包括客服部門一樣應該承擔產品設計不好的責任，也有義務一起去改進! 可用性應該只能算是一個新的詞或者新的工種，並非是一個新的理念或概念。實際上在很早以前我們一開始做網站設計、產品設計的時候就在搞可用性相關的工作， 只是那個時候我們沒有專門安排一個職位或者部門叫做『可用性工程師』而已！ 不是只有叫做『可用性工程師』的人才能去做可用性，也不是只有『可用性工程師』才應該去做可用性。所以我們現在其實是在把工作做的更精細、更符合用戶而已，而非「提出了一個新的概念」。 在這個要求高質量無縫協作的年代。無論是什麼部門或什麼角色在主導項目，溝通永遠都應該是第一位的。 各個角色之間的共同語言是溝通的基礎，RD（技術）不應該只懂代碼、PM(產品經理)不應該只懂產品和市場、UE也不應該只懂用戶體驗… 一個好的團隊應該是項目補充的。大家是衝著一個目標的團隊,要做的是互相幫助著衝向目標. 而絕非各自完成任務! 所以，我認為：一個產品的用戶體驗設計應該：有UE部門主導、多個部門一起努力。 在說「我們不只是美工」的同時一樣要意識到「程序員也不只是寫代碼的」！ 好文一篇~ 推！ 悶著頭寫一堆文件、想辦法弄一堆流程、三不五時開一堆鳥會，這樣就能搞出產品嗎？ 把時間浪費在這邊也不是不行，反正領薪水的，撐愈久領愈多。不過，看到時間一點一滴的流逝、市場一步一步的被蠶食、產品一天一天的崩壞 / 老化。身為開發團隊的一份子，是毫無感覺，還是情何以堪？ 再說，製作人也不只是寫 spec 的&#8230; ■ 延伸閱讀 * &#8220;贊同「創業公司沒有固定設計團隊」&#8221;:http://robertmao.com/archives/472 * &#8220;創業公司是否需要全職設計師？&#8221;:http://uicom.net/blog/?p=702]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=701</p>
<p>不用在公司大張旗鼓的搞個「設計部」，往往搞一個團隊並冠上「設計部」以後，你會發現你的產品設計反倒更糟糕了。最主要還是調動所有人一起來參與設計。再說，你們也沒有那麼多錢請鳳毛麟角般的「好設計師」。</p>
<p>重申那個老掉牙的觀點：<a href="http://uicom.net/blog/?p=514">不是只有設計部門才應該去做設計</a>。參與產品的用戶體驗設計是所有團隊成員的責任和義務，設計師首先要做好的應該是設計的統一協調和管理，然後才是去做設計本身。</p></blockquote>
<p>這篇文章裡面，敘述的一些故事，讓我感同身受、感觸良多，值得閱讀 / 玩味。</p>
<blockquote><p>&#8220;不是只有設計部門才應該去做設計&#8221;:http://uicom.net/blog/?p=514 @ 白鴉，以用戶為中心的設計</p>
<p>產品設計差易用性差確實跟設計人員有關係，而且有直接的關係；但並不是說所有的責任都在於你們的設計部門弱！ 一個產品的UE設計工作不只是UE部門要做，不是只有設計部門才能去做UE設計。你們的PM和RD甚至包括客服部門一樣應該承擔產品設計不好的責任，也有義務一起去改進!</p>
<p>可用性應該只能算是一個新的詞或者新的工種，並非是一個新的理念或概念。實際上在很早以前我們一開始做網站設計、產品設計的時候就在搞可用性相關的工作， 只是那個時候我們沒有專門安排一個職位或者部門叫做『可用性工程師』而已！</p>
<p>不是只有叫做『可用性工程師』的人才能去做可用性，也不是只有『可用性工程師』才應該去做可用性。所以我們現在其實是在把工作做的更精細、更符合用戶而已，而非「提出了一個新的概念」。</p>
<p>在這個要求高質量無縫協作的年代。無論是什麼部門或什麼角色在主導項目，溝通永遠都應該是第一位的。</p>
<p>各個角色之間的共同語言是溝通的基礎，RD（技術）不應該只懂代碼、PM(產品經理)不應該只懂產品和市場、UE也不應該只懂用戶體驗…</p>
<p>一個好的團隊應該是項目補充的。大家是衝著一個目標的團隊,要做的是互相幫助著衝向目標. 而絕非各自完成任務!</p>
<p>所以，我認為：一個產品的用戶體驗設計應該：有UE部門主導、多個部門一起努力。</p>
<p>在說「我們不只是美工」的同時一樣要意識到「程序員也不只是寫代碼的」！ </p></blockquote>
<p>好文一篇~ 推！</p>
<p>悶著頭寫一堆文件、想辦法弄一堆流程、三不五時開一堆鳥會，這樣就能搞出產品嗎？</p>
<p>把時間浪費在這邊也不是不行，反正領薪水的，撐愈久領愈多。不過，看到時間一點一滴的流逝、市場一步一步的被蠶食、產品一天一天的崩壞 / 老化。身為開發團隊的一份子，是毫無感覺，還是情何以堪？</p>
<p>再說，製作人也不只是寫 spec 的&#8230;</p>
<p>■ 延伸閱讀</p>
<p>* &#8220;贊同「創業公司沒有固定設計團隊」&#8221;:http://robertmao.com/archives/472<br />
* &#8220;創業公司是否需要全職設計師？&#8221;:http://uicom.net/blog/?p=702</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/12/28/1478/%e6%91%98%e9%8c%84-%e5%89%b5%e6%a5%ad%e5%85%ac%e5%8f%b8%e6%b2%92%e6%9c%89%e5%9b%ba%e5%ae%9a%e8%a8%ad%e8%a8%88%e5%9c%98%e9%9a%8a%ef%bc%8c%e5%be%88%e5%a5%bd%e3%80%82/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] Design Bookmarklet</title>
		<link>http://blog.planism.com/archives/2007/12/24/1473/%e6%91%98%e9%8c%84-design-bookmarklet</link>
		<comments>http://blog.planism.com/archives/2007/12/24/1473/%e6%91%98%e9%8c%84-design-bookmarklet#comments</comments>
		<pubDate>Mon, 24 Dec 2007 01:42:54 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Diary]]></category>
		<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/12/24/1473/</guid>
		<description><![CDATA[&#8220;Idea Grapes&#8221;:http://blog.yoren.info/2007/12/21/486/ Allen Jardine製作的 Design Bookmarklet 一共有四種功能，如果你和我一樣，做網頁時，有非得把各種元素對齊不可的強迫症，那麼這個工具將非常實用： # Grid：可依需求直接輸入數據（尺寸、欄位數和列數、邊距等）在頁面中產生格線。 # Rule：在上方和左側顯示尺規，並且可以拖曳出準線（guides）。 # Unit：在頁面中測量任意兩點間的距離。 # Crosshair：隨滑鼠游標出現的十字瞄準線，並提示座標。 我也有對齊強迫症&#8230;]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;Idea Grapes&#8221;:http://blog.yoren.info/2007/12/21/486/</p>
<p>Allen Jardine製作的 <a href="http://www.sprymedia.co.uk/article/Design">Design Bookmarklet</a> 一共有四種功能，如果你和我一樣，做網頁時，有非得把各種元素對齊不可的強迫症，那麼這個工具將非常實用：</p>
<p># Grid：可依需求直接輸入數據（尺寸、欄位數和列數、邊距等）在頁面中產生格線。<br />
# Rule：在上方和左側顯示尺規，並且可以拖曳出準線（guides）。<br />
# Unit：在頁面中測量任意兩點間的距離。<br />
# Crosshair：隨滑鼠游標出現的十字瞄準線，並提示座標。</p></blockquote>
<p>我也有對齊強迫症&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/12/24/1473/%e6%91%98%e9%8c%84-design-bookmarklet/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 網頁應用程式 Usability 筆記</title>
		<link>http://blog.planism.com/archives/2007/11/26/1443/%e6%91%98%e9%8c%84-%e7%b6%b2%e9%a0%81%e6%87%89%e7%94%a8%e7%a8%8b%e5%bc%8f-usability-%e7%ad%86%e8%a8%98</link>
		<comments>http://blog.planism.com/archives/2007/11/26/1443/%e6%91%98%e9%8c%84-%e7%b6%b2%e9%a0%81%e6%87%89%e7%94%a8%e7%a8%8b%e5%bc%8f-usability-%e7%ad%86%e8%a8%98#comments</comments>
		<pubDate>Mon, 26 Nov 2007 15:11:33 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/11/26/1443/</guid>
		<description><![CDATA[&#8220;Xexex&#8217;s Java 和其他二三事&#8221;:http://www.javaworld.com.tw/roller/page/ingramchen?entry=2007_11_18_WebAppUsabilityNotes 原則一：思考服務的對象 首先要先了解你的用戶是哪一種類型：若按用戶功力可分為 end user 和 power user。若按網頁使用頻率來分，可分為例行性作業和一次性作業。用例子說明好了，比方說大家熟悉的購物網站，包含產品瀏覽、購物車、下單等等功能。首先，這類網站的使用者功力大多屬於 end user，因此介面上越簡單越好 (即使你有很好的創意，也要小心發揮，因為 end user 可能會看不懂你新穎的介面)。若從使用頻率來看，產品瀏覽屬於例行性作業，下單則屬於一次性作業 (因為久久才下單一次)。因此產品瀏覽的網頁不能拖泥帶水，步驟要越少越好，不然用戶逛了老半天找不到想買的東西就跑掉了。另一方面，下單的網頁到是不怕步驟多，就怕使用者不會用，或是抗拒使用 (要付錢的地方總是會小心翼翼的)。所以一般下單都會設計成 wizard 的方式，一步一步導引使用者完成下單。 那如果是購物網站的後台呢？後台的使用者屬於 power user (可能一開始就是，或是之後會被訓練)。他每天的工作就是產品上架，處理訂單&#8230;等等例行性的作業。這樣的網頁以快速為最優先考量：可以運用 減少 popup、不用 wizard、多功能客製化元件、一頁內放多一點資訊、增設 hotkey&#8230; 等等技巧。總之讓用戶可以在最少的點擊、最少的思考完成他的工作就是了。 原則二：第一頁要放用戶最想做，最常做的事 要提升 usability，就是去思考用戶最想做或是最常做的事，比方說，第一頁除了查詢表單之外，還列出他最近處理過的10個案子；或者，用戶比較關心那些稽核不過的案子，那一開始就先列出這些有問題的案子；或者，可以提供查詢條件 history 的功能，讓用戶可以調出最近下的查詢條件&#8230; 等等。 決定要做那方面的事，要透過談需求時了解。而且，要注意很少有使用者會自覺得想到這一塊，必需由開發者主動尋問和了解使用者的作業才行。 原則三：重要的內容放在 1024&#215;768 內 這個原則很基本，許多人都了解 (還不知道的人要打屁屁！)。問題是出在難遵守&#8230;. 開發人員通常都用很大的營幕、開高解析度、然後字型用的小小的，希望一次看多點資訊，方便開發。這樣的習慣長期下來，一不小心就會發生設計的網頁常常需要 scroll (甚至是左右 scroll)。 除非你的網頁是設計給 power user，而且是配備比較好的營幕。不然開發時建議固定開個 1024&#215;748 的 browser 來檢視網頁的呈現，比較符合一般使用者的畫面大小。(安裝 firefox 的 web [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;Xexex&#8217;s Java 和其他二三事&#8221;:http://www.javaworld.com.tw/roller/page/ingramchen?entry=2007_11_18_WebAppUsabilityNotes</p>
<p><strong>原則一：思考服務的對象</strong></p>
<p>首先要先了解你的用戶是哪一種類型：若按用戶功力可分為 end user 和 power user。若按網頁使用頻率來分，可分為例行性作業和一次性作業。用例子說明好了，比方說大家熟悉的購物網站，包含產品瀏覽、購物車、下單等等功能。首先，這類網站的使用者功力大多屬於 end user，因此介面上越簡單越好 (即使你有很好的創意，也要小心發揮，因為 end user 可能會看不懂你新穎的介面)。若從使用頻率來看，產品瀏覽屬於例行性作業，下單則屬於一次性作業 (因為久久才下單一次)。因此產品瀏覽的網頁不能拖泥帶水，步驟要越少越好，不然用戶逛了老半天找不到想買的東西就跑掉了。另一方面，下單的網頁到是不怕步驟多，就怕使用者不會用，或是抗拒使用 (要付錢的地方總是會小心翼翼的)。所以一般下單都會設計成 wizard 的方式，一步一步導引使用者完成下單。</p>
<p>那如果是購物網站的後台呢？後台的使用者屬於 power user (可能一開始就是，或是之後會被訓練)。他每天的工作就是產品上架，處理訂單&#8230;等等例行性的作業。這樣的網頁以快速為最優先考量：可以運用 減少 popup、不用 wizard、多功能客製化元件、一頁內放多一點資訊、增設 hotkey&#8230; 等等技巧。總之讓用戶可以在最少的點擊、最少的思考完成他的工作就是了。</p>
<p><strong>原則二：第一頁要放用戶最想做，最常做的事</strong></p>
<p>要提升 usability，就是去思考用戶最想做或是最常做的事，比方說，第一頁除了查詢表單之外，還列出他最近處理過的10個案子；或者，用戶比較關心那些稽核不過的案子，那一開始就先列出這些有問題的案子；或者，可以提供查詢條件 history 的功能，讓用戶可以調出最近下的查詢條件&#8230; 等等。</p>
<p>決定要做那方面的事，要透過談需求時了解。而且，要注意很少有使用者會自覺得想到這一塊，必需由開發者主動尋問和了解使用者的作業才行。</p>
<p><strong>原則三：重要的內容放在 1024&#215;768 內</strong></p>
<p>這個原則很基本，許多人都了解 (還不知道的人要打屁屁！)。問題是出在難遵守&#8230;. 開發人員通常都用很大的營幕、開高解析度、然後字型用的小小的，希望一次看多點資訊，方便開發。這樣的習慣長期下來，一不小心就會發生設計的網頁常常需要 scroll (甚至是左右 scroll)。</p>
<p>除非你的網頁是設計給 power user，而且是配備比較好的營幕。不然開發時建議固定開個 1024&#215;748 的 browser 來檢視網頁的呈現，比較符合一般使用者的畫面大小。(安裝 firefox 的 web developer plugin，然後大小設 1024&#215;748 (不是 768，因為要扣掉 toobar和 menu 的高度)) 瀏覽器的大小有了，接下來就是將重要的內容、用戶最關心的事情，盡量放在網頁上半段，一般來說，左上角是人瀏覽的起點，從那裡開始最好。目的就是讓用戶最少的力氣找到他要的東西，而不是 scroll 老半天才看的到。</p>
<p><strong>原則四：改變資料狀態用按鈕，瀏覽資料用連結</strong></p>
<p>當你做的功能是 改變資料狀態時，網頁上要用按鈕來呈現。如果是資料間瀏覽，則用連結來呈現。什麼是改變資料狀態？比方說刪除資料、送出表單、移動位置、切換&#8230;等等功能。這些功能用按鈕比較洽當，因為按鈕有 &#8220;動作&#8221; 的感覺 (按下後再彈上)、有視覺上的 feedback。當然在 ajax 的風潮之下，按鈕漸漸越用越少了，不少地方開始用連結來替代。不過重點還是一樣，要有視覺上的 feedback，例如加些 animation, yellow fade out之類的都可以。</p>
<p>另一方面，瀏覽資料則一定是用連結，千萬不要用按鈕替代。這聽起來很白吃吧？但就是有新手會犯這種錯 (三年前我自個兒也常犯&#8230;)</p>
<p><strong>原則五：慎防預覽頁面</strong></p>
<p>當設計多步驟網頁時，例如結帳的功能，中間多半會夾一個預覽的頁面。預覽的網頁原本是好意，讓使用者可以再完成前，再確認、考慮一番。但偏偏很多用戶會把他當做 &#8220;已完成&#8221; 的網頁，造成常會有客戶來電，抱怨明明已經完成了，卻沒成交。</p>
<p>為避免這類常犯的錯誤，建議預覽的畫面正上方要加上大剌剌的 &#8220;完成按鈕&#8221; (可用顏色/大小/字型來醒目) 提醒使用者，要按了才會生效。如果版面許可，可以再加上 process train (另一說法是 process funnel) 就是常見的按順序導引：(1) -> (2) -> (3) -> done，這樣就更穩了。現在 Ajax 技術發達，也可以考慮用 &#8220;即時預覽&#8221; 取代掉舊的換頁預覽，這樣既方便又不會出錯。</p></blockquote>
<p>簡單易懂的說明，受教了~</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/11/26/1443/%e6%91%98%e9%8c%84-%e7%b6%b2%e9%a0%81%e6%87%89%e7%94%a8%e7%a8%8b%e5%bc%8f-usability-%e7%ad%86%e8%a8%98/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 常被忽略的網頁配置問題</title>
		<link>http://blog.planism.com/archives/2007/11/21/1439/%e6%91%98%e9%8c%84-%e5%b8%b8%e8%a2%ab%e5%bf%bd%e7%95%a5%e7%9a%84%e7%b6%b2%e9%a0%81%e9%85%8d%e7%bd%ae%e5%95%8f%e9%a1%8c</link>
		<comments>http://blog.planism.com/archives/2007/11/21/1439/%e6%91%98%e9%8c%84-%e5%b8%b8%e8%a2%ab%e5%bf%bd%e7%95%a5%e7%9a%84%e7%b6%b2%e9%a0%81%e9%85%8d%e7%bd%ae%e5%95%8f%e9%a1%8c#comments</comments>
		<pubDate>Wed, 21 Nov 2007 01:58:38 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Planning]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/11/21/1439/</guid>
		<description><![CDATA[&#8220;ZDNet&#8221;:http://www.zdnet.com.tw/enterprise/technology/0,2000085680,20125894,00.htm by thinker 一篇文章的長度以一千字上下最為理想。兩千字以上的文章最好分成多篇來刊登。另外不妨放一些圖片在文章中間或是開頭之處，（與內容無關也無妨），在視覺上維持一定的圖文比例。 這是因為「網頁」這種素材天生不適合長篇閱讀，讀者對你的文字付出的注意力十分有限。如果沒有一些圖畫在旁點綴，整個版面會顯得太乾。使用者看到整個螢幕舖天蓋地的字，往往看都不看就按下Back鍵逃走了。除非你自信文筆跟九把刀或金庸一樣，讀者不看完整篇停不下來，不然還是乖乖的控制字數比較實在。 再來還可以考慮在每個段落的開頭給出一個小標題，凸顯文章的結構，讓閱讀更為輕鬆方便，讀者可以預期你接下來要講的內容重點。 把握「長度、圖文比例與小標題」這三個重點，絕對可以讓Blog的畫面與文章更為好看好讀。 有一回，看「超級星光大道」，評審林志炫說：『表演重要的不是你表現得好不好，而是你要的東西有沒有表達出來。』 寫文章、經營 blog 也是同樣道理。心領神會~ ■ 延伸閱讀 * Pingdom 網頁速度優化參考工具使用心得 * 你的網站到底是慢在哪裡？讓 Pingdom Tools 告訴你。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;ZDNet&#8221;:http://www.zdnet.com.tw/enterprise/technology/0,2000085680,20125894,00.htm by thinker</p>
<p>一篇文章的長度以一千字上下最為理想。兩千字以上的文章最好分成多篇來刊登。另外不妨放一些圖片在文章中間或是開頭之處，（與內容無關也無妨），在視覺上維持一定的圖文比例。</p>
<p>這是因為「網頁」這種素材天生不適合長篇閱讀，讀者對你的文字付出的注意力十分有限。如果沒有一些圖畫在旁點綴，整個版面會顯得太乾。使用者看到整個螢幕舖天蓋地的字，往往看都不看就按下Back鍵逃走了。除非你自信文筆跟九把刀或金庸一樣，讀者不看完整篇停不下來，不然還是乖乖的控制字數比較實在。</p>
<p>再來還可以考慮在每個段落的開頭給出一個小標題，凸顯文章的結構，讓閱讀更為輕鬆方便，讀者可以預期你接下來要講的內容重點。</p>
<p>把握「長度、圖文比例與小標題」這三個重點，絕對可以讓Blog的畫面與文章更為好看好讀。</p></blockquote>
<p>有一回，看「超級星光大道」，評審林志炫說：『表演重要的不是你表現得好不好，而是你要的東西有沒有表達出來。』</p>
<p>寫文章、經營 blog 也是同樣道理。心領神會~</p>
<p>■ 延伸閱讀</p>
<p>* <a href="http://playpcesor.blogspot.com/2007/10/pingdom.html" title="Pingdom 網頁速度優化參考工具使用心得">Pingdom 網頁速度優化參考工具使用心得</a><br />
* <a href="http://www.freegroup.org/pingdom" title="你的網站到底是慢在哪裡？讓 Pingdom Tools 告訴你。">你的網站到底是慢在哪裡？讓 Pingdom Tools 告訴你。</a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/11/21/1439/%e6%91%98%e9%8c%84-%e5%b8%b8%e8%a2%ab%e5%bf%bd%e7%95%a5%e7%9a%84%e7%b6%b2%e9%a0%81%e9%85%8d%e7%bd%ae%e5%95%8f%e9%a1%8c/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 界面內容優化的層次</title>
		<link>http://blog.planism.com/archives/2007/11/06/1424/%e6%91%98%e9%8c%84-%e7%95%8c%e9%9d%a2%e5%85%a7%e5%ae%b9%e5%84%aa%e5%8c%96%e7%9a%84%e5%b1%a4%e6%ac%a1</link>
		<comments>http://blog.planism.com/archives/2007/11/06/1424/%e6%91%98%e9%8c%84-%e7%95%8c%e9%9d%a2%e5%85%a7%e5%ae%b9%e5%84%aa%e5%8c%96%e7%9a%84%e5%b1%a4%e6%ac%a1#comments</comments>
		<pubDate>Tue, 06 Nov 2007 05:29:07 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/11/06/1424/</guid>
		<description><![CDATA[&#8220;UCDChina.com &#8211; 白鴉&#8221;:http://ucdchina.com/blog/?p=351 界面的文字就好像一個人的談吐，文字給用戶的感覺不單單只是一個「信息」的傳達，他還關乎用戶對於產品的情感印象和「產品氣質」的理解。 能否系統化的把「內容優化」像「體驗」一樣分層次的理解？ 首先，界面上的文字應該做到：清楚而準確的向用戶傳達信息。 接下來，界面上的文字應該便於用戶閱讀並快速理解其含義。 然後，整個產品不同位置的文字應該統一 最後，界面上的文字應該具備該產品需要傳達給用戶的氣質。 還有，文字的視覺設計應該完整的融入整個產品視覺中。 再有，儘量讓文字自身可以起到「推銷」產品的作用，而且「推銷」的不只是產品氣質。 界面上的文字看似是一個很細小的東西，實際上他蘊藏著很多的價值並且在潛移默化為產品帶來好的或者不好的利益。中國人說「察言觀色」，我想「言語」的表達對於中國用戶的觸動應該會更加的明顯。 用字遣詞，是一門學問。 ■ 延伸閱讀 * &#8220;創業產品的界面文字優化&#8221;:http://uicom.net/blog/?p=653 * &#8220;像聰明女孩穿衣服那樣設計網頁文字&#8221;:http://ucdchina.com/blog/?p=335 * &#8220;有多少文字可以胡來？！&#8221;:http://uicom.net/blog/?p=600]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;UCDChina.com &#8211; 白鴉&#8221;:http://ucdchina.com/blog/?p=351</p>
<p>界面的文字就好像一個人的談吐，文字給用戶的感覺不單單只是一個「信息」的傳達，他還關乎用戶對於產品的情感印象和「產品氣質」的理解。</p>
<p>能否系統化的把「內容優化」像「體驗」一樣分層次的理解？</p>
<p>首先，界面上的文字應該做到：清楚而準確的向用戶傳達信息。<br />
接下來，界面上的文字應該便於用戶閱讀並快速理解其含義。<br />
然後，整個產品不同位置的文字應該統一<br />
最後，界面上的文字應該具備該產品需要傳達給用戶的氣質。<br />
還有，文字的視覺設計應該完整的融入整個產品視覺中。<br />
再有，儘量讓文字自身可以起到「推銷」產品的作用，而且「推銷」的不只是產品氣質。</p>
<p>界面上的文字看似是一個很細小的東西，實際上他蘊藏著很多的價值並且在潛移默化為產品帶來好的或者不好的利益。中國人說「察言觀色」，我想「言語」的表達對於中國用戶的觸動應該會更加的明顯。</p></blockquote>
<p>用字遣詞，是一門學問。</p>
<p>■ 延伸閱讀</p>
<p>* &#8220;創業產品的界面文字優化&#8221;:http://uicom.net/blog/?p=653<br />
* &#8220;像聰明女孩穿衣服那樣設計網頁文字&#8221;:http://ucdchina.com/blog/?p=335<br />
* &#8220;有多少文字可以胡來？！&#8221;:http://uicom.net/blog/?p=600</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/11/06/1424/%e6%91%98%e9%8c%84-%e7%95%8c%e9%9d%a2%e5%85%a7%e5%ae%b9%e5%84%aa%e5%8c%96%e7%9a%84%e5%b1%a4%e6%ac%a1/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] SEO和用戶體驗</title>
		<link>http://blog.planism.com/archives/2007/10/17/1408/%e6%91%98%e9%8c%84-seo%e5%92%8c%e7%94%a8%e6%88%b6%e9%ab%94%e9%a9%97</link>
		<comments>http://blog.planism.com/archives/2007/10/17/1408/%e6%91%98%e9%8c%84-seo%e5%92%8c%e7%94%a8%e6%88%b6%e9%ab%94%e9%a9%97#comments</comments>
		<pubDate>Wed, 17 Oct 2007 02:00:29 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/10/17/1408/</guid>
		<description><![CDATA[&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=675 4、UED是在作品牌內功，SEO是在作品牌營銷。得分清。 5、品牌不只是靠營銷作出來的，品牌體驗非常關鍵。 品牌的基礎是用戶體驗，營銷需要建立在用戶體驗的基礎上。 6、所以：SEO需要建立在用戶體驗的基礎上，破壞用戶體驗的SEO一定是不好的。 所謂「SEO需要建立在用戶體驗的基礎上」是指：沒有好的用戶體驗再SEO也白搭；也指：產品有多少seo就作多少，不要越界。別把搜索「小姐包夜」的網民帶到一個淑女培訓網站上去。 7、UED可以並且應該幫助SEO，但不能是損失用戶體驗去幫助SEO. 這個道理就跟「產品 vs. 行銷」一樣： 老王賣瓜，自賣自誇，不甜的瓜，再怎麼自誇，消費者只會上當一次。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;白鴉，以用戶為中心的設計&#8221;:http://uicom.net/blog/?p=675</p>
<p><img src="http://uicom.net/blog/attachments/200706/jinzita.gif" alt="SEO和用戶體驗" /></p>
<p>4、UED是在作品牌內功，SEO是在作品牌營銷。得分清。</p>
<p>5、品牌不只是靠營銷作出來的，品牌體驗非常關鍵。 品牌的基礎是用戶體驗，營銷需要建立在用戶體驗的基礎上。</p>
<p>6、所以：SEO需要建立在用戶體驗的基礎上，破壞用戶體驗的SEO一定是不好的。<br />
所謂「SEO需要建立在用戶體驗的基礎上」是指：沒有好的用戶體驗再SEO也白搭；也指：產品有多少seo就作多少，不要越界。別把搜索「小姐包夜」的網民帶到一個淑女培訓網站上去。</p>
<p>7、UED可以並且應該幫助SEO，但不能是損失用戶體驗去幫助SEO.</p></blockquote>
<p>這個道理就跟「產品 vs. 行銷」一樣：</p>
<p>老王賣瓜，自賣自誇，不甜的瓜，再怎麼自誇，消費者只會上當一次。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/10/17/1408/%e6%91%98%e9%8c%84-seo%e5%92%8c%e7%94%a8%e6%88%b6%e9%ab%94%e9%a9%97/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>[摘錄] 殺手Google和迷茫的抓蝦</title>
		<link>http://blog.planism.com/archives/2007/09/25/1392/%e6%91%98%e9%8c%84-%e6%ae%ba%e6%89%8bgoogle%e5%92%8c%e8%bf%b7%e8%8c%ab%e7%9a%84%e6%8a%93%e8%9d%a6</link>
		<comments>http://blog.planism.com/archives/2007/09/25/1392/%e6%91%98%e9%8c%84-%e6%ae%ba%e6%89%8bgoogle%e5%92%8c%e8%bf%b7%e8%8c%ab%e7%9a%84%e6%8a%93%e8%9d%a6#comments</comments>
		<pubDate>Tue, 25 Sep 2007 02:47:42 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[rss reader]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/25/1392/</guid>
		<description><![CDATA[&#8220;一言談&#124; New Media Observe&#8221;:http://www.caozenghui.cn/?p=223 by 曹增輝 突然寫這個話題，是因為通過feedsky的統計，這兩天我的Google Reader的訂閱用戶超過了抓蝦，兩個都是1400多，然後是鮮果、bloglines等等。 毫無疑問，Google的這個訂閱數價值要遠大於抓蝦，原因很簡單，Google的訂閱用戶是純粹吸引過來對我的post感興趣的讀者；而抓蝦不同，抓蝦有社區化功能，不論是頻道大全還是熱文排行，幫他吸引了大量可能不應該屬於我的讀者的訂戶。 我覺得，至少說明了在RSS閱讀器這個市場上，以人為主，以工具為主目前還佔在主流上，至少用戶在關心「閱讀體驗」上要高於「交流溝通」，RSS閱讀還是一個小眾的市場。反過來說，即便未來抓蝦的社區功能更強大了，我應該也會堅持Google，因為它更高效的解決了我的閱讀需求，這個是第一位的，然後才是發現和交流。 儘管抓蝦很努力，但其實還是沒有解決用戶最最基本的需求：發現和關注自己感興趣的feed。 我覺得抓蝦在滿足用戶需求上，似乎給弄扭了，在社區交流上費了半天勁，讓用戶發現別人在幹什麼，事實上，我真的不太關心別人在做什麼，甚至我不關心誰訂閱了我的博客！我只關心，我怎麼能看到我喜歡的文章，找到我感興趣的feed。 這麼想的話，類似抓蝦這樣的閱讀器，要建立一個雙向溝通的SNS本身路子就不對。 就我的經驗，產品會開始弄扭，大多是服務流量沒有大增長，而老闆又非常在意流量、流量、流量，只好開始搞一些原本非主軸要搞的事情，意圖拉抬流量。最後，產品改版了、升級了，看起來有在推陳出新，但用起來卻不知所云。 複雜又無奈&#8230;]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;一言談| New Media Observe&#8221;:http://www.caozenghui.cn/?p=223 by 曹增輝</p>
<p>突然寫這個話題，是因為通過feedsky的統計，這兩天我的Google Reader的訂閱用戶超過了抓蝦，兩個都是1400多，然後是鮮果、bloglines等等。</p>
<p>毫無疑問，Google的這個訂閱數價值要遠大於抓蝦，原因很簡單，Google的訂閱用戶是純粹吸引過來對我的post感興趣的讀者；而抓蝦不同，抓蝦有社區化功能，不論是頻道大全還是熱文排行，幫他吸引了大量可能不應該屬於我的讀者的訂戶。</p>
<p>我覺得，至少說明了在RSS閱讀器這個市場上，以人為主，以工具為主目前還佔在主流上，至少用戶在關心「閱讀體驗」上要高於「交流溝通」，RSS閱讀還是一個小眾的市場。反過來說，即便未來抓蝦的社區功能更強大了，我應該也會堅持Google，因為它更高效的解決了我的閱讀需求，這個是第一位的，然後才是發現和交流。</p>
<p>儘管抓蝦很努力，但其實還是沒有解決用戶最最基本的需求：發現和關注自己感興趣的feed。</p>
<p>我覺得抓蝦在滿足用戶需求上，似乎給弄扭了，在社區交流上費了半天勁，讓用戶發現別人在幹什麼，事實上，我真的不太關心別人在做什麼，甚至我不關心誰訂閱了我的博客！我只關心，我怎麼能看到我喜歡的文章，找到我感興趣的feed。</p>
<p>這麼想的話，類似抓蝦這樣的閱讀器，要建立一個雙向溝通的SNS本身路子就不對。</p></blockquote>
<p>就我的經驗，產品會開始弄扭，大多是服務流量沒有大增長，而老闆又非常在意流量、流量、流量，只好開始搞一些原本非主軸要搞的事情，意圖拉抬流量。最後，產品改版了、升級了，看起來有在推陳出新，但用起來卻不知所云。</p>
<p>複雜又無奈&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/25/1392/%e6%91%98%e9%8c%84-%e6%ae%ba%e6%89%8bgoogle%e5%92%8c%e8%bf%b7%e8%8c%ab%e7%9a%84%e6%8a%93%e8%9d%a6/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>淘寶UED招聘</title>
		<link>http://blog.planism.com/archives/2007/09/17/1383/%e6%b7%98%e5%af%b6ued%e6%8b%9b%e8%81%98</link>
		<comments>http://blog.planism.com/archives/2007/09/17/1383/%e6%b7%98%e5%af%b6ued%e6%8b%9b%e8%81%98#comments</comments>
		<pubDate>Mon, 17 Sep 2007 03:38:14 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/17/1383/</guid>
		<description><![CDATA[『全力打造中國互聯網有史以來最cool的招聘子站。』 滿有趣的一個招聘型式~，順便瞧瞧徵才條件： ■ 用戶研究員 1.對網站或軟件用戶界面的可用性有深入的理解和研究，能熟練使用各種可用性研究方法； 2.對用戶心理能夠準確把握，樂於花費大量時間與用戶直接接觸； 3.思維嚴謹，溝通能力強，善於和各種背景的人合作； 4.愛好UI設計，有一定的基礎知識，可以熟練使用Photoshop等軟件設計原型； 5.有產品設計、平面設計、網頁設計經驗者優先； 6.心理學、工業設計、計算機等相關專業本科以上學歷，英語優秀； 7.工作地點：杭州； ■ 交互設計師 1.現在就是交互設計師，有成熟的作品； 2.對用戶體驗方面的理論有較深的瞭解和認識； 3.有不錯的視覺設計能力，對xHTML/CSS等技術有基本的掌握； 4.充滿好奇心，在每一個有趣的網站都擁有註冊帳號； 5.有很強的創新能力； 6.個性樂觀開朗，善於和各種背景的人合作； 7.有大局觀，可以在複雜的約束條件下找到平衡或創新的方法； 8.工作地點：杭州； ■ 前端開發工程師 1.精通各種Web前端技術，包括XHTML/XML/CSS/Javascript/ActionScript等（JS和AS之一即可）； 2.深刻理解Web標準，對可用性、可訪問性等相關知識有實際的瞭解和實踐經驗； 3.有基於Ajax或Flash的RIA應用開發經驗； 4.至少精通一門非Web前端腳本的語言（如Java/PHP/C++），並有項目經驗； 5.個性樂觀開朗，邏輯性強，善於和各種背景的人合作； 6.工作地點：杭州； 專業、專業、專業。 我是讀企管系的，大家對企管系的印象是：什麼都學，但什麼都不通。 我是當製作人的，自己對製作人的感想是：什麼都做，但什麼都不專。 講好聽點，製作人在領導這一群專業人員。 講難聽點，製作人在服侍這一群專業人員。 如何管理專案、管理人員，或許就是最專業的一項專業。]]></description>
			<content:encoded><![CDATA[<p>『全力打造中國互聯網有史以來最cool的招聘子站。』</p>
<p><a href="http://ued.taobao.com/job/"><img src="http://ued.taobao.com/blog/wp-content/uploads/2007/09/uedmovie.jpg" alt="淘寶UED招聘" width="450" /></a></p>
<p>滿有趣的一個招聘型式~，順便瞧瞧徵才條件：</p>
<blockquote><p>■ 用戶研究員</p>
<p>1.對網站或軟件用戶界面的可用性有深入的理解和研究，能熟練使用各種可用性研究方法；<br />
2.對用戶心理能夠準確把握，樂於花費大量時間與用戶直接接觸；<br />
3.思維嚴謹，溝通能力強，善於和各種背景的人合作；<br />
4.愛好UI設計，有一定的基礎知識，可以熟練使用Photoshop等軟件設計原型；<br />
5.有產品設計、平面設計、網頁設計經驗者優先；<br />
6.心理學、工業設計、計算機等相關專業本科以上學歷，英語優秀；<br />
7.工作地點：杭州；</p>
<p>■ 交互設計師</p>
<p>1.現在就是交互設計師，有成熟的作品；<br />
2.對用戶體驗方面的理論有較深的瞭解和認識；<br />
3.有不錯的視覺設計能力，對xHTML/CSS等技術有基本的掌握；<br />
4.充滿好奇心，在每一個有趣的網站都擁有註冊帳號；<br />
5.有很強的創新能力；<br />
6.個性樂觀開朗，善於和各種背景的人合作；<br />
7.有大局觀，可以在複雜的約束條件下找到平衡或創新的方法；<br />
8.工作地點：杭州；</p>
<p>■ 前端開發工程師</p>
<p>1.精通各種Web前端技術，包括XHTML/XML/CSS/Javascript/ActionScript等（JS和AS之一即可）；<br />
2.深刻理解Web標準，對可用性、可訪問性等相關知識有實際的瞭解和實踐經驗；<br />
3.有基於Ajax或Flash的RIA應用開發經驗；<br />
4.至少精通一門非Web前端腳本的語言（如Java/PHP/C++），並有項目經驗；<br />
5.個性樂觀開朗，邏輯性強，善於和各種背景的人合作；<br />
6.工作地點：杭州；</p></blockquote>
<p>專業、專業、專業。</p>
<p>我是讀企管系的，大家對企管系的印象是：什麼都學，但什麼都不通。<br />
我是當製作人的，自己對製作人的感想是：什麼都做，但什麼都不專。</p>
<p>講好聽點，製作人在領導這一群專業人員。<br />
講難聽點，製作人在服侍這一群專業人員。</p>
<p>如何管理專案、管理人員，或許就是最專業的一項專業。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/17/1383/%e6%b7%98%e5%af%b6ued%e6%8b%9b%e8%81%98/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>被抄被搶 vs. 所見略同</title>
		<link>http://blog.planism.com/archives/2007/09/13/1378/%e8%a2%ab%e6%8a%84%e8%a2%ab%e6%90%b6-vs-%e6%89%80%e8%a6%8b%e7%95%a5%e5%90%8c</link>
		<comments>http://blog.planism.com/archives/2007/09/13/1378/%e8%a2%ab%e6%8a%84%e8%a2%ab%e6%90%b6-vs-%e6%89%80%e8%a6%8b%e7%95%a5%e5%90%8c#comments</comments>
		<pubDate>Thu, 13 Sep 2007 03:48:04 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/13/1378/</guid>
		<description><![CDATA[今天看到某篇文章介紹一個網路服務。 光看文章標題就讓我心驚， 看了文章介紹就讓我心慌。 去看網站首頁就讓我心亂， 試用網站功能就讓我心傷。 想法被搶了嗎？點子被抄了嗎？ 不是，是大家所見略同。 只不過，我還在規劃階段，而人家已經推出上線。 說，比想高一級。 做，比說高一級。 做出來，跟還在做是不同層級。 左腳在門檻前，右腳在門檻後， 我該將左腳往後伸，還是右腳往前踏？ 答案是&#8230;]]></description>
			<content:encoded><![CDATA[<p>今天看到某篇文章介紹一個網路服務。</p>
<p>光看文章標題就讓我心驚，<br />
看了文章介紹就讓我心慌。<br />
去看網站首頁就讓我心亂，<br />
試用網站功能就讓我心傷。</p>
<p>想法被搶了嗎？點子被抄了嗎？<br />
不是，是大家所見略同。</p>
<p>只不過，我還在規劃階段，而人家已經推出上線。</p>
<p><strong>說</strong>，比<strong>想</strong>高一級。<br />
<strong>做</strong>，比<strong>說</strong>高一級。<br />
<strong>做出來</strong>，跟<strong>還在做</strong>是不同層級。</p>
<p>左腳在門檻前，右腳在門檻後，<br />
我該將左腳往後伸，還是右腳往前踏？</p>
<p>答案是&#8230;</p>
<p><a href="http://www.flickr.com/photos/zyphichore/424786326/"><img src="http://flypicture.com/files/MzAyODM=" style="border: 0;" title="goto flypicture.com" alt="右腳！" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/13/1378/%e8%a2%ab%e6%8a%84%e8%a2%ab%e6%90%b6-vs-%e6%89%80%e8%a6%8b%e7%95%a5%e5%90%8c/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>[摘錄] 社區的產品和運營（一）</title>
		<link>http://blog.planism.com/archives/2007/09/12/1376/%e6%91%98%e9%8c%84-%e7%a4%be%e5%8d%80%e7%9a%84%e7%94%a2%e5%93%81%e5%92%8c%e9%81%8b%e7%87%9f%ef%bc%88%e4%b8%80%ef%bc%89</link>
		<comments>http://blog.planism.com/archives/2007/09/12/1376/%e6%91%98%e9%8c%84-%e7%a4%be%e5%8d%80%e7%9a%84%e7%94%a2%e5%93%81%e5%92%8c%e9%81%8b%e7%87%9f%ef%bc%88%e4%b8%80%ef%bc%89#comments</comments>
		<pubDate>Wed, 12 Sep 2007 03:39:09 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/12/1376/</guid>
		<description><![CDATA[&#8220;奮翮高飛&#8221;:http://www.zhanghe4.com/index.php?blogId=1 技術是骨架，產品是血液，運營是肌肉。 如果把網站比喻成人體的話，我會這樣來類比各部分的機能：技術好比是人體的骨架，決定了網站能做到什麼樣的高度。這個骨架一定要高大，而且骨質要硬，不能缺「鈣」。產品是人體的血液，表面上看不太出來，但它決定了網站內在的潛力。這個網站「造血」的能力是否強大，直接影響到它是否能有更高的投入產出比。這是一個網站的動力之源。運營是人體的肌肉，看網站是否足夠強壯，就看它的運營能力。有很多矮個子也可以鍛鍊得非常強壯，而有的高個子卻非常瘦弱，這是運營能力的區別。但也有一種情況是假象，那就是「肥胖」，看上去塊頭很大，實際上很不健康。 短期看的是長處，長期看的是短處。 這句話的原始出處是李玉琢的《我與商業領袖的合作與衝突》一書，「短期看，企業家比的是長處；長期看，企業家比的是短處。」我覺得很有道理，就借用到這裡。當網站規模還比較小的時候，擁有一個優勢就足以讓你脫穎而出。比如BuyRen（現在的易購）早期基本沒有技術和產品可言，完全靠的是運營，也獲得了一定層面上的成功。但這種成功是有瓶頸的，需要有新的優勢來彌補不足。當網站發展到一定的規模，任何一個細節的不足，都可能導致和對手競爭的失敗。所以任何時候都需要認清自己的優勢和劣勢，不能因為短期的成功而忽略了長期的發展，需要未雨綢繆，提前在短板上下功夫，做準備。 這篇文章所提的比喻，讓我訝異彼此的看法竟有一絲絲雷同。 我之前常跟同事「屁」製作人如何看待一個服務： * 推出一個服務，就像生出一個小孩，所以你叫「製作&#8230;人」。 * 人的骨架：製作部負責，企劃人員規劃網站的功能及架構。 * 人的神經：工程部負責，工程人員根據功能架構寫出程式機制。 * 人的血肉：編輯部負責，編輯人員編輯內容單元、經營社群。 * 人的外表：美術部負責，美編人員設計長相、穿著。 * 人的舉止：公關部負責，公關人員教導應有的禮儀、行為及說話措辭。 * 人的推銷：行銷部負責，行銷人員利用特定場合及活動，讓大家認識。 * 人的銷售：業務部負責，業務人員帶去給客戶認識，砸錢投資。 我是生了小孩之後，才反過來體會到，這和我推出一個服務是如此的相像。不過，我覺得文章作者認為『產品是人體的血液，表面上看不太出來，但它決定了網站內在的潛力。這個網站「造血」的能力是否強大，直接影響到它是否能有更高的投入產出比。』的比喻更為傳神。社群性質的產品還必須是個有機體，它要能自給自足、自生自滅。 但不管如何比喻，把製作服務當成一個「生命」在孕育的精神，絕對是不變的。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;奮翮高飛&#8221;:http://www.zhanghe4.com/index.php?blogId=1</p>
<p>技術是骨架，產品是血液，運營是肌肉。</p>
<p>如果把網站比喻成人體的話，我會這樣來類比各部分的機能：技術好比是人體的骨架，決定了網站能做到什麼樣的高度。這個骨架一定要高大，而且骨質要硬，不能缺「鈣」。產品是人體的血液，表面上看不太出來，但它決定了網站內在的潛力。這個網站「造血」的能力是否強大，直接影響到它是否能有更高的投入產出比。這是一個網站的動力之源。運營是人體的肌肉，看網站是否足夠強壯，就看它的運營能力。有很多矮個子也可以鍛鍊得非常強壯，而有的高個子卻非常瘦弱，這是運營能力的區別。但也有一種情況是假象，那就是「肥胖」，看上去塊頭很大，實際上很不健康。</p>
<p>短期看的是長處，長期看的是短處。</p>
<p>這句話的原始出處是李玉琢的《我與商業領袖的合作與衝突》一書，「短期看，企業家比的是長處；長期看，企業家比的是短處。」我覺得很有道理，就借用到這裡。當網站規模還比較小的時候，擁有一個優勢就足以讓你脫穎而出。比如BuyRen（現在的易購）早期基本沒有技術和產品可言，完全靠的是運營，也獲得了一定層面上的成功。但這種成功是有瓶頸的，需要有新的優勢來彌補不足。當網站發展到一定的規模，任何一個細節的不足，都可能導致和對手競爭的失敗。所以任何時候都需要認清自己的優勢和劣勢，不能因為短期的成功而忽略了長期的發展，需要未雨綢繆，提前在短板上下功夫，做準備。</p></blockquote>
<p>這篇文章所提的比喻，讓我訝異彼此的看法竟有一絲絲雷同。<br />
我之前常跟同事「屁」製作人如何看待一個服務：</p>
<p>* 推出一個服務，就像生出一個小孩，所以你叫「製作&#8230;人」。<br />
* 人的骨架：製作部負責，企劃人員規劃網站的功能及架構。<br />
* 人的神經：工程部負責，工程人員根據功能架構寫出程式機制。<br />
* 人的血肉：編輯部負責，編輯人員編輯內容單元、經營社群。<br />
* 人的外表：美術部負責，美編人員設計長相、穿著。<br />
* 人的舉止：公關部負責，公關人員教導應有的禮儀、行為及說話措辭。<br />
* 人的推銷：行銷部負責，行銷人員利用特定場合及活動，讓大家認識。<br />
* 人的銷售：業務部負責，業務人員帶去給客戶認識，砸錢投資。</p>
<p>我是生了小孩之後，才反過來體會到，這和我推出一個服務是如此的相像。不過，我覺得文章作者認為『<em>產品是人體的血液，表面上看不太出來，但它決定了網站內在的潛力。這個網站「造血」的能力是否強大，直接影響到它是否能有更高的投入產出比。</em>』的比喻更為傳神。社群性質的產品還必須是個有機體，它要能自給自足、自生自滅。</p>
<p>但不管如何比喻，把製作服務當成一個「生命」在孕育的精神，絕對是不變的。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/12/1376/%e6%91%98%e9%8c%84-%e7%a4%be%e5%8d%80%e7%9a%84%e7%94%a2%e5%93%81%e5%92%8c%e9%81%8b%e7%87%9f%ef%bc%88%e4%b8%80%ef%bc%89/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 強硬的愛</title>
		<link>http://blog.planism.com/archives/2007/09/12/1375/%e6%91%98%e9%8c%84-%e5%bc%b7%e7%a1%ac%e7%9a%84%e6%84%9b</link>
		<comments>http://blog.planism.com/archives/2007/09/12/1375/%e6%91%98%e9%8c%84-%e5%bc%b7%e7%a1%ac%e7%9a%84%e6%84%9b#comments</comments>
		<pubDate>Wed, 12 Sep 2007 02:48:27 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/12/1375/</guid>
		<description><![CDATA[&#8220;譯言 &#8211; Getting Real 翻譯&#8221;:http://www.yeeyan.com/articles/view/4811/1958 樂於向客戶說 不 至於特性需求，客戶並不總是正確。如果我們把客戶需求的每個零零碎碎都加入產品中，沒有人會要我們的產品。 如果我們屈從一個客戶的一時的興致， Basecamp 就會有： 全面的時間跟蹤， 全面的帳單，全面的會議安排，全面的日程安排，全面的附屬任務系統，全面的即時消息聊天，全面的wiki功能，和全面的隨便什麼你能想到的。 然而， 我們通過客戶調查得到的第一號 需求就是 要 保持 Basecamp 簡單 這裡還有另一個例子： 儘管有一些怨言， 我們決定產品不支持IE5， 這樣就有 7% 的市場被我們抹去了。但是我們人問我去關心剩下的 93% 更加重要。 為IE5 修補產品錯誤和測試在時間上不划算。我們寧願為其它93%的每個人作一個更好的產品。 作為一間軟件研發公司，你必須扮演過濾器的角色。 並不是每個人建議的每件事都是正確答案。 我們認為客戶所有的需求並不總是正確。 你不得不時常讓一些人傷心失望。 關於這點， 作為一間研發公司熱愛你的產品是最重要的。如果你的產品中摻和了一些你不認可的因素，你將不會愛你的產品。這是要否決你不以為然的客戶需求是必須的，這一點的另一個明證。 前主管說過一句名言：「不要讓你的產品，成為妥協之下的一坨美麗大便&#8230;」 產品推出的第一版，通常是我嘔心瀝血、呵護備至的最愛。但，當產品慢慢長大，歷經修正、改版之後，我看到原本純淨可愛的小嬰兒，變成一隻巨大可憎的怪獸。 我還愛嗎？愛，但只剩下切不斷的情感在維繫。 小小柯，你可別變成綠巨人浩克啊~]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;譯言 &#8211; Getting Real 翻譯&#8221;:http://www.yeeyan.com/articles/view/4811/1958</p>
<p>樂於向客戶說 不</p>
<p>至於特性需求，客戶並不總是正確。如果我們把客戶需求的每個零零碎碎都加入產品中，沒有人會要我們的產品。</p>
<p>如果我們屈從一個客戶的一時的興致， Basecamp 就會有： 全面的時間跟蹤， 全面的帳單，全面的會議安排，全面的日程安排，全面的附屬任務系統，全面的即時消息聊天，全面的wiki功能，和全面的隨便什麼你能想到的。</p>
<p>然而， 我們通過客戶調查得到的第一號 需求就是 要 保持 Basecamp 簡單</p>
<p>這裡還有另一個例子： 儘管有一些怨言， 我們決定產品不支持IE5， 這樣就有 7% 的市場被我們抹去了。但是我們人問我去關心剩下的 93% 更加重要。 為IE5 修補產品錯誤和測試在時間上不划算。我們寧願為其它93%的每個人作一個更好的產品。</p>
<p>作為一間軟件研發公司，你必須扮演過濾器的角色。 並不是每個人建議的每件事都是正確答案。 我們認為客戶所有的需求並不總是正確。 你不得不時常讓一些人傷心失望。</p>
<p>關於這點， 作為一間研發公司熱愛你的產品是最重要的。如果你的產品中摻和了一些你不認可的因素，你將不會愛你的產品。這是要否決你不以為然的客戶需求是必須的，這一點的另一個明證。</p></blockquote>
<p>前主管說過一句名言：「不要讓你的產品，成為妥協之下的一坨美麗大便&#8230;」</p>
<p>產品推出的第一版，通常是我嘔心瀝血、呵護備至的最愛。但，當產品慢慢長大，歷經修正、改版之後，我看到原本純淨可愛的小嬰兒，變成一隻巨大可憎的怪獸。</p>
<p>我還愛嗎？愛，但只剩下切不斷的情感在維繫。</p>
<p>小小柯，你可別變成綠巨人浩克啊~<br />
<img src="http://www.sfgate.com/chronicle/pictures/2003/05/18/pk_hulk-movie_ho.jpg" alt="綠巨人浩克" width="450"/></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/12/1375/%e6%91%98%e9%8c%84-%e5%bc%b7%e7%a1%ac%e7%9a%84%e6%84%9b/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[摘錄] 網購業者的行銷導師</title>
		<link>http://blog.planism.com/archives/2007/09/12/1374/%e6%91%98%e9%8c%84-%e7%b6%b2%e8%b3%bc%e6%a5%ad%e8%80%85%e7%9a%84%e8%a1%8c%e9%8a%b7%e5%b0%8e%e5%b8%ab</link>
		<comments>http://blog.planism.com/archives/2007/09/12/1374/%e6%91%98%e9%8c%84-%e7%b6%b2%e8%b3%bc%e6%a5%ad%e8%80%85%e7%9a%84%e8%a1%8c%e9%8a%b7%e5%b0%8e%e5%b8%ab#comments</comments>
		<pubDate>Wed, 12 Sep 2007 02:21:38 +0000</pubDate>
		<dc:creator>cokeyko</dc:creator>
				<category><![CDATA[Product]]></category>

		<guid isPermaLink="false">http://blog.planism.com/archives/2007/09/12/1374/</guid>
		<description><![CDATA[&#8220;V怪客的電子商務怪談&#8221;:http://talkec.blogspot.com/2007/09/blog-post_06.html 傳奇基金管理人彼得.林區(Peter Lynch)最著名的投資法是從逛街找靈感，我則習慣從大眾傳媒或異業通路的行銷動態，來擷取經營網路購物的技巧。我樂意將他們分享，我相信應該也能給你豐富的啟發。 1.東森電視購物 / 學解構及推銷商品 2.蘋果日報 / 學資訊導讀及下標法 3. 詹仁雄製作的電視節目 / 學習操控觀眾情緒 網購服務業除了賺錢獲利之外，應該要有讓顧客感動的經營理念，賣東西給顧客就視同賣東西給自己的家人，不敢給家人用的劣質商品，就不該賣給顧客。就我所認識，身邊業界真的有些購物網站或供應商經營者是這樣用心為顧客著想。 詹仁雄最近很紅，大家都在談他，但不得不承認他是箇中高手。]]></description>
			<content:encoded><![CDATA[<blockquote><p>&#8220;V怪客的電子商務怪談&#8221;:http://talkec.blogspot.com/2007/09/blog-post_06.html</p>
<p>傳奇基金管理人彼得.林區(Peter Lynch)最著名的投資法是從逛街找靈感，我則習慣從大眾傳媒或異業通路的行銷動態，來擷取經營網路購物的技巧。我樂意將他們分享，我相信應該也能給你豐富的啟發。</p>
<p>1.東森電視購物 / 學解構及推銷商品<br />
2.蘋果日報 / 學資訊導讀及下標法<br />
3. 詹仁雄製作的電視節目 / 學習操控觀眾情緒</p>
<p>網購服務業除了賺錢獲利之外，應該要有讓顧客感動的經營理念，賣東西給顧客就視同賣東西給自己的家人，不敢給家人用的劣質商品，就不該賣給顧客。就我所認識，身邊業界真的有些購物網站或供應商經營者是這樣用心為顧客著想。</p></blockquote>
<p>詹仁雄最近很紅，大家都在<a href="http://mmdays.wordpress.com/2007/09/11/pride_and_prejustice/">談他</a>，但不得不承認他是箇中高手。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.planism.com/archives/2007/09/12/1374/%e6%91%98%e9%8c%84-%e7%b6%b2%e8%b3%bc%e6%a5%ad%e8%80%85%e7%9a%84%e8%a1%8c%e9%8a%b7%e5%b0%8e%e5%b8%ab/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

