當團隊 Scale Up 時…
從零開始在 17LIVE 導入 DesignOps
從 2016 年開始，國外的社群與研究員開始提出設計營運（DesignOps）的想法，最廣為人知的應該是 Airbnb 發布的 DesignOps at Airbnb。並在 2020 年開始，DesignOps 開始在國外的各種學術研討會被廣泛討論，比如說 DesignOps Submit、Figma Schema、Figma Config、Design System Week 等等。同時，這也是我第一次認識到 DesignOps 的一年。
什麼是 DesignOps？
根據 Kristin Skinner 在 2017 DesignOps Summit 是如此描述的：
設計運營側重於實務、人員和專案的健康。
Design Operation focuses on the health of the practice, the people, and the projects.
因此在設計營運的策略大致上如下：
- 進展（Progress）——如何有效率地完成專案。
- 過程（Process）——如何有效率地達到目標。
- 人（People）——如何有效率地共事。
針對 DesignOps 的解釋便不再贅述，本文會著重在為何以及如何在 17LIVE 的設計部門導入 DesignOps；就讓我們進入這趟旅程吧！
為什麼要導入 DesignOps？
從 2020 年加入 17LIVE 至今日，HQ Design Team 中的 Product Design Team 因應工作量的增加，從原本的 3 人逐步擴編至今的 14 人（七位 UX、六位 UI 以及一位 GUI 設計師）來負責 17LIVE 底下的兩個產品；與此同時 HQ Design 也成了一個多達 26 人的設計團隊。
原本因設計師較少，主要工作都以專案為優先的狀況下，被我們長期忽略的流程標準化、文件化的問題逐漸在 2021 年 H2 團隊擴編至 6 人時浮上檯面。再加上 17LIVE 在 2021 年中開始便採取混合式辦公（Hybrid Remote）的工作型態，逐漸浮出的問題、持續增加的溝通時間、以及打算再持續擴編的狀態下，導入 DesignOps 的勢頭難擋。
如何開始導入 DesignOps？
從一個亂中有序但逐漸失序的狀態中，該如何開始導入 DesignOps 呢？從 2021 年底到 2022 年底，大抵上會拆分成三個階段，分別為提倡（Advocate）、實施（Implement）以及優化（Optimisation）。
提倡（Advocate）
由於問題逐漸浮現，在 2021 年便開始向外探尋各種可以跟前輩們學習的經驗；便拿了公司的教育補助參加了 IxDA Taiwan 的 2021 年會，再自己熬夜追了 2021 的 Figma Schema。
從參加的這兩場年會中提取了一些跟 DesignOps 相關的主題並整理成一份簡報，並決定在 2021 年底跟整個 Design Team 分享。當時也因為絕大多數的成員沒有聽過 DesignOps ，因此在分享的 Q&A 環節中，也得到了各種提問與想要試試看導入的意願。於是乎長達一年的導入兼實驗（？）就這麼開始了。
實施（Implement）
在導入的過程中，其實並不像是製作專案一樣是線性地達到目標；而是多面向的展開並發展出多個組內的 Side Project。而每個 Side Project 之間彼此多少會有些許關聯，從而將大量的文件、制度、流程補成一張大網來支援每一個設計師。接下來我們就用上面提到的 DesignOps 策略，來說明我們大致上成功導入了哪些。
進展（Progress） — — 如何有效率地完成專案
☞ 設計系統（Design System）
以設計師的角度來說如何快速有效率地完成專案，第一時間想到的應該就是設計系統（Design System）。在過往 17LIVE 曾經歷了數次的品牌改造，在每個時期都留下了不同的設計風格與元件。因此在 2021 年尾開始，我們便專心地整頓我們從過往繼承至今的設計元件庫，並讓 UX 與 UI 密集討論每個元件的行為、使用規範與樣式規範並撰寫成文件。
☞ 檔案管理（Files Management）
以 DesignOps 的角度來說，透過一些 Figma 元件、插件等工具，讓設計師們做稿時能夠加快效率，同時讓所有人都能夠單看稿件就能夠理解整個專案的脈絡。讓專案遇上需要交接的情況時，能夠更有效地讓不同設計師、甚至是其他團隊能夠快速進入狀況。這邊日後會在有一篇如何有效增加 Figma Workflow 的文章與大家細講。
過程（Process） — — 如何有效率地達到目標
☞ 工作流程視覺化（Workflow Visualisation）
原本 Product Design 與其他團隊（PM, Dev 等）合作時，都是靠資深設計師領著新進人員去熟悉整體流程。但在後來也經過新人的反饋後理解，有視覺化的流程不僅對於新人更為友善，也可以讓其他的部門暸解，我們設計團隊在不同的階段，可以有哪些產出來讓專案更有效率地達到目標。
☞ 專案評估方法（Project T-shirt Sizing）
將過往讓每個設計師依照自己經驗去評估工時的方式，經由討論（這個真的花了很長很長很長很長很長很長很長很長一段時間）取得共識，並訂定出三個專案尺寸以及相對應的定義、工時。來讓整體開發時程能夠將設計的工時並入計算，更有效地了解整體的開發時長並提早做好準備。
☞ 新人手冊（New Hiring Playbook）
這個可能就要從我自己的慘痛經驗開始說起。當初 Onboarding 時就是個混亂的一週，簡單拿到了幾個 google drive 連結、Zeplin 權限後，就是自己摸索的開始；同時在一片混亂的同時就接下了第一個專案。（現在回想覺得真的很可怕）
於是乎在各個文件逐漸補齊的狀態下，我們也慢慢地將所有文件分類，依照順序規劃了長達一週的新人週。透過新人小天使的制度，讓後來較晚加入我們的新人都能夠有順序地去接觸他日後會需要的資訊與檔案。
人（People） — — 如何有效率地共事
☞ 我的使用手冊（How to Work with Me）
在第一次有新人接受新人週培訓的同時，巧妙地引進了 How to Work with Me 的個人使用手冊，讓所有團隊的設計師填寫。除了讓新人能夠更清楚地知道要如何跟大家共事之外，也讓 WFH 一陣子的所有人互相了解在遠端環境下的彼此該如何地更有效溝通與給予回饋。
優化（Optimisation）
任何的流程制訂、工具設計、規範撰寫等等，都很可能遇到不適用、不理想、或者過期需更新的狀態。
而這些回饋可能出現在一些例行的會議，比如說每兩週固定一次討論設計系統、設計變量、元件風格等等的 Design System Meeting、還有例行的 1–1、額外預約的下午茶閒聊、以及讓新人在體驗 Onboarding 流程並接觸專案一段時間後，提供如何優化新人使用手冊的會議之中。
透過不同的方式收集多方的回饋後，以公開的方式公告什麼東西遇到了怎樣的問題、我們優化後的解法可能為何、為何是這樣子的解法，同時也讓所有人表達改動後的回饋；透過這樣盡量透明且公開的討論，讓大家了解每個人的聲音都能夠被聽到。
後記
那一定需要有設計營運部門嗎？答案顯然易見的是：不。
當產品或設計團隊成長到一個規模時，設計營運部門、設計系統部門這類型的團隊才會更顯得重要。但在中小規模團隊中，擁有或去主動培養「設計營運」的思維一定沒有壞處。在一人以上的團隊中，使用一樣的工具、遵守一樣的規範、依循相同的開發流程等等，都是設計營運最重要的體現。
而 DesignOps 在 17LIVE 之後又會如何下去？坦白說我們也是邊學、邊做、邊優化，但值得開心的是日後在營運中偏向管理的部分也將是我觸手可及的領域，而其實有很多的事項也還沒開始進行。（光看下圖就知道有多少東西了）
與此同時，由衷感謝 17LIVE 所有 HQ Design 的成員們，有你們對 DesignOps 的感興趣與協力推動跟討論，在導入 DesignOps 以及實際展開營運的過程才能如此順暢。
但最重要的一件事，別忘記把所做的一切文件化！引用一句在 2021 年與啟蒙我的設計師 Jennie Yip 在 Twitter 對談時她所寫下的一句話做為收尾：
If you don’t document it,
it doesn’t exist. - Jennie Yip
你也是在團隊中推動 DesignOps 的那個人嗎？你在過程中有什麼遇到什麼問題呢？抑或是得到了什麼寶貴的經驗？都歡迎跟我分享！
謝謝大家的收看，也請大家不吝嗇多多拍手（我會當作是給我們所有設計師們的鼓勵 😍）我是 Should，我們下篇文章見 👋
🔗 我的 Bento
