我金睛火眼地盯著老婆的⋯⋯ 手機。她用手指滑動著畫面，終於找到那「讚賞鍵」，猶豫了一會後，她點了一下我的頭像，畫面沒反應，令我的心情有點忐忑；然後她再點「拍手」，這次成功了！
可是當那「登入視窗」彈出來後，她卻立即把它關掉了。
初創團隊想像到產品能飛天遁地，天下無敵，推出市場後卻發現完全賣不動。十個做產品的人，九個都要克服這閉門造車的引誘。
我們公司所做的產品，其中一個焦點是一個「讚賞鍵」。那只是一個小小的長方形的用戶介面，功能上看似超簡單：就是讓用戶登入後點一點讚，最多點五下，並提供一些連結到作者的網站。這個讚賞鍵可以嵌在任何網站上，能載上作者的頭像，有一句 CTA (Call to action) 呼籲讀者點讚，支持創作。
很完整的構想，簡單直接，對吧？我們覺得每個支持作者的讀者都會理所當然樂意點讚的。
數據這樣說
我在 Google Analytics 觀察數據，發現閱讀文章的人雖然很多，但是卻不如我所料一般樂意點讚，實際數字是：
每 100 次文章閱覽，只有少於 3 次點讚。
就算不看數據，在跟用戶接觸時，也聽到有意見反映在同一篇文章中從 Medium 得到的拍掌數字遠遠超過從「讚賞鍵」所得的數字。那代表讀者並不是不樂意「掌聲鼓勵」，而是有其他原因阻礙他們點擊那個鍵。
基於效能考慮，我們沒有採用 User Heat Map 的方案追踪用戶點擊的行為，所以最直接找出答案的方法就是做用戶體驗 (UX test) 測試。於是我便找了老婆幫忙，因為當我有需要時，她隨時樂意相助。
而更重要的，老婆是一個非技術人，正是我們產品的主要目標用戶。
測試結果
測試的過程很簡單：我請她用手機讀一篇文章，然後點讚。我不給她其他指引，看看她是否能夠只靠使用者介面的引導完成任務。
測試結果就如本文開首所述：她不知道要點那裏（先點了頭像），然後她被登入視窗嚇怕了。
之後我再找了不同的朋友和用戶做相同的測試，發現大家都有類似的反應，有些人會點了名字而跳進轉賬頁面，有些人雖然沒有立即關掉登入視窗，但也會猶豫地提出私隱權的疑慮。
用戶轉化要一步一步來
邀請用戶點一下「讚」已是如此不容易，何況要用戶提供自己的個人資料註冊？數據顯示點了「讚」的用戶中，
超過 60% 的人會在登入視窗彈出時放棄操作。
這情況跟我老婆所做的用戶體驗測試結果一致。就算肯在此步驟選擇註冊的用戶，也不見得一定會完成整個註冊程序。數據顯示就算通過社交媒體登入，只有 36 % 用戶會繼續完成註冊。結果：
從點讚到註冊成功的用戶轉化率僅 14%
在客戶轉化的過程中，每一個步驟都會有流失。團隊還在設計如何改善每個轉化點。
接受新概念，也是轉化過程
一個簡單的用戶介面轉化過程也有如此流失率，可想而知，要用戶接受一個前所未有的概念，轉化難度有多高。
一年半前我們團隊開始研究區塊鏈的技術，當時我被技術背後所提倡的開放精神所吸引。於是我又找老婆來做一次「用戶體驗測試」。我嘗試跟她解釋一遍區塊鏈技術能解決什麼問題。她專心地聽我演說，但作為非技術人她其實沒法聽懂，她表現出的支持眼神純粹只是因為她是我老婆而已。
她給我的啟發是：我抓錯重點了，若我們要開發一個給大眾使用的產品，得用大眾能聽明白的語言，能看得懂的包裝才行。一天我老婆沒聽懂，一天這產品還得繼續調整。
於是我們後來在跟大眾解釋這項目時，把闡述的方向倒轉過來，淡化難懂的技術詞彙，借用一般用戶能聽明白的「點讚」行為，並且把主題不斷重複企圖讓概念內化於用戶心中。在說服市場接受高深難懂的底層技術以先，先嘗試說服市場接受容易懂的概念。
用戶轉化得由淺入深，一步一步來。
任何事情的轉化也一樣
最近我把生活的事情從產品開發的角度審視，發現原來有趣得很。逐步轉化的過程其實可當為生活常識。
例如我的目標是想令女兒愛上閱讀，她的轉化必然是一步一步地發生：首先讓她願意踏走進圖書館，再讓他願意自行拿起書本，才推介看由淺入深的書目。太急功便容易把把用戶（女兒）嚇跑了。
又例如我的目標是想令老婆愛上運動，那她的轉化也必然是一步一步地發生：首先願意走出戶外，然後願意做 7分鐘運動，再來 30 分鐘緩步跑，然後才是爬三小時的山。
最近我多寫了一些文章，嘗試看看能否走出另一條路來。我也不敢太貪心，先邀請包括我老婆在內的共十個好朋友成為我的讀者會會員。畢竟就算我寫的文章不好看，他們也會比較願意耐着性子提供意見。況且若連最親近的人也不願成為我的讀者，我又怎能期望其他人會肯為我的文章點讚呢？連最好的朋友也不肯為我的作品買單，又怎會有其他人肯呢？
於是我成立了只有數個成員的「黃牛山人讀者會」，這就是我計劃中的「最低限度能用版本」 (Minimal Viable Product, MVP) ，用來驗證我自己是否適合把寫作當志業。 除了用戶深度的轉化，還有寬度的轉化，其理相同。有說要做初創募資，便應該先從最信任自己的親人朋友開始。
敏捷開發
上述有關「讚賞鍵」的例子說明了那怕是一款很簡單的產品，市場的期望跟團隊的期望也會差了那麼一大截，原設計者往往有盲點。在產品開發的過程中如果我們一次把大部分資源投入產出一件心目中「完美」的產品，結果往往是被市場期望的落差狠狠教訓，然後沒有足夠的資源繼續修正。這是為什麼初創企業都傾向使用「敏捷開發」 (Agile Development) 的模式開發產品，先推出 MVP，然後快速地根據市場反應作調整。
然而知易行難，很多從前做慣了外包項目的人（包括我自己），習慣要在項目開啟前計劃好整個項目的時程和資源分配，據此仔細定好工作需求內容 (Job Spec)，否則總覺得無從掌握項目的進度。事實上敏捷開發模式確實較難在一開始預算資源；只是在經歷無數次的教訓後，我發現若信奉瀑布式開發 (Waterfall development) 期望一步到位地完成開發，大部份的結果是到最後既用光了資源，產品卻又賣不動或沒有達到預期效果。項目結果雖然是「面世」了沒錯，事情卻不能算是成功。
今是昨非，還是朝秦暮楚
敏捷開發的概念對人生規劃也很有用。與其要孩子從小便立志做這做那，不如讓他們學會靈活地應對環境轉變，適切地改變計劃，早一點嘗試失敗，學會接受挫折並修正目標。
要知道現在世界變遷的速度很快，年頭的計劃年中可能已經不適用了，今天的新知識下個月可能已經被推翻。把自己的人生過早定型，或分成標準的里程碑，其實是限制了生命的可塑性。不要說幾十年後，就只說十年後的世界會變成怎樣，誰又能說得準呢？智能電話才只流行了十年，已為人類的生活帶來翻天覆地的改變。
堅持一件事為終身志業的人固然可敬，但在變化急速的世界裏，這種堅持有時可能反過來變成不肯變通的藉口。相反，每隔一段時間檢討得失，修正目標，甚至改變整個方向，是十分負責積極的人生進路。只要有充分的理由，打倒昨日的我絕非朝秦暮楚。
擇善固執於今天，固執容易，難處卻更在判斷何為「善」，需要固執的往往是核心價值，而非形式。