文/Ivan Wei
在進入網路業前近七年的時間，我都在消費性電子品牌廠，公司主要的產品都是以硬體裝置為主，手機、平板、車用、錄影盒（Video capture device）等，曾遇過一個實際案例：當時在開發一個遊戲錄影盒，這個裝置能接到 Consol 或是 PC 透過軟體錄影，而裝置正上方有一個巨大的實體錄影按鍵，總經理問設計團隊，這個按鍵的機構件，其耐用性應該達到多少次點擊？
Materials from Business vector designed by Freepik
無法靠經驗回答的問題
因為機構件涉及到材料成本（Bom Cost），耐用性高的零件、採購成本貴；耐用性低的，又擔心保固期內就壞了，反而多了客訴與新料件的成本。偏偏公司靠的就是銷售價格與成本的價差賺取利潤，當時能做的只有透過用戶訪談、實地觀察用戶，或是業務反饋、通路商的建議，再加上客訴能得到的資訊，幫助我們理解用戶使用產品的狀況。但被問到耐用性的問題時，當時除了答不出來，更不知道該用什麼方法去找出這個答案。而從這個案例看來，有幾個洞見（Insight）值得深思：
- 如果當時可以透過少量測試的方式，找到核心的用戶或是粉絲；或是第一批出貨，加上硬體按鍵點擊的數據埋點，得知樣本用戶每天的使用頻率，這個問題似乎就可以得到答案，並且協助零件的採購決策，在第二批挑選一個在保固期內無虞的機構件。
- 透過這些數據的蒐集，甚至能知道用戶是不是非常依賴這個硬體鍵的設計，還是大多用軟體去驅動錄影的功能，這對之後產品的改版是很有幫助的情報。
- 從軟體的數據埋點，也可以知道用戶大多是用來錄 Console 還是 PC Game，這還有助於商業拓展 （Business Development）與行銷（Marketing）。
這個案例的核心問題在於，過去我們並沒有軟體的Domain Knowhow去蒐集用戶用行為數據，而這在網路行業卻是一個習以為常的工作！
數據的價值
Material from https://pbs.twimg.com/media/BxPnJo-IYAA2xT9.jpg:large
上面的圖片，說明了用戶體驗和設計初衷的巨大落差。設計的概念模型（#ConceptualModel）是基於一個發展邏輯去組織的，大多是工程化的，就像我們的產品；而用戶的心智模型（#MentalModel）只在他自己關注的那一部份去探索，找到他自己的解決方案。再仔細觀察，如果沒有那一片草地，留下了用戶的足跡，我們也無法觀察到用戶的行為模式是如何，這就是數據的價值！再對照一開始案例的洞見，數據能幫助我們驗證用戶的操作行為、協助企業的商業拓展與決策。
驗證的重要
關於「驗證」這件事，如果你讀過精實創業（#LeanStartup），一定明白它是整體的核心思維，中國互聯網一句琅琅上口的話，把這個概念詮釋的很好。
小步快跑，快速迭代 － 用最小的成本去試錯、用最快的速度去驗證假說（Assumption），進而達到目標。
關於這個方法論，小可應用在產品上，大則可應用在組建一個新團隊或是一個新的業務線上。實際在開發CM Security這款產品時，光是2014年就迭代了超過100次，我們用了這個方法驗證了許多假說，有些失敗、有些成功，一年內達到了超過1億下載，從AARRR指標的各項數據結果看來，達到了非常好的的成果，而這個方法的執行的過程，完全可以用精實創業模型（#LeanStartupModel）來剖析。
Material from THE LEAN STARTUPMETHODOLOGY
應用在新的專案項目上，又是如何呢？事實上多如萬人以上的企業阿里巴巴內部，充斥著許多的微型創業團隊運用著精實創業的方法。這些團隊就是一支支的Task Force，從不同的部門裡調兵遣將，他們有一致的目標，彼此沒有部門利益衝突的問題，甚至設計、產品與研發相處的時間多過於和自己部門裡的同事，完全是一個新創團隊的氛圍。由幾個核心的成員去擬定策略、張羅資源，不管是招聘、和第三方談業務合作（BD），從公司的高度來看，這些微型團隊，目標也是驗證，而且是戰略佈局的MVP（Minimum Viable Product）。
Q&A
在很多次機會線下分享的場合中，常被問到幾個問題：怎麼實現單週迭代的節奏？為什麼產品開發流程裡沒有Prototyping的過程？或是怎麼在公司內部推行精實創業的方法？
事實上大家只看到了週期，而忽略了「迭代」，關鍵在Learn，也就是經驗的積累！有沒有把驗證的結果具體分析，去評估有沒有達到最初定義的那三個目標，適時放棄或是改變策略，作為下個版本的需求驅動。至於速度，從自己企業內部的資源現況，去定義最適合自己的節奏就行，只是速度越快，越快能確定是不是做白工，這是一種成本意識！
產品開發完 Beta 上線或是概率發佈，就是在Prototyping，至於透過Flinto、AE或是Pixate等工具產出的UI Prototype，只有兩個目的，一是用來做使用性（Usability）評估；二是作為和PM、RD溝通的材料（Mockup），討論落地的效果是否符合預期，包括協助定義UI-Spec。
事在人為。我相信被充份授權或是你的崗位本來就是Stakeholder，推動的成功機會會大很多；如果不是，就試圖影響別人，畢竟做好用戶体驗不是一個人的事，而是大家的事，哪怕你是PM、RD或QA ！
從硬體廠到網路行業的轉換，自己感受到兩個產業思維方式與做事方法的巨大落差，靠譜的驗證與積累是我過去在硬體廠感受到最缺乏的，當然商業模式也是，不過那又是另一個故事了。
我是Ivan，歡迎關注我的LinkedIN及Medium，不定期會分享更多的行業觀點、UX與UI設計知識。
本文授權來源：Ivan Wei
