內容概述

今天的內容主要是將我們為設計師的設計流程（DesignOps）進行優化的過程通過故事化的形式體現，以及我們的思考。

作為設計師，你應該對接過不少開發。你有沒有發現這些開發其實都有點懶，一件事情只要是重復了三次以上就不想再做了，而是會花時間去做一個工具，把這些重復的事情交給工具來做。

甚至你會發現，這個工具可能都不需要自己花時間做，而是已經有其他的開發者把代碼開源出來，只需要做一些小改動就可以直接用了。

利用工具來解決重復的工作有個好處，就是機器往往比人要更加可靠，更加穩定。同時還能把開發者的時間節省下來，專注在具體的問題上。

而這個偷懶的過程其實就是 devops 文化倡導的，通過構建相互合作的工具和文化，降低成本、提升效率和質量。對設計師來說 devops 到底是什么還是有點模糊，我舉一個更容易理解的例子。

我在家里有一項固定的任務是我要定期在家里打掃衛生，這對我來說是一個枯燥而且重復的工作。打掃衛生這件的事情，可以有其他的解決方案。比如：請個阿姨。所以我跟我老婆商量了一下是否可以請一個阿姨來定期打掃衛生，我們的討論結果是「我可以是那個阿姨」。

形勢所迫，我還是在網上買了一臺掃地機器人來幫我解決打掃衛生的問題。還挺貴的，因為它支持掃地和拖地兩種模式。但是用了一段時間之后我發現，我家的衛生問題并沒有得到改善。

首先，這個掃地機器人的清潔模式是一次性的，什么意思？就是它沒辦法自動從掃地模式換成拖地模式，你不在家的時候它只能掃地，或者拖地，二選一。

其次，雖然這個掃地機器人有兩個分別裝清水和污水的水箱，拖把臟了它會回到水箱底下進行清洗。但是經過實際測試，在不換水的情況下只能滿足 45㎡ 的房間拖兩遍。

對于我這種特別懶的人來說，這兩件事情就變成了我啟動掃地機器人的巨大門檻，這個掃地機器人開始閑置，我的家開始繼續變臟。我意識到繼續這樣下去的話，「我就會是那個保潔阿姨」。

所以我開始想是不是能讓更換拖把模塊和換水的工作自動化，降低我使用掃拖機器人的成本。于是，我又花了一筆錢買了一臺二手的掃地機器人，一臺專門負責掃地，另一臺專門負責拖地，每個機器人各司其職，節省掉人工更換拖把模塊的工作。

△ 圖片來源： https://post.smzdm.com/p/a259pzr2/

而自動換水是剛好家里的抽水馬桶給了我靈感。我在掃地機器人的清水桶上打了個一個小孔接上了自來水管，在桶里面裝了一個浮球開關，只要桶里沒水了就會自動加水。

我在污水箱里面裝了一個抽水泵，打了兩個小孔，一個給抽水泵供電，一個用來接污水的排水管，直接把污水排到了陽臺的地漏。

最后的方案是，我設定了一個標準化的任務，在工作日在我出門之后就自動啟動掃地機器人打掃家里的衛生，打掃完成后就另外一臺掃地機器人就開始拖地。因為不用擔心需要人工更換拖把模塊和換水的事情，我不需要做任何額外的工作就可以享受到干凈衛生的地板。這個案例剛好是一個典型的將 devops 思維應用在生活中的例子。

1. 提煉 DevOps

DevOps 的核心就是構建相互合作的工具和文化，降低成本、提升效率和質量。按照我們的理解，我們把通過 DevOps 實現降本增效的手段提煉為：

工具化和自動化可以讓我們減少原來在某一個流程上的重復工作，提升效率。而且工具的建設也應該是建立在開源協同的基礎上，利用已有的輪子而不是自建生態。

標準化的流程可以幫助我們避免人工處理帶來的不可控和意外的問題。

我理想中設計師的工作是這樣的：有了一個好的想法或者需求，設計師投入創作，最后交付，簡單而且又有成就感。

但是自從我開始做一些設計項目的項目管理工作之后我發現，并不是設計的工作簡單而是我的想法簡單了。設計師除了有一個好想法和進行創作之外，實際上還有很多需要跟上下游溝通以及打斷設計思路的事情，這都影響著設計師的效率。

這是我們梳理了一個設計師的日常工作的流程：

這樣的流程是合理而且非常良性的循環。但是我們發現這個流程并沒有給設計師帶來更高的效率，反而讓設計師的精力分散到各個環節，真正進行創作思考的時間變少了。

比如設計師各自有自己的素材資源庫卻沒有共享的機制；設計稿的管理依賴本地硬盤和公共網盤，一旦多人協作就可能出現版本不統一的問題；交付給開發的設計稿還需要手動導出切圖，重復溝通。

而且因為疫情的緣故很多公司開始遠程辦公，也讓這個流程上的問題更加突出了。設計師投入了非常多的時間在做一些重復又沒有收益的事情上。

2. 我們的角色定位

對比開發有這么多完善的工具和自動化的流程，設計的協作流程反而像是在刀耕火種的年代。

