Archive for the 'Planning' Category

[摘錄] Feature 和 Function的差別

出處:English Vincent

feature,本意還是特點,指有鮮明特徵的方面。function則強調產品目的和用途。你上面所據的例子其實還是在描述ipad的特點。只是很多產品,特別是消費數字產品,它的特點也正好是其所包含的多種功能。其實,在傳統產品中是很容易區分feature和function的。比如說自行車,它的功能很少有人再描述,而特點不外乎foldable, serviceable,alloy wheels之類的東西。

我個人覺得,為什麼在介紹產品時很少看到用function,是因為日常產品的基本功能無人不知,只是特點有所不同。比如買手機,我當然知道是用來打電話的,我想知道的只是與眾不同的features,這時一般的問題是"what’s the difference?"。但假設你在介紹一個全新開發的又沒人認識的東西時,我想function是必須要先予說明的,這時的問題是"what’s this?"。

  • Feature:特點、特徵,What’s the difference?
  • Function:功能、用途,What’s this?

其實,硬要區分兩者的不同,是沒什麼必要。但在寫網站企劃的文件時,兩者分一下,不僅有助於企劃者撰寫,也有助於閱讀者理解。

[摘錄] 學習騰訊的產品管理之道

出處:cnBeta.com

馬化騰帶著一大批產品高管自上而下,持之以恆地推動產品本位的管理體制規範化,並不斷地創新和優化這套體制,使得整個公司上上下下融入了「產品的基因」,最終成就了「產品的騰訊」。

1、設置一個質量監控小組,由經驗非常豐富的高Level的產品人員構成,賦予他們很大的權力,去監控和規範所有的產品項目。並且用KPI來制約產品項目服從這些規範。為了不搞教條主義,很多規範都是在立項之初,由項目經理和這個小組共同確認的,未必是硬性指派,一經確認就受到嚴格監控。確保好的規範不流於空喊口號。

2、每個產品都設置公開的反饋論壇,突出外部入口,積極徵詢用戶意見,並以內部輪班方式回覆「每一條」有價值的反饋,要求以「人對人,面對面」的溝通態度來進行解答,禁止機械問答。公司高層(包括小馬哥)不定期巡查每一個產品論壇,一旦發現有不認真回覆用戶的情況,立即予以訓誡。確保產品人員與用戶長期保持近距離接觸。

3、每個產品都設置內部的交流平台,分為兩部分,一塊類似留言板,由產品主管發佈項目的進度、動態;另一塊是論壇,向公司內部所有人開放,接納反饋。在騰訊內部已經形成了非常活躍的氛圍,甚至以該平台人氣高漲為榮(至少你主管會喜歡這個),利用這個平台跨項目提意見,或是項目組內部交流思維碎片都很常見,達到了群策群力,內部監督的效果。

4、設置產品架構師這樣一個職位,由少數幾個技術精英,負責所有項目的系統架構搭建,只搭架構,確保每個項目的底層合理性。

5、執行項目總結制度,在每個版本上線後,由相應的策劃-開發-測試人員開一個會,每個人都總結在這個版本過程裡,有什麼心得,有什麼失誤,可以怎麼改善,尤其注意改進三方人員的配合過程。用制度的方式來強制反省,強制跨職能溝通。幾個版本下來,項目效率就會有明顯的提高。

6、執行灰度發佈政策非常之徹底,一個版本會經過若干級的內部測試,再向外部用戶逐步放量升級,不斷修正問題之後,最後進行大規模發佈。確保提前發現問題,受影響的用戶面儘可能小。與此同時,騰訊異常活躍的內部交流氛圍,也能讓產品在內部測試時得到較多專業反饋。

7、擁有背靠客戶端,強大的數據挖掘功能,具體描述起來比較複雜,總之非常強大,數據細緻到令人吃驚的地步。數據挖掘部門的地位也是相當高的。我以前說過「統計數據太單薄無法推導出可靠結果」這樣的話,但在騰訊的數據挖掘機能面前,這句話恐怕要改口。

8、設置對新人和新項目的風險管理機制,比如3個老程序員帶1個新程序員,將技術管理和具體開發的工作徹底分離,每週進行代碼走讀,對新產品採取格外嚴格的測試安排等等,使得缺乏經驗帶來的技術損害被降至最低。

