無法靠經驗回答的問題,那就看數據吧!

0

文/Ivan Wei

在進入網路業前近七年的時間,我都在消費性電子品牌廠,公司主要的產品都是以硬體裝置為主,手機、平板、車用、錄影盒(Video capture device)等,曾遇過一個實際案例:當時在開發一個遊戲錄影盒,這個裝置能接到 Consol 或是 PC 透過軟體錄影,而裝置正上方有一個巨大的實體錄影按鍵,總經理問設計團隊,這個按鍵的機構件,其耐用性應該達到多少次點擊?

Ivan_20160709_1Materials from Business vector designed by Freepik

無法靠經驗回答的問題

因為機構件涉及到材料成本(Bom Cost),耐用性高的零件、採購成本貴;耐用性低的,又擔心保固期內就壞了,反而多了客訴與新料件的成本。偏偏公司靠的就是銷售價格與成本的價差賺取利潤,當時能做的只有透過用戶訪談、實地觀察用戶,或是業務反饋、通路商的建議,再加上客訴能得到的資訊,幫助我們理解用戶使用產品的狀況。但被問到耐用性的問題時,當時除了答不出來,更不知道該用什麼方法去找出這個答案。而從這個案例看來,有幾個洞見(Insight)值得深思:

  1. 如果當時可以透過少量測試的方式,找到核心的用戶或是粉絲;或是第一批出貨,加上硬體按鍵點擊的數據埋點,得知樣本用戶每天的使用頻率,這個問題似乎就可以得到答案,並且協助零件的採購決策,在第二批挑選一個在保固期內無虞的機構件。
  2. 透過這些數據的蒐集,甚至能知道用戶是不是非常依賴這個硬體鍵的設計,還是大多用軟體去驅動錄影的功能,這對之後產品的改版是很有幫助的情報。
  3. 從軟體的數據埋點,也可以知道用戶大多是用來錄 Console 還是 PC Game,這還有助於商業拓展 (Business Development)與行銷(Marketing)。

這個案例的核心問題在於,過去我們並沒有軟體的Domain Knowhow去蒐集用戶用行為數據,而這在網路行業卻是一個習以為常的工作!


數據的價值

Ivan_20160709_2Material from https://pbs.twimg.com/media/BxPnJo-IYAA2xT9.jpg:large

上面的圖片,說明了用戶體驗和設計初衷的巨大落差。設計的概念模型(#ConceptualModel)是基於一個發展邏輯去組織的,大多是工程化的,就像我們的產品;而用戶的心智模型(#MentalModel)只在他自己關注的那一部份去探索,找到他自己的解決方案。再仔細觀察,如果沒有那一片草地,留下了用戶的足跡,我們也無法觀察到用戶的行為模式是如何,這就是數據的價值!再對照一開始案例的洞見,數據能幫助我們驗證用戶的操作行為、協助企業的商業拓展與決策。


驗證的重要

關於「驗證」這件事,如果你讀過精實創業(#LeanStartup),一定明白它是整體的核心思維,中國互聯網一句琅琅上口的話,把這個概念詮釋的很好。

小步快跑,快速迭代 - 用最小的成本去試錯、用最快的速度去驗證假說(Assumption),進而達到目標。

關於這個方法論,小可應用在產品上,大則可應用在組建一個新團隊或是一個新的業務線上。實際在開發CM Security這款產品時,光是2014年就迭代了超過100次,我們用了這個方法驗證了許多假說,有些失敗、有些成功,一年內達到了超過1億下載,從AARRR指標的各項數據結果看來,達到了非常好的的成果,而這個方法的執行的過程,完全可以用精實創業模型(#LeanStartupModel)來剖析。

Ivan_20160709_3Material from THE LEAN STARTUPMETHODOLOGY

不管是新功能、或是新的產品,從需求的提出(IDEAS),當中包含產品目標、需求場景的假說,透過單週迭代的節奏(BUILD)進行設計、開發、測試,完成後直接把產品上線(CODE)進行概率發佈,讓用戶使用我們的產品(MEASURE),同時也觀察產品的崩潰率,並且實時觀察用戶行為數據(DATA),確認是否有達到預期的數據目標,進而驗證需求的假說是否成立(LEARN),不如預期的再調整方案,或是放棄實驗;而確定滿足商業目標的場景,則再進行深挖,作為下個版本的需求提出。這正是一個小步快跑的過程,單週則是迭代的週期。每次的版本發布一旦發現AARRR指標裡的留存率(Retention)出現下滑的跡象,我們就會快速地調整方案,哪怕是一天一版本的迭代。

應用在新的專案項目上,又是如何呢?事實上多如萬人以上的企業阿里巴巴內部,充斥著許多的微型創業團隊運用著精實創業的方法。這些團隊就是一支支的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,歡迎關注我的LinkedINMedium,不定期會分享更多的行業觀點、UX與UI設計知識。

本文授權來源:Ivan Wei

Share.

About Author

Ivan Wei

在移動互聯網與消費性電子行業,從事用戶体驗設計多年,具有軟體與硬體產品設計的豐富經驗;曾得過 iF 與 Red Dot Design Award 以及參與多項創新概念設計,目前在雪豹科技負責用戶量破億的 Android App “CM Security” 介面設計。

Leave A Reply