我們在想有沒有可能把開發的那一套 DevOps 的思維應用在設計師的協作流程中，來幫助設計師降低協作成本、提升效率和質量？按照我們剛剛提煉的核心手段，我們是否可以設計一套 DesignOps 的流程？

這個想法聽起來很棒，我們在團隊內做了不少 DesignOps 的腦暴，有了很多的新想法，最后我們的結論是只差一個開發了！而剛好我就是那個開發（或者說我們就是那個開發）。

我們是騰訊公司級的公線設計和研發團隊 CDC，我們給騰訊內部的其他設計團隊提供設計支撐服務。

我們最早碰到的是一個設計稿的版本管理問題。改稿似乎是設計師逃不掉的“宿命”，你剛開始給需求方做需求的時候，他們說：“按你的感覺來做，好看就行！”。你很快地就做好了第 1 版設計稿，但是有點小瑕疵，改了一稿。他們好像還是不太滿意，接連又改了 10 次。終于，需求方說：“我還是覺得你的第一版稿比較好”。這個時候你已經陷入了崩潰，因為你根本沒有保存第一版的設計稿。

當然，改稿的事情也不僅僅發生在國內，在 2019 年，Pizzahut 把他們最新的 Logo 改回了 1967 年的那個版本。這可能是歷史上時間最長的改回第幾稿。而且，我看到新 Logo 的顏色跟 1967 年的那個版本有一點點不一樣，是不是 1967 年的那個設計稿源文件也沒有保存下來呢？

你可能已經對改稿這件事有了比較好的心理預期，所以你開始給每次輸出的設計稿文件名打上版本號，就像這樣。

看起來這個方法還是挺實用的，萬一需求方要改回其中的某一個版本你可以很快的改回去。

但是，如果你存檔了 50 個甚至更多的版本，在你真的要找回以前的某個版本時，你唯一能做的是把所有的設計稿打開，在不同的窗口一個個的篩選，直到你完全迷失或者意外找到。

1. 嘗試直接用開發者的工具 GIT

其實在文件的版本管理這件事上，開發者有很多豐富而且成熟的工具。比如我們用 GIT 來做代碼的版本管理。就像你現在看到的一樣，我們可以通過 GIT 可以很清楚的記錄下來誰在什么時候修改了哪個文件的哪一行代碼的哪怕一個逗號。而且，他可以像時光機一樣，隨時回到你想要的任何一個歷史版本。看起來這個事情也不難，只要給設計師的設計稿做版本管理就可以了。我開始嘗試整理一些跟 GIT 相關的資料，打算給設計師講一講 GIT 的概念，這樣就可以讓設計師也能用上開發人員的這一套版本控制系統了。

2. 直接使用開發者的工具帶來更高成本

我在 Google 上檢索，在社交平臺上求助網友，希望找一個比通俗易懂的 GIT 教程。Google 和網友們給我推薦了這個評價非常高的教程：《猴子都能懂的 GIT 入門》，我認真的研究了一下這個教程上的入門篇目錄，整理了一個腦圖。

我陷入了困惑，我該怎么跟設計師解釋：

什么是數據庫，分支，克隆，合并？這可能真的是一份讓人覺得不錯（頭大）的教程，可是猴子哪需要懂這么多的概念啊。當然，我不是在說設計師連猴子都比不上，看不懂。而是這么多復雜的概念對于沒有計算機基礎的設計師來說真的太難了。

我繼續尋找有沒有《設計師都能懂的 GIT 入門》呢？是的，果然有更早比我想嘗試給設計師講明白 GIT 概念的人。我找到了兩篇文章：

• 《Git 與 Sketch 的神奇邂逅：Abstract》

他們的內容是這樣子的：前者嘗試用更簡單的方式來告訴你 GIT 的概念，而后者則是建立了一個設計師的 Github 網站，對比起 GitHub 稍微簡單一些。但是，不管是前者還是后者，你仍然需要理解分支 、克隆、合并的概念，這仍然是很難的。

這是去年在廣州，我花了半天的時間嘗試教會兩個設計師怎么使用 GIT，我偷偷錄了個小視頻，可能是習慣了圖形界面的設計師對代碼和命令行有一種天然的畏懼，我似乎看到了我爸媽第一次使用智能手機的感覺。

總之，如果我們想讓一個設計師能理解和使用 GIT 很難，想讓所有參與到協作的設計師都能理解和使用 GIT 是南上加南。因為他的門檻太高了，甚至比需求方的需求還要難。

而且，GIT 也并不是非常適合直接用在設計稿的版本管理上。因為代碼是文字內容所以可以比較容易的進行對比。而設計稿是一個獨立的二進制文件，沒辦法直接進行對比。

怎么理解這個問題呢？我打個比方，如果給你兩本不同時間出版的書，那你至少可以一個字一個字的對比他們有什么區別。但是如果給你兩塊不同時間生產的磚頭，你要怎么對比他們的區別呢？

3. 轉變思路 簡化工具

