以下的文字，由筆者湯六 (Tom Liou) 參與 2017 TalkUX 論壇，自行錄音並繕打而成的逐字稿，且該文章經由 ProtoPie 同意授權發布。由於當天現場我的手機拿去錄音，沒有多餘的設備可拍照，所以文章中的 slide 圖片由該場講者「韓學穎」授權提供，特此感謝之。
該講座為 TalkUX 第一天的其中一場講座，講者為 ProtoPie 市場部人員「韓學穎」，她所分享的題目是「從 Lean UX 到 Microinteraction」(以下開始為逐字稿正文)。
大家好，我的公司在韓國，產品是一款名為「ProtoPie」的高擬真原型工具。這款工具是由設計師與開發人員，一共 9 個人來完成的，而這 9 個人可以保證產品以「25」天為一個週期進行迭代更新。我們的用戶會跟我們說「你們怎麼做到這麼少的一個團隊，還能以這麼快的一個速度去做更新，是不是你們的開發人員都特別的猛啊？」然後我想了想就回答他說「是的，我們的開發人員真的特別的猛！」，但我認為除了個人能力之外，就是我們團隊整體的工作流程的確帶給我們很大的幫助。
我們工作的流程方式就是今天帶給大家介紹的「LeanUX」，這個單詞大家肯定不陌生，它是由「Think」、「Make」、「Check」三者為一個的開發循環流程。
-
- 「Think」階段會討論一個產品要添加哪些功能，哪些東西需要去優化。
- 「Make」階段會去討論如何去設計與改良一個產品。
- 「Check」階段會在產品上線之後讓用戶去討論，哪些改動是否好與壞。
如此三步驟一個快速循環的過程，就叫做 Lean 的過程。而 LeanUX 指的就是我三者在執行的時候，永遠都以「用戶為核心去思考」。
所以 LeanUX 用一句話來形容就是「以用戶體驗為中心，然後執行 Think、Make、Check 三者快速循環的一個流程。」
圖 3 是 ProtoPie 工作時的流程，我們在工作時完全按照時間表在跑。你可以看到 3.4 版本四個星期開發上線、收集用戶反饋。但是在 3.4 版本的尾段進入到ＱＡ測試時期，我們就會進行下一個版本的企劃，所以整體的過程就非常的快。
有的人就會問我到底瀑布式流程開發與 Lean 有什麼區別，因為瀑布流裡面也有你說的這三點啊？
我們看一下簡報，以瀑布式流程為例，這個紅點是開發者認為預估的市場需求，然後我就會去想，這個產品裡面我要加什麼功能、然後去做設計跟開發。當一個產品裡面可能有十多個功能要去逐步的開發完成，然後再一次性的發佈。我們就會面臨到開發時間過長的問題。有時會六個月、有時會要一年，若我發現一年之後萬一用戶的需求變了，從紅點移動到綠點上，我們此時再去修正產品，團隊的資源便會浪費掉很多很多。
但如果大家是用 Lean UX 的話，在面對10多個功能的時候，我只要先開發一個。等上線之後迅速得到用戶的反饋，發現用戶需求好像有些變化，我再去調整我的方向，接著立馬去開發下一個功能。在如此反覆的修改中，就可保證我離市場的需求，亦或是用戶的需求是更近的。
所以綜合上面兩點，LeanUX 的優點就是用戶的需求可以準確的把握，另一個則是可以讓開發流程的速度快起來。
那麼問題來了，我們要如何又快又準確地滿足我們用戶的需求呢？
第一點：要加快我們的設計流程，所以我們就必須問自己，「為什麼我們的設計流程會這麼的慢？」其中的問題就是，我們很容易把一個大的專案一起開發，然後開發完才上線。而在 Google 內部，他們有一個做專案的方式叫做「One Bite」。
「One Bite」就是指將一塊大蛋糕切成許多塊小蛋糕，而大小剛好符合你吃下去一口的大小。因此 Google 把一大產品分成一口一口的方式去切碎它，並依照開發的流程去做。
舉一個例子，Google 有一個圖片搜索的介面，信息非常的冗長，排列起來看著很亂。改版的時，它們共進行三個要點的改版，而這三個要點的改版只花了一個月的時間。而且是三點分批次上線，而非傳統認知的一次性上線。
這樣的好處是 Google 是一個大企業，一次改版很多用戶接受起來會比較困難，另一個好處則是假如我們一點一點去做的話，會讓開發人員去決定該產品的開發版本的重點項目與優先次序，並在不同時間點中收集到用戶反饋，甚至影響到後續整體產品的改良。
此外還有一個方法可以讓開發流程快起來的方式就是做「原型」。以前若想要測試設計想法是否行的通，或是合不合體驗的時候，我必須要等套上代碼，等到產品開發完之後再拿到用戶面前去做測試，去問用戶用起來的感覺如何。
但是透過原型製作工具，則可以透過不套上代碼的方法，由設計師自己設計原型並給用戶去做測試，去問自己設計成果的使用性與問題點。故原型的製作與測試可以加快整體開發的節奏與速率。
在準確了解用戶需求方面。首先第一個就是看數據、我們在講用戶需求一般來說有兩個方式，一種是「定性」，另一種是「定量」。而我們公司會通過一個免費的數據工具如 Google Analytics，去洞察用戶的需求。之前 ProtoPie 的官網上新加了一個 Feature Page。添加後我們沒有馬上又添加新的介面，去看了一下數據。發現他的流失率居然有超過25%。但我們認為這個頁面不應該是流失的的一面。
因此我們設計師就去找到為何流失率高的問題在哪裡，後來我們發現在 Feature Page 裡面沒有一個通道，讓你到達 Download Page。之後的改版中設計師便想要在頁面旁加一個按鈕在旁邊讓用戶看到。
我們之後就設計出了三種方案，去看按鈕加入在哪邊比較好，並做了A/B Test 最後藉由著數據選出了一個比較好的設計方案。所以數據除了可以幫我們找到問題之外，也可以通過數據來告訴我們用戶的行為是什麼？
但提醒大家一下，因為我們公司比較小，用戶群體還不是比較多，如果大家工作的公司跟我們公司狀況一樣，數據沒有累積到一定程度時，數據就不見得有意義。我後來做了一個測試，把所有數據丟入一個網址所得出的結論就是「我們之前收集的數據是沒有意義的」。
但因為用戶的「基數」太小了，雖然大家看到他的點擊率有3.39多、2.81多。但這些數字對我們來說是沒有意義的，故我們只能加長我們的測試時間，讓數據的基數變更大才會得到更準確的答案。
說到定性，一般而言就是讓設計師帶著原型去採訪我們的用戶。我必須提到另外一個方式也是 Google 所提倡的。叫做「Cafe Study」的採訪形式。我沒有去過 Google 總部，但我聽說 Google 的餐廳特別好吃，且會有很多外部的人到他們餐廳吃飯。這時設計師們會在中午時拿個原型找人幫忙測試一下原型，採訪的過程大約是六到十五分鐘。大概只要花一個中午的時間，當採訪人數達到六至八個人的時候，就可以把數據全部收集完畢，且設計師可以馬上得到用戶的反饋訊息。
所以在 Lean UX 的原理中，「快」與「準確」的兩個要素中都有一個共通點就是「原型」，故此原型的地位是相當重要的。
(講者在這邊請大家舉手，第一題是「有沒有做過原型？」，第二題是「有沒有做過互動原型？」。筆者觀察現場舉手有做過原型的人很多，但能做到互動原型的人卻很少）
第一個問題「有沒有做過原型？」，我發現現場還是有很多人沒有舉手，我問了很多設計師為什麼會發生這樣的狀況，他們都回答我「因為沒有時間」。
我們看一下投影片這個是企業一整個的開發流程分工。前面從產品經理到 UX 設計師，其中經過了產品定位、使用場景規劃、線框圖這些步驟。到最後留給 UI 設計師做原型的時間其實是沒有的，這樣的流程是許多大企業做設計的方式。
題外話，最近有一種流行的方式，就是從開功能需求，線框稿規劃、版面空間配置、原型製作甚至到與工程師去溝通代碼，都由設計師一手包辦。我們管這種形態的設計師叫做 Fullstack Designer (全端設計師)。而在我們公司會怎麼做呢？我們公司也才一名產品設計師，為了提升專案的執行速度。他是不做 wireframe 的，因為他認為這只是為了工作而工作的一個環節。取消了這個環節之後，他的工作時間多出了22%，這樣就可以把多餘的時間直接拿來做原型與測試，這是我推薦大家的一個工作流程改良方案。
第二個問題「我問了有沒有做過互動原型？」大家除了沒時間做之外，另外一個癥結點就是設計師「不會做」。如圖12的案例，設計師在做原型時通常會畫很多圖，然後跑到開發人員跟他說「當我點擊這個按鈕時，會繃的一聲彈跳出來一個東西」。這樣子的溝通方式常常讓工程人員一頭霧水。
尤其是跨國團隊，每個國家擬聲詞都不一樣，故用口語溝通根本達不到溝通的目的。雖然在我看來，我不知道這樣的動效設計與擬聲詞有什麼區別。但我相信開發人員心裡也會跟我一樣困惑的反應。故假如你是設計人員，有動效設計的需求，但你又不會用語言器描述的時，溝通上自然就會很多的障礙。
那我們要如何做這一個互動原型？不知道大家有沒有看過一本書叫做「Design Sprint (設計敏捷方法)」這是一個從 Google Partner 出來的設計師所寫的。他裡面有一句話就說「不要讓你的用戶去想像」。這句話是什麼意思？我舉一個我朋友公司的例子，他自己做了一個專案也做了一個是可以動的原型。他就拿了這個原型去問用戶說「你點擊這個按鈕呢，他會有一個翻頁的動效，但其實我做的不是點擊，我們要做出來的樣子是往左滑，可是我們做不出來，請你想像你再點按鈕的時候腦海裡有這個動作。然後你再告訴我這個轉場如何？」
朋友用這樣的問句去問他的受測者得到的答案都是「很好啊很好啊」，這個項目可惜的是後來就失敗了。我會舉這個例子是當你讓受測者去想像自己用的時候，可能他自己都不知道自己的狀況是什麼？而更多的是受測者說出了一個不符合他內心真實狀況的東西，這就代表他說的是假話，而你得到的結論也是假的結論。
雖然我們常常在說，要把你的互動原型做的逼真一點，要更像真實產品的樣子，除此之外還有五個做原型的原則。
- 第一點、「一次性」：原型只是一種溝通的工具，不要想說去把原型不停地迭代更新。
- 第二點、「一個原形解決一個問題」：如果你只想了解的是用戶在輸入密碼的過程中，體驗是否好。那就做輸入密碼的原型，而不要做整個Log in的過程，這樣測出來的結果反而會失去焦點。
- 第三點、「多做」：做原型的頻率要高
- 第四點、「90%高保真」:在這邊的高擬真並非指的是百分之百和你的產品像。有統計數據顯示，在擬真度0％到90％的過程中，受試者會心中意識到這個原型是真假的曲線值會逐漸降低。可是當原型擬真度到達90％以上的時候，用戶對於原型的感覺是沒有分別的。雖然追求極高擬真，對於測試很重要，但對於設計師來說在追求90％到100％的擬會更花費大量的時間，這樣反而失去了我們做原型的意義。
- 第五點、「互動體驗」：原型一定要考慮的是「互動體驗」不只是靜態的、純視覺的，你更必須要考慮到動態的行進方式。
以上我提的五點裡面前三點，大家記在心裡就好。第四、五點如何作「高保真原型」、「如何去增加互動體驗？」這裡就要提到 Microinteractions (微互動) 的概念。
我們認為任何一個「交互動作」＝「觸發動作」加上「對象」加上「反應動作」而組合而成的。
或許光這樣子講，你可能還有點不太懂。圖15是我在網路上找到的一個叫「ViggoZ」的設計師所編寫的動效互動文檔。仔細看後也發現這位設計師編寫文檔的邏輯同樣是依照「觸發條件」、「對象」、「反應動作」逐步編寫。所以當你用這三個條件去思考互動特效時，對於設計師與開發人員之間的溝通效率也會大大的提升。
圖16是我們做的一份表格適用於手機端，分別有「觸發方式」、「反應動作」兩大單元等。這張圖就如同大家小時候學的元素週期表一樣，我們覺得世界萬物很多都是由有限的一百多個元素所組合而成的。交互的動效也是由有限的觸發方式與反應方式拼接而成。雖然剛剛很流於表面的講了UX 到 Microinteractions，但這到底要用什麼工具來完成？
我身為 TalkUX 贊助商是需要打一下廣告的，目前公司所開發的產品叫「ProtoPie」，意思是指要設計師做原型像是吃派一樣簡單。我們發現在當代介面的互動方式不再只是限於手指與屏幕了。故此 ProtoPie 產品最大的特色為設備與設備之間的交互，如演示跨設備的支付行為、車聯網載具行為或是用手機去遙控電視等不同的項目。更重要的是設計師完全不需要編寫任何代碼就可以輕鬆的完成有關於跨設備以及跨平台的的互動。
以下為 ProtoPie 實做的案例影片
01. NFC付款原型
02. 設備交互動效示範
03. 不同平台間的原型範例 (with Arduino)
以下為 ProtoPie 產品於網路中的社團與相關資源，如有需要下載試用版本的人，或是在使用上有任何疑惑的人都可以到 ProtoPie 的官網或社團發問尋求解答。
原文轉載於 – ProtoPie – 從 Lean UX 到 Microinteraction
Tom Liou
本文章所屬設計大舌頭與作者所有，未經授權，不得轉載！如需轉載，煩請通知。
