本文是 Carolyn Chung 參與 HP65 – User Friendly 2014 心得分享會,於會後整理 Code Chin 當日分享內容的筆記。
第三場講者:Code(金韋宏),目前就職於大予創意設計,擔任 UXR 及 URI。
Code 分享的是關於精實設計(Lean UX),分享這次在User Friendly 2014的心得,Code 參加的是第三天上午的 Workshop,這場 Workshop 的分享人是騰訊的總監,周陟先生,跟大家分享精益體驗思維跟產品創新,因此另一個分享的大主軸是 Lean UX,周陟提到了這個概念是他們公司內部經過一些時間所消化出來,是屬於騰訊專屬的 Lean UX。Code 在聽過整個 Workshop 之後,再依據自己所涉略的一些東西,提煉出今天分享的內容。
生態環境一直在變,而且很快。
常聽到「天下武功,唯快不破。」大家總是求快,想站在對手的前頭,但是這是一個過時的心態。前陣子也因逢選舉時季,Code 也耳聞某候選人講到一段話:「未來的世界不是大打小;不是強打弱;而是快的打慢的。」這個快,是指開發的快?上市的快?應該都不是,快的應該要是體現在「選擇」上。設計的困難不在於發想,而在於選擇:兩個 Proposal 到底哪一個好,這時應該要趕快決定好,趕快做,趕快上市,這才是快的真諦。所以 Lean UX 作為一個方法,能為這些傳統開發時,在選擇上的困境做一些解決。
甚麼問題? 傳統開發流程的不流暢。
台灣從早期的 OEM 時代到現在的 ODM 時代,我們應該要求快,傳統流程的 SOP 從找需求方向(Scope)、設計定義(Specification)、開發生產(Production),最後才會進入市場(Marketing),這樣的連串的流程,將時間拉得很長,設計完還要等待 RD 的確認,可能還會遇到產品已經生產完成才發現方向不對,或者無法真正打動到真實用戶需求。「老闆跟客戶可能會等你,但是你的對手不會等你。」Code 在無錫聽到了快在產品開發上,非常有可能會遇到 B 牌比 A 牌晚一個月得到產品概念,卻比 A 牌早上市一個月的窘境,從用戶端來看,他們只會了解這個品牌是 B 牌上市的,這就是慢的風險。因此,雖然從老闆的角度思考,傳統流程對於管理來說相對方便,且分工清楚,但還是避免不了風險較高,過度的浪費資源的問題。
LEAN UX 的起源
Lean UX 起源於 Eric Ries 出版的《The Lean Startup》,其主要精神大致分為五點:跨部門合作、分享觀念相互學習、避免不必要的設計文件、以有效的使用測試來確認方向以及更精實更有效率。
- 跨部門合作
在 Workshop 提到了從設計到生產,都希望維持是團隊合作的形式,團隊成員各有所長且各司其職,有管理端、設計端、開發端及行銷端等。Amazon 創辦人 Jeff Bezos 曾經提出一個「兩片披薩規則」,他認為,團隊的人數要保持在兩片披薩以內可以餵飽一餐的人數,避免人數太多的時候,會降低「獨立思考」的機會。這說明了獨立思考才是團隊的真正價值。 - 分享觀念及互相學習
在團隊氛圍中,每個人的角色各異,各有不同的專業思維,整合出一個完整的產品概念要靠團隊成員以共創的方式來發展概念,同時也了解限制所在。例如行銷端在產品開發階段就可以利用他的行銷專業給出目前開發的可行性,提供給設計開發者調整方向,因此,團隊會逐漸的培養出默契,也會減少對可行性的差異認知。 - 避免不必要的設計文件
我們現有的設計文件都力求精美清楚,讓 RD 可以有依可循,想要減少多餘的溝通心力,但在過程中消耗掉太多的時間,在技術面無法達成時,精美的設計文件又會被退回來做修改,就在一返一覆之間,犧牲了時間資源。另外,此次 Code 在對岸聽到了一個「低保真、高效能」的概念。對岸求快的腳步顯現在某些例子上十分的極端,他們會把概念畫在白板上,直接在白板上修改,而團隊裡的 RD 或行銷僅利用手機拍下共創的概念,就可以開始動工了。這是一個有趣的概念,也許不是每種型態的公司都試用,但是概念要被界定到多清楚的程度是值得思考的。
另外一個避免不必要設計文件的方法是:「逆向工程的練習」。這個練習是要我們從生活中所接觸的 App 或任何界面設計,都記錄下來,每天都將自己覺得有趣的界面徹底的使用一遍,用完之後再利用手繪紀錄出來,這就是逆向工程的方式,這樣展現了快速呈現的要義,且達到了前述所提的「低保真、高效能」,每天都一是一種練習。
Lean UX 的實踐觀念
- 概念假設(Assumptions)
概念假設不是一次到位,而是尋求逐步確認的方向,因而一次次的討論都會因不同成員看待事物不同的觀念而逼近群體一致認同的概念方向,更重要的是,這樣的方向不是死的,是可以依據討論的脈絡去時時微調的。 - 製作最小可行性的概念模型(MVP)
在概念模型的呈現方式上,大家熟悉的紙模、互動式 HTML、可點擊 PDF、Keynote、PPT,甚至是手機 App 的輔助,例如:POP。這些工具都有助於用戶更接近設計情境。在這些設計上要遵守一些原則,完整度剛好就好、以製作重點功能或單一功能為優先、重要的情境要想辦法模擬。舉例了車用的導航系統,開車真實感覺的模擬必須要被建立,要營造真實的感受。 - 實用性測試(Experiment)
在進入測試時,要了解測試的目的是驗證最初的假設以及找出思考的盲點,以供修正及微調。當產品進入開發階段時,也可以再次確認技術可行性,是否要找更多資源。也提到了一個有趣的「假門測試」,這是指當設計開發時,不確定某一個功能或需求是否客戶買單,因此會特意埋一個沒有真實功能的 Button 或 Link,去了解有多少用戶去點擊它。這個概念的邏輯時:「有人點擊,就有被需要的可能。只要 30% 以上的用戶點擊了這個假門,那這個功能就有被開發的價值。」
Lean&Agile
談到兩者差別,和 Agile 相比,Lean UX 的核心精神還是有所不同的。Lean 關注的是:我們是否做對的事;而 Agile 關心的是:我們如何做好一件事。
Lean UX 利用快思快做來確認概念,核心價值在於建立概念後趕快做測試,了解概念的需求是否被用戶真切的需要;而 Agile 會在開發之後才得到 Feedback,是一個迴圈發展的概念。在思考這兩者是不是有機會整合為一,講者認為是有可能的。總結,Lean UX 就是,「以最小的工,成就最大的效果。」
UF 2014參加心得
Code 最後跟大家分享去無錫的心得,提到課程雖然很多,但交流成分也十分地高,認識很多對岸和台灣的同業們,建議如果有機會過去,建議可以準備一個快速的自我介紹,讓大家有深入認識你的興趣,才有更多交流的機會。此次的交流也感覺到對岸的同業都能言善道,想法也非常快,也可以準備 2-3 個問題,增加溝通。