事實上，設計師并不需要理解太復雜的概念，他們的需求就只是希望有個地方能夠管理他們不同版本的設計稿，同時能看到各個版本設計稿之間的差異而已。

所以我們嘗試丟掉一些復雜的概念，然后把一部分必要的概念解釋成設計師能理解的語言。

• pull 的意思是下載更新
• push 的意思是上傳修改
• 初始設置 對應 個人設置
• 倉庫就是我的文件夾

我們把這幾個簡單的概念做成了一個 sketch 插件給到我們的設計師體驗。他只需要知道，看到設計稿有個小紅點，點一下更新，修改完了設計稿點一下上傳就可以了。而在這背后真正在工作的其實還是 GIT 的那一套概念。

另外，因為設計稿是一個獨立的二進制文件，我們把這些設計稿生成了一張張的圖片，讓這些圖片也變得像文本一樣可對比。所以不管以后你是在左邊畫了一條龍還是右邊畫了一道彩虹，設計師都可以把這些版本記錄下來，做清晰的比較。

在這個基礎上，我們還開發更多的工具來幫助設計師提升效率：

• 通過云端存儲，提供在線預覽設計稿的能力不用安裝專門的設計軟件
• 項目成員可以直接在設計稿上反饋修改意見，查看歷史版本
• 開發可以自行下載標注和切圖

通過借鑒和簡化 GIT 的概念我們做了這樣一個工具來幫助設計師解決設計稿的版本管理問題，同時也衍生了一系列其他的工具。

一個購物車的圖標，它出現在某個商品的立即購買按鈕上。這個圖標從出生到被你看到一共經歷過幾步呢？

• 首先，設計師在矢量設計軟件畫出了這個圖標；
• 然后將這個圖標進行二次加工（轉曲、壓縮、去色、規范命名）；
• 因為不需要考慮兼容低版本的瀏覽器，在和開發人員討論后你們決定用現在最合適的 SVG 格式；
• 在企業微信里面把圖標文件發給了開發工程師；
• 為了更方便的復用這個圖標，開發把它存到代碼庫并轉換成組件可以隨處調用；
• 最后這個圖標會隨著最近的一個版本發布，出現在你的眼前。

1. 更多的場景帶來更復雜的問題

一個圖標從設計到上線確實不復雜，但是并不是所有的項目都能夠非常規范的按照這個流程來：

嘗試用工具解決一部分問題

有了前面的經驗和工具化的意識，我們在發現了這些痛點之后做了幾個工具來幫設計師解決這些重復的工作。

我們做了一個專門的加工工具，只要導入圖標就可以自動進行轉曲、壓縮、去色生成新的圖標文件。我們在內部搭建了一個圖標庫管理后臺，支持按照項目管理圖標。習慣偷懶的開發也編寫了一個腳本，可以把圖標自動生成組件。

有了工具加持，我們可以保證每次加工后的圖標是合格的；保證每個圖標都是最新的版本；省去了重復編寫圖標組件的工作。

2. 問題依然存在且容易斷流

我們發現，雖然我們提供了很多工具來避免重復的工作，但是設計師或者開發者還是需要頻繁的接入到這個流程中。

用工具加工完的圖標需要手動上傳到圖標庫，更新圖標之后要在企業微信上告訴開發，開發生成代碼還需要手動敲一次命令。而這些人工操作的流程存在很高的不穩定性和不確定性。任何一個步驟異常都可能會讓這個流程無法進行。

可能是設計師忘記通知開發圖標已經更新，也可能是開發不小心敲錯的一個圖標名稱，都可能給產品帶來線上問題。

而這個人工操作圖標的過程就像給你送外賣的外賣小哥，你永遠不知道你的外賣什么時候才能送到你的手上。

3. 整合工具自動化

在我們理想中，工具應該是盡量減少人工的操作。就像我們使用掃地機器人和智能家居一樣。我在工作日出門，回到家可以看到干凈的地板。在我走進廚房的時候，廚房的光線是足夠明亮的。這些自動化的場景涉及到了多個工具一起協作，里面可以有復雜的交互，幫助我們考慮各種特殊情況，而我們不應該參與到其中，只需要關注我們行為和最終的結果。

所以，我們做了一個管理工具的工具，把他們串聯在一起。在這個自動化流程里面，設計師只需要上傳設計好的圖標，就能把最終需要交付的內容推送給開發。如果是替換一個已經存在的圖標，還會自動發布新版本。

在整個流程中，設計師只需要關心圖標的設計，而開發者只需要關注圖標應該使用在哪里。其他的工作都交給了工具自動化處理。除了提升設計師和開發者的效率，還避免了很多人工操作帶來的不確定性，保證最終的交付質量。

以上是我們在工具化和自動化上的一些實踐，后面我們將分享我們在標準化和開源協同上的一些嘗試。

其中案例一/案例二的解決方案已經上架到 CoDesign 的設計稿和圖標庫兩個模塊，歡迎體驗。

設計稿：?https://codesign.qq.com/workspace

如果你想快速知道我們在幫助設計師提升設計效率上做了哪些事情，可以直接訪問我們的 CoDesign 設計協作平臺：https://codesign.qq.com