Back
Designtips.today
聊聊 DesignOps 設計營運 | 組織成長該面對的問題
May 18th, 2019
用 5 分鐘來了解怎麼在設計組織變大時持續保持效率
公司裡面的設計師變多、設計的工具不斷推出，UI/UX 的流程與分工越來越細緻、面向也很不一樣，國外的社群與研究員在 2016 年開始提出了 DesignOps 這個想法，這個新名詞包裝了什麼已知的知識？又怎麼能幫助公司提升開發效率？ 這篇介紹文章因此而生，附上文章段落提供讀者快速挑選想看的片段:
所以…什麼是 DesignOps?
DesignOps 包含的面向
DesignOps 的發展與工作職位狀況
每個公司都需要設計營運部門嗎
1. 所以…什麼是 DesignOps?
設計營運(或是設計維運) 是由 Design + Operation 兩英文字結合所產生的新名詞，設計營運團隊(或是一個人)的中心思想與職位內容在於:
訂定設計團隊的開發流程、降低跨部門的溝通成本、讓組織內設計師都能專注在開發上
在 2016 年時，這個字出現於 Airbnb 設計團隊的文章 中，Airbnb 的設計團隊在組織成長時遇到了管理層面的問題，透過這篇文章可以看看當時的團隊的想法與做法。
設計營運團隊要能訂出每個 onBoard 的設計師需要使用的開發工具以及在組織內合作時的模式，降低團隊內耗時的討論 (譬如交代進度、核對設計稿版本等等…) 與跨部門間的溝通成本 (譬如將設計稿交給工程團隊、快速搜集 PM 與受測者的意見回饋)。
如果說專案經理是公司對外與客戶溝通的角色，那設計營運團隊就是 公司內的組織潤滑劑，或像是 RPG 遊戲內的打鐵舖老闆，讓角色們可以放心使用手中的武器全力應付每天的任務。
示意圖: 知名遊戲的強大鐵匠 (來源)
2. DesignOps 包含的面向
DesignOps 其實不是個新的領域，只是將管理組織的方式包裝起來的一個通稱，甚至我們早在這字眼出來前就用了各種方式在維護組織的營運與健康。
目前 DesignOps 有以下的幾個面向 (這些面向參考這篇文章):
Workflow (工作流程): 在公司內設計的流程是什麼模式
Tools (工具): 我們需要哪些工具來完成工作
Governance (管理體系): 誰需要審核結果，在哪些時候
Infrastructure (基礎設施): 團隊需要什麼讓工作更有效率
Budget (預算): 需要多少預算來支援團隊，為什麼
Headcount (招聘人數): 我們需要多少人，並需要具備什麼技能
Pipeline (管道): 團隊人員應該如何配置
Retention (留職): 如何留下組織內的組員
Education (教育): 哪些技能還需要學習
Evangelization (傳達): 幫助組織暸解設計的價值所在
前四個 Workflow, Tools, Governance, Infrastructure 是公司在訂製整個產品方向時，設計團隊最直接會遇到的問題面向: 要使用什麼軟體、要由哪些人負責哪個部分、審核是給 PM 還是老闆…
而後面比較抽象、理念形式的部分，則是當設計團隊已經步上軌道、開始擴張之後會面臨到的問題，因新人加入會稀釋團隊文化; 而組員的離開也會帶走一些習慣，這些變動都是設計營運中需要去注意的面向。
3. DesignOps 的發展與工作職位狀況
DesignOps 目前在國外可以說是越來越被重視，這三年來許多的社群活動、研討會在世界各地進行著，譬如這場在墨爾本舉辦的 designops 聚會，裏頭有議題分享、訪談、資源搜集列表，舉凡 Autodesk、IBM、LinkedIn 公司中的 DesignOps 都分享一些管理自己團隊的方式:
而大型公司譬如 Spotify 也注重這一個缺塊，開始招募這方面的人才; 或是職缺網站 Glassdoor 內張貼的徵才文，在管理職職缺文中會描述希望來應徵的人能具備有關 designOps 的知識: “They enable design teams to focus on delivering elegant solutions by removing roadblocks and communicating and coordinating across workstreams.”。
左邊為 Spotify 徵才訊息 / 右邊為 glassdoor 徵才文描述，詳細內容參考
4. 每個公司都需要設計營運部門嗎?
不用，但至少要分得出 擁有設計營運概念 與 擁有設計營運團隊 這兩件事。
在多於一人以上的團隊之中，確保每個人都使用相同工具、模板、與開發流程是極為重要的，譬如良好的命名格式、歸檔的依據，遵守這些規定並不一定需要設置一個團隊來達成，而是 仰賴每一個人培養出習慣，以幫助日後回頭尋找或修改某些部分時，可以有效率一點。
在 2017 年，我寫下這篇設計團隊內可以使用的工具，用來改善設計師的工作流程，協助多人開發時可以避免不必要的衝突，並讓開發者與非開發者可以降低溝通成本。
在 2018 年，分別在台中與台北都分享了有關設計師的設計稿版本控制技巧。這兩場的分享給我自己的收穫很多，也更清楚知道目前業界對於一些工具的使用場景還是陌生。
在 2020 年，我寫下了“Meet me in the browser” — 2020 介面設計工具的狀態 來描述我對於工具革新影響設計營運的看法。我想設計營運會一直出現在你我周遭，這樣的議題很值得我們不斷、不斷去探索跟嘗試！