最近在幫公司找 mobile app developer，跟不同的 developer 間有很多意見的交流，也從他們的開發經驗裡學到不少不同的邏輯跟觀點。
「你們的 app 看起來還很陽春，不像 Facebook 那麼完整」
「為何要像 Facebook 呢？為何要那樣『完整』呢？」
這個問題涵蓋了兩個區塊：
1. 觀摩其他人的產品很常見，可是我們往往陷入一個「我覺得很好」的圈套裡。我們每一個人充其量只能代表使用者的某一個類型跟面向，所以如果不去想想自己要開發的產品的定位跟本質，就很容易在「觀摩」時，開發出其實並不是符合自己產品特性的服務。
例如，Pinterest 問世時，「瀑布流」（waterfall）的佈局蔚為風潮，很多網站紛紛把自己的瀏覽界面改得很像是 Pinterest，不過卻產生了很多問題。
主要原因在於 Pinterest 的產品設計邏輯與其產品原創發想時的需求跟定位有關，許多需要使用者閱讀的網站採用了同樣的設計，卻忽略了原始構想的「適性」（adaptive）的問題，試想一個以瀏覽視覺元素為主的設計，套用在以文字內容為主的網站，會有什麼結果呢？
「不好用」，這是可能得到的答案，也是大多數使用者不習慣的時候常說出口的一句話。
2. 什麼是「完整」呢？這是一個因人而異的問題。
曾經，有一個朋友這樣問「你們為什麼不新增這個功能呢？這樣很難用，我去用 Facebook 就好了」。
我的答案是：「這個功能不適合我們。如果 Facebook 推出什麼功能，我們就非得也要有相同或類似的功能，那麼使用者的選擇基礎相同，必然會選擇具備豐富資源、金援的產品，這樣我們被放在同一個盤子上比較，便失去了特色了。」「貓是貓，不是狗，要如何要求貓學狗叫呢？」
手機是一個不同的介質，有其限制、特性，以及使用時機的限制，人們使用手機的時間通常非常短、碎片化，所以滿足在行動平台上可能的幾種主要需求便已足夠，我們必須了解哪些是最主要、大部分使用者會使用到的功能，把這些功能做好，那麼就沒有完整與否的問題了，因為使用者的需求永遠是不滿足的，要照顧到所有人的需求是不可能的任務，但千萬別嘗試想把所有功能搬到手機上，否則即使做得「很完整」，最後可能還是會得到同一個答案：「不好用」。
使用者需要很多功能嗎？
其實，使用者懂得選擇符合自己需求的產品，但有必要不斷的在自己的服務或產品上新增功能嗎？
我的答案是：是，不是。
是：要推陳出新，甚至整個翻新，讓使用者嚐鮮的心態獲得滿足，但另一方面必須要顧慮到設計的一致性，避免新的設計或功能偏離了產品的定位。
不是：同時間，隨時檢視已經開發好的功能的使用狀況，最好的方法是透過統計數字來觀察使用的狀況，當使用的頻率不高時，我們必須回頭思考兩個問題：是這個功能真的沒有需求了（沒太多人使用），還是這個功能欠缺某些補給，例如：更好的整合、更明顯或流暢的位置及使用流程。對於真的不受歡迎的功能，必須當機立斷淘汰（retire）掉，因為過多的功能反而容易造成使用者的混淆，增加使用者使用時的選擇的成本。
其實這也是很多人設計產品時常犯的問題：拿一個產品定位不太相同的產品來相比，然後要求自己跟那個產品一樣『完整』。其實只要使用者的主要需求被滿足了，他們真正要的往往並不是「完整」，而是「順手」跟「夠用」。
所以把時間花在「想像自己是使用者的情境」來設計一個產品才是正途。當然，「自己」永遠都只能代表其中一個或一種使用者，所以，一個雛形完成時，可以多觀察人、多從其他人的反應跟經驗中得到回饋更好，這樣產品才容易接近使用者實際的需求跟使用情境（use case），而不是產品設計者「想像」中的需求。
讓使用者「順手」很重要
再來則是「順手」。
想想看 Microsoft Word 有多少個功能？選單上看得到的項目，可能一兩千個，看不到的功能，加總起來可能好幾倍。但你常用或覺得用得到的功能有多少個？
「大概 15 個吧」，很多人大概會回答類似的答案。
既然你常用的功能只有 15 個，為什麼還要把時間花在打造一個需要寫一本書，拉長學習曲線，花去很多使用者時間，可能還會中途因為挫折而不想使用的產品跟功能呢？
把精神花在專注開發使用者最需要的少數核心功能，確保核心功能可以滿足使用者「順手」的需求，再來思考如何完善周邊「必要」的附加功能，才不致在使用者覺得還不夠順手時，增加了使用者可能產生的新挫折感。
減法開發哲學
我在大公司受過的完整訓練跟經驗是：大公司的那一套完整產品開發經驗跟流程不適合套用在每一個公司，特別是新創公司（startup）。
Startup 本身的資源有限、人力有限，必須要思考如何把資源投注在最重要的項目上，才不致浪費時間在開發「只有 20% 需求的功能」上 – 沒錯，要取悅所有使用者很難，因此，當資源有限時，必須取捨。
先照顧大多數人的需求，確保絕大多數使用者是被滿足的，然後行有餘力再來檢視是否必要滿足剩下的使用者需求 — 有的時候，維持使用者的「飢餓感」是必要之惡，因為，很多時候連我們自己都不確定是否是短暫的需求，抑或可能發展出長久的使用習慣 — 這個問題跟購物慾望很像，當我們很喜歡一件商品時，心裡頭可能會開始囤積慾望，不斷的堆積自己必須購買的理由，說服自己「我需要」，進而促成實際的購物行動，但很可能一兩個禮拜後，這件商品就被晾在一旁了。
我認為 Startup 適用的開發方法是「減法開發」。
什麼是「減法開發」呢？
1. 盡量列出需求
首先，團隊可以天馬行空發想，依照產品的主要定位構思不同的功能，並列出詳細的使用情境（use case），假設總共列出了 100 個待開發的功能。在這個階段，我們先不去構思其可行性或是開發的時間。
2. 去蕪存菁
現在，我們提出一個實際的假設：「我們的資源有限，只能開發其中 50 個功能，哪 50 個功能是非得要優先開發的？」
留意到了嗎？第二個階段我們必須思考的問題是：當我們必須取捨時，哪些功能是真正使用者必要使用的。取決「必要」性的關鍵在於，哪些功能是可能「現在（或暫時）沒有也沒有差別」。
3. 專注在核心項目
第三個挑戰來了。「我們只有一半個月時間，依照目前的人力與資源，算一算可能只有 10 – 20 個功能可以如期被開發完成。」
我們必須在 50 個我們在第二階段覺得「一定要開發」的功能裡，再篩選出「真正必要」的功能。團隊只需要專注在把第三階段列出的 10 – 20 個功能開發完成即可。
因為，新創公司往往沒有太多的資源，必須要在很快的時間內「做實驗」（interation），知道實驗的結果，然後不斷的從實驗結果及經驗中快速修正，繼續做下一個實驗，花費太多時間在開發一個大型專案，很容易把僅有的有限資源不知不覺中就耗費掉了。
把使用者的抱怨與不滿變成助力
這是一句老話，可是我們往往（或偶爾）會忘記。千萬別一開始就把所有資源都抑注在一個超大型的專案，因為對很多 Internet 的使用者來說，早已習慣測試新的服務跟產品，並提供自己的使用經驗回饋，別放過廣大的 beta tester 群所能貢獻給你的價值。
開發一個超大型專案所冒的風險不小，因為一個新功能或新產品，往往推出後三個月內就會決定生死：這是一樁一翻兩瞪眼的生意，很快就會知道結果。
所以，如果所冒的風險是如此，我們是要選擇要花一年時間開發一個超大型、超完美的專案，還是很快地在三個月內先推出簡單的版本呢？我會選擇後者。
曾經，有一個公司耗費了很多人力、資源，花了兩年時間開發一個新的服務，結果在一年半時，市場竄出了新的同樣的服務，並且快速地在市場空窗期滿足了使用者需求，擄獲了很多使用者的心，形成一股不小的「實力」，最後只得花大錢跟其他競爭公司競標，買下這個新的服務。
「測水溫」是 Internet 軟體或服務的常態，使用者早已習以為常，對於「不完美」完全可以理解，也很樂於嘗試，因此，先推出核心的功能測水溫，反應好再持續專注開發其他必要的周邊功能來使得這個新服務變得更完善，反應不好，也不必冒著抑注了所有精力，花費很多時間開發一個大專案，卻可能很快便知道不討使用者歡心的結果的風險。
一次給一點，使用者最高興
我承認這是我以前求學、工作時使用過的伎倆 – 使用者的期待是需要被管理的。
如果一次推出 100 項功能，大部分使用者不見得會覺得高興，反而因為面臨太多選擇，亦或是在使用者遭遇到程度不等的問題，在這些功能裡「迷航」了，他們心裡頭可能會覺得「不好用」。
其實，使用者接觸一個新的服務都需要「學習」。每個使用者的學習曲線會依照他們的專業背景、接觸網路的時間長短等而有所不同，這還不包括「適應」的問題。試想：100 項功能要花多久的時間才能上手，甚至「適應」（順手）呢？
如果只推出 5 項功能，使用者可能會感到驚訝，很快地便可以上手，甚至可能到處廣為宣傳，使用者得到的成就感與滿足感與前者有很大的不同。
你會選擇哪一種方式呢？
