以遊戲化推動公司文化轉型 （下）一 遊戲化設計畫布工具簡介
本文轉載自作者於2020年首次發表在Medium平台的文章。
本文轉載自作者於2020年首次發表在Medium平台的文章。
========================================
透過「遊戲化設計畫布」 (Gamification Design Canvas) 可以有系統地改善遊戲化設計
我在2020年二月底加入了趨勢科技為了推動 DevOps 文化轉型活動而成立的跨部門工作小組 — STOC (Stand Tall On the Cloud) 。經過一個多月整合各方領袖的意見後，設計了「星際奇航 2020 計畫（Star Trek 2020）」的遊戲化競賽活動（以下簡稱「星際奇航計畫」），並於四月底開放公司同仁組隊報名參加。
原本就連工作小組中的許多人都不太看好這個活動，他們認為 —「有誰會想參加這種『以遊戲來包裝』，但實質上根本沒有遊戲可玩的比賽活動呢！？」沒想到，原本被認為需要透過主管動員以湊到 30 隊來參加的活動，在開放報名後竟有 93 隊合計共949 人報名參加，報名隊伍數足足是原本預期目標的 310%！
為了因應這遠遠超出預期的參加人數，工作小組還特別請了人力資源部幫忙徵集更多人手加入 STOC 來支援活動。而我們也找了前端工程師另外撰寫網頁程式，以支援活動細節的公布並期減少參賽者提交資料與裁判評分過程中可能出現的人為錯誤。後來，甚至還提前關閉了報名登記的網頁，以免有更多隊伍報名參加活動！
這個轉折讓很多原本看壞將專案遊戲化的工作小組成員跌破眼鏡，也因此有些人反而在之後產生了更多的興趣與動力來支援這個活動。畢竟，能參與辦理有這麼多人報名的文化轉型比賽活動本身就是一個難得的經驗，更不要說專案裡面還計畫用上「遊戲化」這樣的新鮮概念來設計活動。
近幾年遊戲化的概念在台灣蔚為風潮，除了很多桌遊老師與部落客大力推廣以桌遊為主的課程外，遊戲化大師周郁凱的著作 ──《遊戲化實戰全書》－發行中文版後，更是吸引了許多產品經理及使用者經驗設計師爭相撰文，分享他們以書中提到的「八角框架」（Octalysis）理論分析熱門遊戲的心得與看法。
筆者與遊戲化大師周郁凱（圖左）與於 2019年的合影
不過，在這個專案中，我發現多數人對遊戲化的認知普遍仍停留在「將枯燥的活動以有趣的遊戲『包裝』」的層次上，而我自己也缺乏一個完整檢視遊戲化專案的工具，於是便將這次專案的經驗整理、歸納，並運用常見的「畫布」（Canvas）文件範本形式設計了一個「遊戲化設計畫布」（Gamification Design Canvas）的工具，用來幫助自己在未來的遊戲化專案中找出設計時的盲點，並與利害關係人快速、有效地溝通。
我將應用這個畫布工具的方法簡單分享如下，希望能夠對計畫應用遊戲化方法的朋友有一些啟發。
這個遊戲化設計畫布共分為七個區塊：
一、商業目標（Business Objectives）── 進行遊戲化所欲達成的目標及用來衡量目標達成程度的指標。
設計師要反覆地提醒自己：「遊戲化只是達成目標的一種手段」，如果忽略了商業目標而以「好玩」或讓「玩家更投入」進行遊戲化設計，很可能會設計出或許有趣、吸引人，但耗用了專案時間跟資源卻對達成商業目標沒有幫助的遊戲化機制。這是為什麼我將「商業目標」擺在畫布中的第一個欄位且以較大版面呈現的原因。
訂出商業目標後，最好還能依此訂出衡量成功與否的「關鍵指標」。不過關鍵指標可以在對商業目標有更具體的瞭解後再訂定，不一定要在專案一開始時就於畫布中註明。
以「星際奇航計畫」來說，商業目標就是：「讓公司同仁能將 DevOps 的價值與方法實踐於日常工作中」。
二、目標使用者（Target Users）── 遊戲化機制的目標使用者（或玩家），也就是為了達成商業目標而必須影響其行為模式的目標對象。
一般簡單的遊戲化專案中，目標使用者可能僅有一組特定對象；但在複雜的遊戲化專案中，目標對象有可能是多個屬性不盡相同的群體。
以「星際奇航計畫」來說，主要的目標使用者是公司裡各產品的開發團隊，但其中還分為「已有導入 DevOps 經驗的團隊」與「尚未導入 DevOps 的團隊」。
三、期待行動（Desired Actions）── 希望透過遊戲化激勵目標對象採取的具體行動或行為。
以「星際奇航計畫」來說，我們希望已導入 DevOps 的團隊盡可能地「分享 DevOps 工程實踐案例」，也希望尚未導入 DevOps 的團隊能「瞭解實踐 DevOps 方法的各種可能」並進一步「實際導入 DevOps 思維與工程案例於日常工作中」。
以上三個區塊是畫布中的「定義階段」（Define Stage），三者可以構成一個迴圈，用來幫助設計師及利害關係人快速釐清並瞭解遊戲化專案想要解決的問題。迴圈由定義「商業目標」開始，其次確認「目標使用者」，並在列出「期待行動」後，為「商業目標」訂出可以量化衡量的「關鍵指標」（Metrics）。
在「星際奇航計畫」中，我們認為遊戲化的設計若是成功，那自主報名參加的隊伍數應該要可以超過我們原本計畫透過主管動員參加的隊伍數，所以可以以「報名參加的隊伍數」作為專案初期衡量活動成功與否的一個指標。另外，我們也討論到以「收集到的工程實踐案例個數」（Number of Good Practices Collected）作為專案後期衡量活動執行成功與否的指標。
遊戲化設計畫布中的「定義階段」（Define Stage） - 以「星際奇航計畫」為例
多數涉及創新的專案其實都是一個由混沌到清明的過程。專案初期的目標可能都只是一個不甚具體的想法。透過釐清需求、產出交付項目並與利害關係人來回確認的過程，設計師（或專案經理）才能漸次將專案目標及範疇具象化。遊戲化的專案也不例外。運用畫布中左側的三個欄位，可以幫助設計師（或設計團隊）在專案進行的過程中以迭代方式漸次釐清目標。
像「星際奇航計畫」這樣的企業內部遊戲化專案，設計團隊不需要在專案一開始時就耗費時間鉅細靡遺地定義所有資訊。若是以委外顧問的角色替客戶進行遊戲化專案，我覺得也可以在將畫布左側的這三個欄位跑過一輪並訂出量化指標後，便以書面方式請客戶確認並做為專案的基準（baseline）。之後若團隊對專案要達成的商業目標有新的理解或發現時，便可以有一個能被快速檢視的基準可與利害關係人進行討論或進行專案變更。
想看更多關於畫布左側「定義階段」三個欄位的說明可以參考我之前分享的《以遊戲化推動公司文化轉型》（上）篇。
確認了遊戲化欲達成的目標（或欲解決的問題）、對象、期望行動及衡量指標後，便可進入畫布「設計階段」（Design Stage）── 第四到第七個欄位。
四、使用者旅程（User Journey）── 遊戲化專案裡希望帶給目標對象的端對端體驗（End-to-End，從認識、加入到完成或退出）。
簡單的遊戲化專案可能只要針對使用者體驗歷程的部分特定階段進行設計即可，但若是像「星際奇航計畫」這樣用來推動跨國公司文化轉型的大型遊戲化專案，就需要針對目標使用者設計出可以囊括所有「期待行動」的完整旅程。
「星際奇航計畫」的使用者旅程 - 一段邁向協助客戶成功的星際冒險
以「星際奇航計畫」來說，我將使用者旅程設計成「展開一段與工作夥伴一同協助客戶成功的星際冒險（The Voyage to Customer Success）」。
大家在看到這樣的文字描述及示意圖時會產生什麼感覺呢？
我們希望透過設定這樣的使用者旅程概念，讓公司員工在第一次聽到「星際奇航計畫」時就可以就知道 「DevOps 是一件與客戶成功有關聯的事」，而不是特定一套的工作流程或工程實踐；另外，也希望他們意識到 「DevOps 轉型是個旅程」，而且可能是有點兒漫長、甚至費工費力的星際旅行（英文的 “Trek” 意思即是 “艱苦跋涉、牛車旅行”），不是什麼可以靠服用特效藥就藥到病除的快速翻轉過程。
我們認為：導入 DevOps 的過程就像兄弟爬山需得各自努力一樣，Ａ團隊的做法未必適合Ｂ團隊，Ｂ團隊可接受的改變也不代表Ｃ團隊的成員都可以接受。大家可以用適合自己團隊的步調展開自己的轉型旅程，並在旅程中實踐「改善沒有最好，只有更好」的概念。
另外，如果大家也從「星際冒險」字樣及各式卡通圖案等資訊中感受到「好像很有趣」、「很像可以玩遊戲」的念頭，因而激起了想要瞭解更多專案內容的想法，那也表示這個使用者旅程的概念設計得還不錯。因為，若有越多人願意瞭解活動內容，就表示之後有越多人願意投入並啟動自己的 DevOps 轉型旅程。
在這個大區塊當中，我建議設計團隊也將目前達成商業目標的做法以「既有替代方案（Existing Alternatives）」的資訊列在欄位中。因為，列出替代方案可以幫助團隊反思並規劃出比現有機制更好的創新方案。同時，這樣也方便利害關係人快速比較達成商業目標的不同方案。
設計師應該要時時提醒自己：「遊戲化只是達成商業目標的方法之一」，如果完成畫布後，發現設計出的遊戲化機制沒有比既有方案來得更有效率（如：無法更有效提高員工生產力）或能得到更大的效益（如：對提升公司雇主品牌形象沒有幫助），那不如不要浪費時間跟資源在專案中硬推遊戲化。
遊戲化設計畫布中的「設計階段」（Design Stage） - 以「星際奇航計畫」為例
在「星際奇航計畫」啟動之前，公司推動 DevOps 轉型的做法就是在重點產品開發專案中，由高階主管審查第一線主管擬定的計畫。但是產品開發專案的審查會議中，重點通常都在產品的商業模式、重要設計及效益，導入 DevOps 往往不是專案審查會議的重點。也因此，就算某個專案真的成功導入 DevOps 而改善了其團隊的效能及文化，團隊以外的人也鮮少有機會一窺堂奧，更不用說要複製別人的成功經驗於自己的專案中了！
透過列出端對端的使用者旅程及既有的替代方法，我們可以很容易地掌握遊戲化設計的全貌及其與既有解決方案的差異。接著就是要展開設計的細節，以便評估成本是否符合效益了。
五、設計的活動（Designed Activities）── 為了讓目標對象採取期待行動而設計出的遊戲化活動。
遊戲化就是透過讓目標對象採取特定行動並感受到玩遊戲般的興奮或樂趣，進而達成商業目標的一種行為設計方法。在簡單的遊戲化專案中，「設計的活動」與「期待的行動」通常就是相同的使用者行為，不需要特別的設計或轉化。但若是在像「星際奇航計畫」這樣複雜的專案中，各種「期待的行動」就必須透過適當的設計使其融入於使用者旅程的主題之中，以期透過轉化為「設計的行動」來營造代入感。
知名的連鎖壽司店 ── 藏壽司（Kula Sushi），在他們的店裡擺設了扭蛋機，消費者只要累積消費滿五盤，便可以透過將空盤投入機器中取得一次扭蛋抽獎的機會。扭蛋機啟動後會撥放一段卡通影片，並在結尾透過卡通中的主人翁是否通過挑戰的方式告訴消費者是否中獎。
雖然卡通、抽獎都與吃壽司無關，且每次看完卡通影片後也不保證一定都可以拿得到扭蛋玩具，但這個遊戲化的設計確實成功地讓消費者常常為了湊到 5 的整數倍盤數，而比自己平常的食量要再多吃一兩盤壽司。
藏壽司（Kula Sushi）的扭蛋機，每投入五個空盤就可以抽獎一次！
在情境較為複雜或為時較長的遊戲化專案中，設計師可能需要採用多個遊戲化機制於活動中。若各機制彼此互不相關，遊戲化的設計就很難產生綜效，並達到激勵目標對象持續投入活動的目的。因此，達成商業目標所需的各個「期待行動」需要進一步被轉化為符合使用者旅程情境的「設計的活動」，才能讓目標對象在活動中產生代入感。
「星際奇航計畫」中的「期待的行動」（左欄）與「設計的活動」（右欄）對照表
在「星際奇航計畫」中，我們希望參賽隊伍都能實際演練 DevOps 裡的「假設驅動開發」（Hypothesis Driven Development, HDD）方法，以運用數據來分析、驗證產品設計對客戶的價值。另外，我們也還希望參賽隊伍能分享他們在產品開發中實際的 DevOps 工程實踐並接受裁判的審核與評鑑，如此我們才有機會遴選出公司裡的最佳工程實踐方法並與其他團隊分享。
我在「星際奇航計畫」中透過「敘事」（Narratives）的遊戲化方法，將「期待的行動」重新命名為與太空冒險情境符合的活動名稱，並賦予各活動簡單、好記的編號。如：將「提交 HDD 計畫」轉化為「制定航行計畫」（Define a Voyage Plan）、將「提交 HDD 執行報告」轉化為「提交航行日誌」（Submit Voyage Logbooks）、將「分享/採用 DevOps 的程式碼」轉化為「發明/裝備武器」（Invent and Adopt Weapons）、將「提交 DevOps 工程實踐報告」轉化為「打怪」（Fight the Monsters）等活動。如此一來，參賽者在工作中的活動就有機會成為太空冒險旅程中的一部分。
如果遊戲化旅程中沒有將這些雖然重要但卻枯燥、乏味的「期待行動」轉化為符合使用者旅程情境下的活動，那麼多數玩家或許在報名時便不想去瞭解活動的內容，報名後可能也會因為活動缺乏與「使用者旅程」訴求的體驗有所連結而很快地出戲，更遑論要他們持續、積極地投入活動了。
專案起始前，有部份同事對我提案的這種遊戲化設計相當不以為然，他們認為這種把活動重新命名的做法只是多此一舉的噱頭。不過我們事後從許多「平時不願意在周末加班的同事卻願意在週末打怪」的現象來看，這些重新命名且與使用者旅程情境相符的活動確實能達到讓參與者產生代入感且積極投入的目的。
試想，你若是參加太空冒險活動的成員，當然有可能會因為周末的到來而不願意接受「打倒危害人類的外星怪物」的挑戰；但若同樣是沒有加班費可領的狀態，週末加班「提交 DevOps 工程實踐報告」可就更令人生厭了吧？！
這個欄位可以幫助利害關係人與你在進行遊戲化機制的細部設計之前便瞭解－專案中的「使用者旅程」裡會涵蓋哪些具體的活動，並且將以什麼樣的形式（或名稱）呈現。
「星際奇航計畫」中的兩種太空怪物 - 「Galaxy Wasp Swarm」 及「Space HIPPO」
以「星際奇航計畫」來說，參加者的主要活動有兩個：一是透過「提交航行日誌」演練｢假設驅動開發」方法，一是透過「打怪」提交「DevOps 工程實踐報告」。參賽隊伍可透過多次提交航行日誌的方式，將實踐 HDD 方法的記錄分享給其他團隊；或是挑戰一系列難度各不相同的太空怪物，陸續將不同的 DevOps 工程方法應用於自己的產品開發專案當中。
六、遊戲化機制與獎勵（Gamifications and Rewards）── 專案中會應用到的遊戲化機制及預計提供的獎勵措施。
將活動中的主要遊戲化機制及其獎勵列於畫布中，可以讓設計師及利害關係人快速掌握目標使用者在遊戲化專案中的可能體驗，並做為評估建置相關系統人力、物力成本與時程的參考依據。
先前提到藏壽司的「每投入五個空盤就可以啟動扭蛋機抽獎」的例子中，運用的主要是「點數」（Points）及「隨機獎勵」（Random Rewards）的機制，提供的獎勵則是扭蛋裡的小玩具或紀念品。而在星際奇航專案中，我則組合運用了多個遊戲化機制，像是「化身/頭像」（Avatar）、「點數」（Points）、「排行榜」（Leaderboard）等。而獎勵措施除了現金獎以外，獲得公司內的 HDD、DevOps專家的指導，或是有機會複製其他團隊的工程實踐至自己的專案中也都是我們活動中的獎勵措施。
具體列出這些機制與獎勵後，利害關係人及專案團隊便能在遊戲化設計的初期便評估技術上及時間上的可行性，並依照專案時間跟技術的限制，思考完成遊戲化機制的可行做法及執行專案所需的人力、物力及資金。透過這個欄位，專案團隊也可以快速掌握需要設計、開發的表單、系統或流程的範疇，及專案中的潛在風險。
「星際奇航計畫」中各參賽團隊會因其得分策略不同而有不同的太空船頭像
在「星際奇航計畫」中，我們設計了兩種不同的任務類型及不同的點數系統，讓參賽隊伍有機會透過完成不同的任務獲得不同的點數，並透過收集點數來升級做為他們隊伍頭像的太空船。除此之外，我們還設計了許多支線任務供參賽隊伍挑戰。像是：「發明武器」、「裝備武器」、「探索星球」等活動，並用點數系統將這些遊戲化活動串聯起來。
完成「遊戲化機制與獎勵」的設計後，就可以進入畫布的最後一個欄位：「動機」了。
七、動機（Motivations）── 激勵目標對象採取期待行動的動力來源，可以是採取行動後的獎勵、也可以是不採取行動時的懲罰。
畫布中的這個欄位是用來讓設計師（及利害關係人）快速檢驗「設計的活動」與「遊戲化與回饋迴圈」是否能有效驅動目標使用者投入活動。
史丹佛大學教授布萊恩福格（Brian Jeffrey Fogg）在他著名的 B= MAP 行為模型中提到：若希望人們表現出特定「行為」（Behavior）時，必須同時滿足三個條件：
- 確保其有充分的動機（Motivation）
- 確保其有足夠的能力（Ability）
- 提供適當的提示（Prompts）
史丹佛大學教授布萊恩福格（Brian Jeffrey Fogg）的 B= MAP 行為模型
遊戲化專案的本身就可以是一種「提示」。譬如說，「星際奇航計畫」就是個鼓勵員工於日常工作中實踐 DevOps的「提示」。如果我們希望這個提示能發揮作用並讓參賽者願意依照活動的設計去「打怪」、「提交航行日誌」、「發明武器」，那麼除了透過培訓課程提高其能力外，也可以透過提供專家的引導或良好產品介面設計來降低員工完成活動的難度。但是，員工的動機又要如何透過遊戲化設計來催化、產生呢？
我認為《遊戲化實戰全書》一書中提到的「八角框架」（Octalysis）理論提供了一個相當完整的架構，設計師可用該架構去評估遊戲化設計是否適當地運用了各種不同面向的動機。但如果你要在職場之中應用遊戲化設計，我覺得美國知名作家丹尼爾品克（Daniel H. Pink）在其暢銷書《動機，單純的力量》（《Drive: The Surprising Truth About What Motivates Us》）裡提到的三要素也非常值得參考。
品克在其書中提到了三個激勵員工的要素，分別是：
- 目的（Purpose）──從事一個超越小我的遠大目標的渴望；
- 自主權（Autonomy）──主導我們自己人生的欲望；
- 專精（Mastery）──對自己念茲在茲的事情精益求精的衝動。
「星際奇航計畫」裡目標使用者的動機分析
我在「星際奇航計畫」中進行遊戲化設計時，選擇了運用這三個面向來快速檢驗活動設計是否能讓目標使用者具備充足的動機以採取行動，並以此與利害關係人溝通，讓他們理解活動設計的可行性，進而支持整個專案的遊戲化設計。由於這三個面向相當直覺、易理解，我們在專案初期與利害關係人的溝通因此得以更專注於其他重要的專案資訊，而不會陷入討論遊戲化機制設計的細節上。
完成的遊戲化設計畫布應該要像下圖一樣 —— 可以用一頁A4大小的投影片完整說明遊戲化專案的內容。如果，你的專案資訊塞不進一頁投影片裡，那就是寫得太多、太細了，建議你再去蕪存菁。
「遊戲化設計畫布」填寫完成後的狀態 - 以「星際奇航計畫」為例
在 STOC 工作小組的群策群力之下，我們終於在這個月（2020年12月）順利完成了為期九個月的「星際奇航計畫」。過去十多年來，公司為了提升研發團隊的工程技術及管理能力，一直都常態地運用傳統的投稿給獎辦法收集工程實踐案例。但運用投稿頒獎的老方法，每年都只能收集到 20 ~30份稿件。今年，透過星際奇航計畫，我們於九個月內就在 DevOps 的各個知識領域內收集了 438 個工程實踐案例（是過去三年平均投稿數的1,460%），而且深度與廣度俱足！
除了近千人的參賽者直接在活動中深度學習 DevOps 知識與方法，並將其應用於日常的工作中以外，我們更透過這個遊戲化專案為公司訓練出60多位對DevOps 工程實踐及 HDD 方法有深刻瞭解的裁判與教練團隊！我們相信這些成果都會是公司持續推動 DevOps 文化轉型及協助客戶成功路上的好資產。
你也打算、或正應用遊戲化於工作之中嗎？
不妨來試試我設計的這個「遊戲化設計畫布」。
歡迎轉傳本文或追蹤本帳號以閱讀我分享更多關於產品服務創新、敏捷專案管理或用戶體驗設計的心得或文章。謝謝！
你可能也想看
