Awwwards. F2E東京見聞錄 — 精華開箱 (中)
對…是（中）…😅
承接（上）篇，從 David Navarro 的 Order/Chaos，到 Keitaro Suzuki 的 Universality/Soul，以及 Vitaly Friedman 的 Personality。
對我來說，Peter Smart 的分享替整個脈絡鋪上了從理想邁向現實的有效台階。
Peter Smart
Creating Magic — Products for Humans not Robots
創造魔法 — 為人，而非為機械而生的產品
Peter Smart 是一個滿盈正面情緒能量的講者，也是這次 Awwwards Conf 的主持人。兩天議程活動中當有意外發生，他都能向所有人分享他的正能量，引領所有會眾在活動中保持專注與熱情，是位十分厲害的激勵者。
而這樣的特質也與他分享的內容有所共鳴。
在這裏我同樣嘗試先破個題！
為何 MVP 「最後」會失敗
Minimum Viable Product (MVP)：最簡可行產品
就 Peter 的意思，即使 MVP 以 Sprint 的形式幫助你有效持續前進。
但！當團隊以這樣的模式啟動運作，所成型的產品，在一定時間後要試圖「逐漸（Sprint）」的成為足以傳達願景與魅力的產品。
可是，這個邁向願景的門檻，往往只會隨著離起步越遠，困難度也變得越來越高。
可以倚靠 Sprint 打造出了「可行」的產品，卻無法同樣以 Sprint 蛻變成「具有感染力」的產品。
對… 純粹這樣說很難懂…尤其是粗體那段的敘述，所以這整件事沒有那麼單純，我們還是從頭開始吧～！
螢幕將佔據了我們人生整整 21 年
這也就是為何 UX 如此重要，因為我們的一生將活在其中如此之久。
所以置身其中的這些 Experience/體驗， 也應當如同現實體驗的那般美好。而正如生命中令人著迷的魔幻時刻以及回憶，那些體驗都必定都與我們的人性有所連結。
But much of what is being produced today isn’t about us being user experience designers. It’s about us being user transaction designers
可是今日我們在做的比起說是使用者經驗的設計師，更像是使用者交易的設計師。
設計“交易”？ “交易”什麼？
交易“資訊”：
我們設計以最快的速度向使用者有效傳達資訊，然後以最快速度獲得反饋。但事實上，這就如同機械程式運行般的缺乏人性。
回到 Sprint + MVP
資訊交易建立在 MVP 模式上的時候，使用 Wireframe Framework 以組件復用形式來構成產品設計是一種十分常見的形式。
但以這樣直接性的資訊流的串接來說，這應當是 AI 擅長且準備取代人類的事情。
相對於此，作為設計師就理所當然應該在 UX 方面施展可以連結人性的「魔法」，讓魔法與人性中複雜的各種動機、情緒、理性…等特質有所共鳴，創造出有感的驚奇產品。
那從（上）篇中我們已經有足夠的眼界廣泛的理解人性要素為何，現在來看如何把這樣的目標導入專案，以及施展其效益。
Create Magic For People
Peter Smart 以他們替一間專門經營海上豪華郵輪的公司 Royal Caribbean 所做的 APP 為例，這個 APP 並不是郵輪的訂票系統，而是登板乘客的超級體驗幫手。
關於這個APP可以參照這個影片連節。
工程師mermer： By the way, It's created by Unity.從訂立體驗準則開始
Peter 訂出了三項體驗準則：
一. 情境為王：
以這個郵輪APP的使用情境來說，設計的核心是讓置身在高達24層的郵輪中，使用者可以從APP輕易掌握：
- 發生什麼事
- 你在哪
- 你可以做什麼
具體細節像是：
- 郵輪位置：行程、停靠狀態
- 戶外天氣：以決定是否要/可以進行夾板活動
- 船上活動：各類型娛樂活動資訊、餐廳資訊、預約規劃多日行程、同步夥伴行程
- 地圖：十多層的夾板地圖
- 即時服務：在船上各地可以隨叫隨到的餐飲服務
- …等
二. “如果給我們看到漢堡選單你就被開除了！”的態度：
雖然作為一個設計師這樣乍聽之下很嚇人，但也只有抱有這樣精神志向的夥伴，才有真正的渴望與意志共同創造「更好」的體驗，而非「常規可行」Framework 式的通用性體驗。
三. 以使用者的「決策」作為設計軸心：
以郵輪 APP 為例，他們訂出兩種使用者的主要決策情境：
- 使用者在家中：開始規劃船上的活動計畫，以及選擇要與哪個群體活動（配偶/小孩/朋友…）。
- 使用者在船上：或許因為小孩子去玩，於是自己有多餘的半小時，那這個當下有什麼活可以參與。
於是在這三個準則之下，找到了正確的夥伴＆目標後，就可以開始創造該業界最具衝擊性的體驗了！！
設計流程
由於要面對無盡的 User Stories 總是令人無比焦慮，於是我們還是從打造 Framework 作為開始。
在傳統上可能就以瀑布流先用 Wireframe 以「內容信息」面來設計拼湊整個流程，再破碎的以個別「畫面」去做視覺設計，到最後才對各種元件展開互動設計。
但這裡我們要作為最開始打造的 Framework 指的是以「具體體驗」為主體的 Framework，而非上面以「內容信息」面為作主體。
這是為了確保使用者的操作體驗，是作為「最開始的願景」被掌握著。
但？為何要以ＵＸ作為起點？
傳統瀑布流先確保功能有效才增進使用者體驗不是更務實合理嗎？
上面的邏輯固然合理，但我們先再繼續下去，答案呼之欲出～Prototype 是為了打造有效願景
當使用建構好的 UX Framework 開使製作 Prototype
Prototype的目標：
- 實際體驗 UX Framework 的成效。
- 以破碎性的來測試一切，讓眾人在具有「實質體驗」的狀況下溝通意見、凝聚令人興奮願景。
所以為何不應該從「內容信息」& Wireframe 作為 Prototype 的核心，是因為只有當使用者面對「有效體驗」的 Prototype，才能讓眾人利基在「有感」之上，以被有效體驗所勾動的情緒與想像，進一步共同追求足以凝聚彼此的「偉大願景」。
而非只是如同 Wireframe 的性質，將彼此溝通凝聚的「層次」僅停滯在「合理」上。
可是？為何不能先合理再邁向遠大的願景？在一開始就凝聚眾人真的那麼重要嗎？
關於這個問題我們就先暫且放一邊，後面會有解答～為何 Motion Design 不該放在最後，而該最早做
承接上面「有感引導願景」，於是 Motion Design 理所當然該作為起始設計工程的核心，以締結人性的「情緒」體驗，來引領使用者進入願景。
Performance driven design, Motion is your friend.
當然，除了引領情緒 Motion 也是超越各種溝通界限的存在。
於是在打造好能有效傳遞願景的 Prototype 之後！
展開測試 & 打造設計系統
以 Royal Caribbean 的 APP 來說，Peter 他們以啤酒兌換卷兌換得了該公司所有的船員進行了充滿熱情🍺的測試。
在這個過程中，設計師＆測試者＆開發者一起參與整個迭代以及重構，進而產出一個足以跨越地理角色限制，凝聚大團隊共識的 Design System 設計系統。
前面的確保「可匯聚願景」的特特性，就是在這個階段發揮作用。
但？ 具體來說「凝聚大團隊共識的設計系統」究竟可以帶來什麼？
我們先再繼續往下看～打造自然流動的體驗，而非畫面切換的體驗
回到 Motion 是我們追求 Performance 最好的夥伴，來創造體驗的自然流動性，並確保資訊內容能以最佳的形式傳達產品的願景。
Peter 以 Ramping 這個遊戲產業詞彙例舉 Motion 的重要。意指藉由動畫漸變的時間，來平緩式的掩蓋背後數據傳輸的等待感，甚至進一步提升使用者的體驗。
工程師mermer：
以我最近做的[個人網站](https://gore.wang/f2e/)為例，我是用 React 這個 JS lib 以組建化形式去跑出我的網站 HTML 內容。
所以一般情況在所有 JS 載入解析完成之前網站無法被繪製出來，也就加長了使用者的等待時間。
所我讓開頭的Ｇ字先以在網站上架前先行繪成 HTML（prerender by Gatsby.js），並且倚靠瀏覽器在初始繪製階段就可以第一時間運作動畫的 CSS & SVG SMIL 來實現動態的入場效果。
直到後面 JS 部分都解析執行完了，再以 JS 接手觸發一個 callback 計算確保誤差時間，然後用改以 JS 實現Ｇ字的動態出場，最後正式進入資料量互動複雜的主畫面。
這樣一個設計，或許掩蓋的只是一秒不到讀取時間，但我認為這一個順暢舒服的有趣過場可以讓整體的體驗提升許多。然後就可以再進一步
正因為有了足以凝聚大批所有人願景所構築起來的 Design System，讓他們可以不只對一艘船一條航線的去做產品擴張。
憑藉已確保體驗的設計系統，再去依每一條船的特色定位去做風格的調整，最後將服務擴張到整個 Royal Caribbean 全球所有 55 艘船上面。
又甚至是船上電視的系統。
如此龐大且複雜的服務，一切為都是以使用者體驗作為出發。
這讓我們再次回到開頭有聽沒有懂的破題。也準備回答「足以凝聚大團隊願景共識的設計系統」究竟解決了什麼？
結論：為何 MVP「最後」會失敗
因為開始沒有在有效體驗上，參與者無法達到有感的共鳴，進而無法提出有火花凝聚的構想與共識，理所當然參與者的熱情與付出的意願不可能來的更好。
到這裡或許你還是認為「能有效前進」最為重要。
但最關鍵的事實就是，你最後根本無法將上圖左邊 MVP 形式下所構成的「有效」產品，以 Sprint 的步調轉移到右方的願景性產品形式上。
如開頭所說，如果無法打從「一開始」就倚靠願景匯聚足夠的產品熱情，又怎麼可能在中途才將某種非出自願景的折衷產出，靠著「階段性 Sprint」突破各種沈積的歷史因素，以逆風之勢「羽化」成具有願景的產品？
The convention is just permission to do better, so invention over convention. If that wasn’t true we would not have jobs as designers today.
常規只是用來承諾把事做好，如果不倚靠創造超越常規，那又為何來設計師這項工作？
最後 Peter Smart 替設計作下總結：
- 所以在「一開始」就確立可以溝通傳達的 vision 願景是多麽重要。忘記 MVP，因為那是 MLP 在做的！
- 科技已足以讓我們超越限制，超越螢幕的想像。關注引領整個體驗的流程，並以混搭的形式來打造最貼近現實的自然互動，進而創造優雅愉悅的體驗。
- 設計讓更多人，能以最小的體驗門檻，在體驗上獲得更強大的價值延伸，甚至令自己感覺像超級英雄。（呼應 David Navarro，設計師的精神要像超級惡棍。Peter Smart 說設計師要讓使用者在能力上成為超級英雄😆）
- 灌注你的心/生命/靈魂 到你的設計，能另自己享受其中也就表示你是真正用到自己的經驗在說服自己。而且如果你可以令自己有感，也就可以打動他人。
精華開箱 (中) — 後記
我發現自己很難在文字上重現 Peter Smart 在現場所傳達的能量魅力，我只能將這連串充滿正面情緒的分享更邏輯化的與大家分享～
對我來說，（上）（中）這兩篇我超愛的講者們其分享的內容，在我視野面前聚合成了一條清晰明確的道路。
讓我釐清了對於設計不知作何拿捏的距離感，也看清自信了未來我置身其中所能帶來的可能性。
原本想將上篇所說其他講者的 Spotlight 合併寫在這篇，但就內容就是有種無法連貫的不協調感，索性之後再獨立寫一篇以分類形式的來分享。
回到這篇的主題，否定產品設計 MVP 這個思路真的是非常吸引我，尤其我自己完全就是願景驅動燃燒型的人。如果當產品只剩純粹的「合理」性，而沒有企圖傳達的具體願景時，我就會像無柴空燒般的感到不適。
所以說我在聽 Peter Smart 分享的時候聽到心跳加速完全不是誇飾，當時心頭甚至讓我有衝動想喊 “I am also want to create magic!”
尤其 Royal Caribbean 這個 APP 可以說是最貼近我核心動能的工具性產品，與我去年替 TEDxTaipei 做的當日活動網站各種情境功能方向一致，真的無比有感～！
沒跟 Peter Smart 聊到天是我本次活動最大的遺憾… 從第一天中午領完便當之後我就再也沒看到他出現在任何休息時間和 After Party 上…
說到這裡我不得不提一下，過去幾年的我為了在職涯上匹配「專業前端工程師」這種的定位，不斷的在聚合那種 roadmap 式的「專業能力」，於是在這樣的視野之下就不知覺將設計從自己的符號中逐漸分離出去。
以至於過去接近一年的時間，我一直試圖從廣義的「專業前端工程師」的角色跳出來重新定義自我。不過即使找到自我本質的核心了，卻在工作定位上老是有種違和感～
縱使我在會眾群像文章裡頭表示自己意識到面對設計的界線可以沒有侷限，但為了能夠有效幫助他人和與人合作，在角色的溝通上還是應該要有個可以被理解的符號。
前幾天一位 設計師朋友 Chelsea 聽了我的困擾之後就分享了一篇文章：
Google 的 UX Engineer（ 使用者經驗工程師 ）在做什麼？如何成為 UX Engineer？
這是在 Google 擔任 UX engineer 的 Mimin 所寫的文章，看完之後頓時有種三角定位完成，終於知道自己是誰了的感覺。
會扯到這邊，是因為體認到自己為何會如此被 Peter Smart 的分享所感動，就是因為我一直以來都是為了打造體驗，而過去我竟一直沒有把這件事看成是一回事。
當初讓我成為前端工程師的契機，就是想替自己的文字創作，去實現我心目中最理想直式翻頁閱讀的體驗。
一直以來，創造＆挑戰體驗才是驅動我成為工程師的主因。
過去我對 UX 只懷抱著一種純粹加值性的意義看法，但 Peter Smart 的分享讓我看見事實上由 UX 引領的願景所能帶來的影響。
我顯示者，我是 Eng-Lens UX Engineer，我現在知道我可以創造體驗與大家一起朝著願景前進。
筆者自介：
大家好，我是 Gore Wang ～
享受動畫敘事＆打造具沈浸式互動體驗的網站 F2E/UX Engineer。
尋找同好夥伴中，歡迎參觀我的個人網站以及加我好友～！