滿不可思議的~

[摘錄] Linkedin創始人霍夫曼:成功的三個秘訣

出處:新浪科技

我意識到未來的世界將受到兩股力量的作用。

一股力量是工作環境將如何變化——從某種程度上說,每個人都可以成為創業者。

另外一股力量則是互聯網,這些人都可以在網上建立資料,以便其他人可以找到他們。你可以通過網絡,和人進行溝通,更好地規劃你的發展道路。

分享成功秘密

1、合理高效安排時間

當人們問我如何在工作和生活之間實現平衡時,我只會微笑置之。我會高效安排我的時間,安排會議時間不超過15分鐘。我還努力著讓人們瞭解,一封簡短的電子郵件並不是冷漠的表現。

2、靈活調整計劃

企業家總是認為,「嗯,我已經做了決定,那就堅持到底,絕不放棄。」但我建議他們認真考慮一下,他們的商業計劃是否真的無可指摘,他們是否需要作出改變。根據現實靈活調整計劃,你才不會盲目從事一個項目五年,最後才無奈接受失敗。

3、別做完美主義者

我經常對互聯網企業家說,「如果你總是對產品吹毛求疵,那麼你的產品肯定已經推出的太晚了。」作為一家企業,你有必要盡快推出產品,和消費者進行溝通,瞭解他們的意見反饋。這有助於指引你的發展。

別做完美主義者,嗯~ 看狀況。

[摘錄] 產品管理 vs. 項目管理

* 原文:”Jeff Lash”:http://www.goodproductmanager.com/2007/09/24/product-management-vs-project-management/?PHPSESSID=ca265820eef17812d1c37c6e6682a28a
* 翻譯:”hawking”:http://www.2tan.net/article.asp?id=29

項目經理的職責是在一定的目標、範圍、時間期限、預算以及其他制約條件下,試圖一次性完成一個成功的項目。一個項目經理需要分配資源,管理問題與風險,並且主要協調所有的各種必要因素以完成項目。當把他們跟產品聯繫起來時,項目也可能被要求承擔起創建一個產品,為產品提供新的特徵,或者是為產品創建新的版本或擴展的任務。當項目完成時,項目經理通常會被轉移到一個新的項目,甚至有可能是服務於一個完全不同的產品。

產品經理的職責是從頭到尾的服務一個產品,並使得產品持續成功。一旦創建產品的項目完成,而且項目經理轉移到下一個工作,產品經理依然會留下來管理產品,直至產品的整個生命週期。其他項目被聯繫到產品可能是由於產品經理的發起,產品經理會始終在產品生命週期,定義項目的目標,並帶領團隊完成擬定的商業目標。

大陸稱「項目經理」,台灣叫「專案經理」。

我負責專案,但我是產品經理。

[摘錄] 擁有專案團隊最快的方式

“給新手PM之3 – 配置資源”:http://userxper.com/blog/archives/53 @ 悠識數位 by Richard Tsai

擁有專案團隊 (Team) 最快的方式,你知道是什麼方式嗎? 很簡單,只要僱用一個英文名字叫做 Tim 的人,就可以跟客戶宣稱我們有 Team 了。

這是一位好友在非常無奈的情境下,想出來的冷笑話,當時他就在沒有 Team 的情況下苦中作樂,才想得出這種冷笑話。

太好笑了 😀

[摘錄] web 2.0 設計指導之一:簡單

“wowbox blog (網頁設計知識庫) “:http://www.wowbox.com.tw/blog/article.asp?id=3068

2.0風格設計代表著聚焦、乾淨和簡單,但那並不代表著要極簡主義,我們應該用少量但必需的元素去達到我們的目標; 有個原則是我一直堅持的:假如解決某個問題有兩種方案,那麼更簡單的就是更好的。

為什麼簡單更好

1. 網站和每個頁面都有目標;
2. 用戶的注意點是有限的資源;
3. 幫助用戶找到他們想要的(或讓用戶注意我們希望他們看的內容)是設計師的職責;
4. 屏幕上的元素吸引眼球,元素越多,用戶去關注的各種不同的事情就越多,同時他去關注重要內容的幾率就下降了;
5. 所以我們需要很確定的交流方式,也需要把信息噪音減少到最少,那代表著我們要找到一個盡可能少用元素的解決方案,那就是節約元素即簡單。

