此为历史版本和 IPFS 入口查阅区,回到作品页
imsyc
IPFS 指纹 这是什么

作品指纹

我在瑞典當產品設計師(4)老闆說我們要開發MVP!

imsyc
·
·
這是系列文的第四篇,我將介紹Minimum Viable Product 最小可行性商品(MVP)是什麼、實務中常見的問題以及不同種MVP及其優劣。

MVP的概念已經不是新鮮事了,且如果你曾在新創公司或是跑敏捷開發的公司工作的話,你應該多多少少也聽過人談論這個詞。用最簡單的話去形容他,就是:使用最少資源開發的可用產品。不過,如果我們只用這麼簡單的一句話來定義MVP,那也非常容易扭曲MVP的真諦而適得其反。

非常建議各位花個四分多鐘來看一下這個影片,講者是NN/g的資深副總Kara Pernice。在這部影片中她提到:

For some teams, MVP means mediocre design launched every few weeks. (對於有些團隊來說,最小可行性產品就是每幾週就會上線的平庸設計。)

這麼做的壞處就是讓你的早期用戶有較差的用戶體驗,進而要面對的就是高流失率並且更難喚回那些已流失的用戶。畢竟,如果三天兩頭就看到一個爛設計被推出,為什麼用戶會期待下一個版本會更好呢?

💡 NN/g是Nielsen Norman Group的縮寫,是一間致力於推廣UX或是UCD的顧問公司,由Don Norman(非常早期開始倡議UX的人,著有The design of everyday thing一書)和Jakob Nielsen創立。

敏捷團隊中最容易踩到的MVP陷阱

😣 將MVP視為各個功能的堆積

這個問題可以說是我最常遇到的且最不能理解的。身為設計師,我們會以用戶價值為出發,而非單一個功能。

以我而言,我通常以「How might we…」這個造句方法來框架我的設計任務。這個方法在設計思考的流程中很常見,主要是能夠將挑戰轉化成機會,以一個正面的角度來思考可能的問題。

舉個例子:

How might we help educators, parents, and students adapt to remote learning while also using this moment to radically reimagine what we need our education systems to be?
Source: OpenIDEO

這是一個很典型的HWM用法。我們透過建構一個句子來描述我們的目標用戶(educators, parents, and students)以及他們正面臨的挑戰(adapt to remote learning )以及目標(radically reimagine what we need our education systems to be)。也因此,我通常不會設定自己的設計任務為「視訊軟體-新介面設計-撥號畫面」。

但多數的組織習慣於將產品功能切割,並將只提供單一功能的產品試做該產品的MVP。舉個誇張的例子,就很像是早期Instagram用戶的初始功能只有「上傳照片」卻沒有任何地方可以「瀏覽照片」,僅因為這個在開發流程中被切割成兩個功能分開上線,其實是非常不合理的。

😫 為了趕上線,而精簡規劃好的設計

第二個容易發生的問題則接續著第一個問題。在不是特別注重UX或是視覺設計的公司,會認為UI漂不漂亮、產品好不好用,等上線後在搜集客戶反饋就好,現在花太多時間刻,如果用戶不喜歡不是白做了嗎?所以權衡之下決定將資源全數投入功能開發,而忽略用戶體驗的重要性。

我就經常在設計完後被詢問「開發能量不足,這個能不能稍微改一下?」當遇到這種狀況的時候說實話也是只能改啊,但是通常改動不會新增更多時間來讓設計師測試改版的易用性,也因此往往會就精簡原有的設計、或是使用已經存在的設計模組來「組裝」出一個新設計,然後設計師在自己記錄下這是個「Design debt 設計債」,之後有時間要來優化,而現實面就是開發功能的需求源源不斷,幾乎很少有時間能真正的來處理這些設計債。

😔 版本間的設計缺乏一致性

這個問題通常會在時間長或是公司規模大的狀態下出現。時間一長,可能團隊內的設計師已經換過一些人了,但由於每次的版本都是以小塊模組的方式設計、上線,而缺乏完整、全局的設計理念,在物換星移之後新人摸不著舊人的設計理念,或是根本版本控制不佳,一個返回按鈕可以有多種不同互動模式,這些狀況都是會有的。