何時/如何讓你的設計簡單

1. 何時 始終如此
2. 如何做 有兩個方面能讓你成功做到簡單
— 在不影響效果的情況下,去掉多餘的元素
— 能達到同樣效果的可行方案中,選擇更簡單的

看起來達到完美的結果,不是沒有東西可再添加,而是沒有任何東西可被去除的時候,每當你設計的時候,有意識的把去除多餘的視覺元素作為準則。

不要把注意力特別集中在和頁面目標相關性比較小的區域,因為用戶視線在關注這些時會分散在主要內容和導航的注意力。利用視覺細節如線條、文字、形狀和顏色去傳達信息,而不僅僅是為了裝飾。

並不反對網站設計的豐富、複雜或美感性

簡單的意思:無論採用什麼方式,只要是為了讓信息傳達更順利的元素是越多越好,當然,通常你要傳達的不是硬數據,而是軟數據;

硬數據:指事實,如新聞、股票價格、列車時間或你銀行賬戶的存款……

軟數據:涉及信息傳達的質量,如公司給人的第一印象,服務提供者是否親切,一種產品是否適合你……這些都是同樣重要的。

無論你要傳達的是硬數據還是軟數據,你都應該有意識並謹慎的使用元素數量。

原文網址:http://www.webdesignfromscratch.com/web-2.0-design-style-guide.cfm

[摘錄] 內容設計,初始內容

“白鴉,以用戶為中心的設計”:http://uicom.net/blog/?p=719

Content Design(內容設計)即涉及產品需求也涉及到(產品和用戶)互動過程中的具體環節。大多數團隊中只有PM才會涉及到相關工作,一般情況下不是基於用戶需求就是如何展現,很少涉及具體的互動環節也很少會有人整體上去綜合思考內容的設計。

事實上沒有什麼產品是「難用」的,只要用戶有了使用的需求興趣,基本上所有產品都會變得容易。但,也沒有任何產品是「好用」的,如果用戶沒有使用樂趣怎麼做都難用。

一切的根本在於需求和興趣,滿足用戶需求的是內容,引導用戶用戶興趣靠「初始內容」。

關於「初始內容」的設計,主要是指在用戶未正式使用(不只是「未登錄」,登錄了但沒有深入使用也算)前給他們展示什麼,讓他們可以(不可以)做什麼。其主要設計原則與用戶的認知積累、目的性有著非常直接的關係。

有些產品把「內容」做的很早讓用戶有了一定的認知。於是,他們可以讓用戶進來後直奔主題。

有些領域用戶進來就帶著強烈的需求,或者已經有了足夠的認知積累。於是,需要讓用戶進來後直奔主題,而無須設計過多的「初始內容」來干擾用戶。

在更多用戶沒有「認知積累」的時候,「未正式使用」之前整個產品只是一本又厚又難懂的「說明書」。很多用戶進入一個新網站時,會先「看看」然後「逛逛」,再後才是深入去用。

在「未正式使用」之前讓他看到什麼、逛什麼? 直接影響新用戶的轉化率。如何讓用戶「有興趣」並「快速」讀懂,然後「產生使用的慾望和興趣」,是所有產品設計過程中都會遇到的問題。

受教了~

有興趣的話,建議回讀原文,寫得很詳細,也舉了一些網站當作範例。

[摘錄] 跟著用戶走到溝裡

“白鴉,以用戶為中心的設計”:http://uicom.net/blog/?p=718

交互設計大師、「Macintosh」之父 Jaf Raskin 曾說:好的設計不會讓使用者養成對今後工作不利的習慣,但設計人員卻經常有意無意地給用戶設下壞習慣的陷阱。事實上,良好的設計應該在給用戶帶來幫助的同時,把對其未來可能出現的限制性障礙降到最低, 保持使用者自由的可擴展性。這說的是交互設計。放在產品上亦然。

當浴缸裡只有一碗水的時候點一滴墨就會使整個浴缸變得骯髒,當浴缸裝滿以後偶爾一兩滴墨水根本無所謂,而且那個時候看著乾淨的一缸水也沒人「道德敗壞」的去滴墨進去。

這些很有技巧性的「引導」我們很難在國內的模仿者那裡看到,能有意識去做「限制」或者「刪除」的網站已經算是很不錯了…

確定方向是什麼、搞清楚什麼東西對用戶才有真正的價值,實在很難但也實在很重要。

「我們完全是根據用戶需求的演變而發展產品的,用戶需要什麼我們就滿足什麼」其實都是成功後騙人的鬼話。

雖然有人說顧客永遠是對的,但顧客卻不一定知道他要的是什麼。

[摘錄] 創業公司沒有固定設計團隊,很好。

“白鴉,以用戶為中心的設計”:http://uicom.net/blog/?p=701

不用在公司大張旗鼓的搞個「設計部」,往往搞一個團隊並冠上「設計部」以後,你會發現你的產品設計反倒更糟糕了。最主要還是調動所有人一起來參與設計。再說,你們也沒有那麼多錢請鳳毛麟角般的「好設計師」。

重申那個老掉牙的觀點:不是只有設計部門才應該去做設計。參與產品的用戶體驗設計是所有團隊成員的責任和義務,設計師首先要做好的應該是設計的統一協調和管理,然後才是去做設計本身。

這篇文章裡面,敘述的一些故事,讓我感同身受、感觸良多,值得閱讀 / 玩味。

“不是只有設計部門才應該去做設計”:http://uicom.net/blog/?p=514 @ 白鴉,以用戶為中心的設計

產品設計差易用性差確實跟設計人員有關係,而且有直接的關係;但並不是說所有的責任都在於你們的設計部門弱! 一個產品的UE設計工作不只是UE部門要做,不是只有設計部門才能去做UE設計。你們的PM和RD甚至包括客服部門一樣應該承擔產品設計不好的責任,也有義務一起去改進!

可用性應該只能算是一個新的詞或者新的工種,並非是一個新的理念或概念。實際上在很早以前我們一開始做網站設計、產品設計的時候就在搞可用性相關的工作, 只是那個時候我們沒有專門安排一個職位或者部門叫做『可用性工程師』而已!

不是只有叫做『可用性工程師』的人才能去做可用性,也不是只有『可用性工程師』才應該去做可用性。所以我們現在其實是在把工作做的更精細、更符合用戶而已,而非「提出了一個新的概念」。

在這個要求高質量無縫協作的年代。無論是什麼部門或什麼角色在主導項目,溝通永遠都應該是第一位的。

各個角色之間的共同語言是溝通的基礎,RD(技術)不應該只懂代碼、PM(產品經理)不應該只懂產品和市場、UE也不應該只懂用戶體驗…

一個好的團隊應該是項目補充的。大家是衝著一個目標的團隊,要做的是互相幫助著衝向目標. 而絕非各自完成任務!

所以,我認為:一個產品的用戶體驗設計應該:有UE部門主導、多個部門一起努力。

在說「我們不只是美工」的同時一樣要意識到「程序員也不只是寫代碼的」!

好文一篇~ 推!

悶著頭寫一堆文件、想辦法弄一堆流程、三不五時開一堆鳥會,這樣就能搞出產品嗎?

把時間浪費在這邊也不是不行,反正領薪水的,撐愈久領愈多。不過,看到時間一點一滴的流逝、市場一步一步的被蠶食、產品一天一天的崩壞 / 老化。身為開發團隊的一份子,是毫無感覺,還是情何以堪?

再說,製作人也不只是寫 spec 的…

■ 延伸閱讀

* “贊同「創業公司沒有固定設計團隊」”:http://robertmao.com/archives/472
* “創業公司是否需要全職設計師?”:http://uicom.net/blog/?p=702

[摘錄] Design Bookmarklet

“Idea Grapes”:http://blog.yoren.info/2007/12/21/486/

Allen Jardine製作的 Design Bookmarklet 一共有四種功能,如果你和我一樣,做網頁時,有非得把各種元素對齊不可的強迫症,那麼這個工具將非常實用:

# Grid:可依需求直接輸入數據(尺寸、欄位數和列數、邊距等)在頁面中產生格線。
# Rule:在上方和左側顯示尺規,並且可以拖曳出準線(guides)。
# Unit:在頁面中測量任意兩點間的距離。
# Crosshair:隨滑鼠游標出現的十字瞄準線,並提示座標。

我也有對齊強迫症…