而公司規模大,往往團隊區分細,彼此間的溝通就會變的更為重要。如果缺乏溝通、或是沒有完整的設計系統,那麼整個產品的一致性將會岌岌可危。並且由於「一致性」是屬於「整個產品」的問題,不會有任何一個團隊能負責優化一致性問題,往往需要各個團隊協同合作,在自己原有的專案時程上去協調可能的優化方案。

好的MVP長什麼樣子?

早期談論「好的MVP」時我們會使用Henrik Kniberg畫的這張圖來做解釋:第一層注重一次提供一個功能,但單一功能無法讓整個產品運作順暢,所以是一個很糟糕的MVP。而第二層在每個階段都能讓用戶使用,所以是個好的MVP。

Henrik Kniberg 來自瑞典,以身為Agile coach知名,並曾在Spotify、LEGO等知名企業服務過。

不過,隨著時代的演進,慢慢有人提出不同的看法。像是上圖的MVP的不足之處即是:如果我今天要解決的問題是「我想從台北去高雄」,那滑板、滑板車就顯得有點不合時宜,或許應該改成一張火車票。

Jussi Pasanen 綜合了 Aarron Walter 的「情感設計」並提出了下面這個金字塔,將情感設計放入金字塔的頂端,並強調在開發產品的同時,不應僅單單的提供功能(如左側的金字塔),功能開發完了才往下個層次前進,而應該像右側的金字塔一樣,在每次的版本中都能提供用戶穩定、好用、有價值的產品。

不過由於情感設計是一個非常複雜也廣泛的概念,我個人更喜歡下面這個插畫,僅簡單的將金字塔分為「價值」與「功能」。

Credit to Lassi A Liikkanen

價值是個可以因為產品定位、公司品牌而有所不同的,像這篇論文《Beyond Maslow’s Pyramid: Introducing a Typology of Thirteen Fundamental Needs for Human-Centered Design》裡所歸納的13種基礎需求和對應的52個子需求,單一個產品不可能涵蓋這些所有的需求,而是應該釐清,你的產品主要是要滿足何種用戶需求?帶給用戶什麼價值?

而在每一個MVP版本中,重要的都不是把某個功能趕上線,而是能在每個更新中持續不斷的提供用戶價值,維持最佳的用戶體驗。

結語

在文章的最後,我希望各位讀者能思考一下兩個問題。第一,你個公司產品真的適合使用MVP來進行產品開發嗎?第二,重新定義對你的團隊而言,什麼是最適合的MVP?

很多時候我納悶,敏捷開發、精實創業(Lean startup)明明重視的是方法背後的價值觀,但卻因為方法太簡單的而經常讓人忽略背後重要的是什麼。MVP的重點是當你資源短缺時,要如何用既有的資源去開發一個可以滿足用戶需求的產品,小時候當我想要送媽媽一份母親節禮物的時候如果沒有錢我就會自己做「打掃券」,因為要達成的目標是「讓媽媽開心,多點休息時間」,從來不是「買給媽媽一台吸塵器,但是因為現在預算不足所以我先買掃把」。

也因此我認為,無論看這篇文章的你是產品設計師還是PM,或是一腔熱血想導入敏捷開法、利用MVP的決策者們,都想想你們要解決的用戶需求是什麼?這樣子的需求適合用MVP嗎?怎麼用呢?

歡迎大家在留言區討論,你所負責的MVP長什麼樣呢?

下一篇,我會介紹如何使用「設計衝刺(Design sprint)」來確保一個MVP能在快速開發的同時提供價值、具備良好的用戶體驗。

感謝你閱讀至此!喜歡我的文章的話請幫我拍手👏和分享📣!有任何合作邀約或是單純想交流出國做設計的心得,也歡迎到我的LinkedIn、臉書或IG找我。
Stella Hsiao | LinkedIn / 
@imsyc | Instagram / Stella Hsiao | FaceBook
CC BY-NC-ND 2.0 授权