常常聽到工程師的背後總是有一屁股的技術債，你知道其實設計也會有嗎？
在工程師的世界裡，所謂的技術債（tech debt），往往指的是一些當時開發為求速度或其他因素，而產出比較難以維護、可能影響效能的程式碼，甚至也沒寫文件告訴你這件事情。
而在設計的世界裡，也有像這樣為求速度或達成某
也就是說，可以一致的東西不一致，這將導致在管理上的困難，也讓後人接替工作時，容易搞不清楚所以是否要遵守這些規則。
設計債的實例：Google Chrome 的 95 道陰影
這聽起來很罐頭式的標題，其實卻是個血淋淋的真實事件。
在去年 2018 年，Google 為了慶祝旗下瀏覽器 Google Chrome 的十週年紀念，全面更新了他的瀏覽器樣式，但在那之前，他們總共有 95 種不同的陰影（shadow）樣式。
在《Unboxing Chrome》裡面提到，雖然前幾年他們確實因應著 Material Design 這套文件的出現，檢視過一次是否有呼應這份文件所提到的原則，但他們並沒有詳細的規範（ guideline ），來讓設計師們知道要如何使用。因此，在他們多國不同載具下的 Chrome 瀏覽器，總共定義出了 95 種不同的陰影樣式。
雖然是非常小的細節，但這其實也可能導致幾個問題的出現：
1. 難以維護，降低效率
因為沒有詳細的規範，又或者是前人在專案結案的時候並沒有將這件事情寫下來交接給未來會繼續接手的設計師與工程師們，導致最後總共有 95 道稍微不同但作用幾乎類似的陰影樣式，而這其實會導致維護上的大麻煩。
實際上在他們這次的更新中，設計師重構了整個 Google Chrome 瀏覽器的 UI 與 UX 上的細節，工程師可能卻需要花費大量的精力，將 95 道陰影的樣式全部找出來逐一調整。（先讓我替苦手工程師一拜。）
2. 造成使用者體驗不佳，並且會稀釋品牌資產
第二個問題則是這將會造成使用者體驗不佳與稀釋品牌資產，任何一個小細節，都能夠讓介面為使用者帶來不同的感受與體驗。作用相同但卻樣式不一致的設計，嚴重時會干擾使用者在使用產品上的體驗，使用者會不知道該如何操作；小則很有可能讓品牌喪失了一次可以展現出品牌精神的機會。
是的，在這些視覺與互動的設計裡面，能夠展現出屬於品牌的風格。就像是當你看到某些特定的顏色使用與排版，第一個直覺就是立刻聯想到是某個品牌的產品，就是從這些方方面面體現出品牌的識別。
一致不代表唯一
值得一提的是，在設計上，為了求管理與維護上的方便，很多設計師可能認為要盡可能的讓所有樣式都精簡化，但那並不表示就需要限縮到只剩下一種樣式。
回到剛剛提到的那篇文章裡面，設計師 Hannah Lee 有提到，在他們多次的探索下，根據不同的實際狀況，最終設定了 8 種陰影。
那些年，Star Rocket 所欠的設計債
舉了一個 Google 的實例，那回到 Star Rocket 這樣的小組織，又有什麼樣的設計債？
目前 Star Rocket 旗下雖然沒有太多線上產品，不過在我進來開始使用新技術 Gatsby.js 進行官網的開發與 newsroom 的建置 ，以及半路還跑去當編輯製作《Star Rocket 創業週報》的途中，我發現 Star Rocket 的 logo 就像什麼神奇寶貝的百變怪ㄧ樣，有各種不同樣式的 logo。
圓角的 logomark、logotype 兩排變成一排、粗線條的、細線條的、自己在後面加字的，我其實也不知道我們到底有多少個版本，但這些全部都在 Star Rocket 當初 2015 年所寫的 brand guideline 以外的用法。
此外，還有發現各種好像有更新但日期卻非常相近，而且好像全部長一樣的 brand guideline 檔案控管，我看不出到底其中細微差異在哪。
簡言之，這兩個實際遇到的設計債其實反映出幾件事情：
1. 設計師因為實際的案例狀況（use case），而需要調整品牌識別，但卻沒有更新到 guideline 上
儘管多數團隊可能像 Star Rocket ㄧ樣，設計師就只有一個人來擔任，似乎沒有需要和其他設計師協作的可能。但別忘了，你離開以後，還有後面的設計師需要接著做下去。
沒有一份最新的品牌識別使用規範，就可能導致設計債的產生。一片混亂，債台高築，沒有人知道到底正確使用品牌的方式是什麼，其實是間接地是傷害了組織的品牌資產。
作為一個相信品牌會帶來價值的我來說，會覺得這地方的缺失會是非常可惜的，看了無數個優秀的產品 Airbnb、Shopify 等等，其實會發現到，他們能夠如此優秀，是因為他們從小細節開始就會認真看待，而且他們也認為這些細節都會是伸展品牌價值與理念的所在。
這陣子我爬梳了許多的設計系統（ design system ）或者是單純的品牌使用規範 （brand guideline） 像是 Starbucks Creative Expression 或 Shopify Polaris，得到了一個體悟是：雖然建立充滿文字的規範（guideline）似乎沒有實質的幫助，但這些能夠讓前後人可以知道該如何使用，讓別人在接觸品牌旗下的產品的時候，會知道這個是屬於哪個品牌的產品，也就是實際上其實對組織而言是有好處的，這是加深品牌印象的附加效益。
版本控管與歸檔
Star Rocket 內部雖然有歸檔的好習慣，但實際上在命名上以及版本控管上依然有可以改善的地方。像是我剛剛提的，雖然我們的 brand guideline 有更新，但我卻看不出到底其中細微差異在哪。
任何的變更都沒有提示是變更了哪裡，以及哪裡有增減，其實也會造成後人（也就是我）些許的疑惑與不安不知道到底是發生了什麼事情所以作了調整。尤其是還看到公司內部還有規範以外的識別在使用，就更使我疑惑。
這使我突然感覺到也許使用 Google Drive 單純做歸檔與統一命名也許還不是最好的協作方式。
我相信我遇到的狀況不算是特例，這些容易出現在組織內的事情，其實也意味著設計師也需要理解設計營運（DesignOps）這樣的概念。
什麼是設計營運 DesignOps？能吃嗎？
所謂的設計營運（DesignOps），是由 Design 與 Operation 所結合出來的一種新詞。根據 Invision 所推出的電子書《Design Ops Handbook》指出，DesignOps 是擴展設計團隊與增進設計效率的關鍵，隨著公司開始投入更多資源在設計上，會開始需要去優化設計的工作流（Workflow）、跨部門的溝通，好讓設計師能夠專注於設計上面。
這概念其實就跟 DevOps 的其中一種精神有相同類似之處：讓工程師專注於撰寫程式碼上，減少工程師將時間浪費在一些行政作業上面。也因此在工程師的世界中，他們會運用像是 Git 來管理自己的 code 的版本與協作問題、直接寫一隻程式碼或者是利用一個工具來讓原本人工進行 SOP 的部分直接交由程式去執行。
但此外其實他還有包含更多面向，包含：需要編列多少預算來支援團隊進行設計時能夠更加有效率、如何讓設計師們更密切合作、如何讓設計師上手新的設計工具與流程等等。
值得注意的是，雖然 DesignOps 聽起來像是一個職位（確實也有許多公司會把他當一個職位來徵才），但其實我認為算是一種概念。當設計師在做設計惡時後，除了設計本身以外，也需要去思考：
未來要怎麼讓其他人維護、這份產出如何讓工程師方便開發、應該選用什麼樣的設計工具來做設計、你所選的設計工具是否有符合你的需求。
靠設計營運思維優化設計流程
對，說這麼多，所以最後我們是怎麼解決目前遇到的問題的？
1. 重新使用一套新的設計工具 — — Sketch，來整理 brand guideline
經過了我們多次的考量，最後選用了 Sketch 這套系統來整理 brand guideline，但同時將 logo 的向量檔用 Adobe Illustrator 的檔案進行保存。
過去我們的 brand guideline 是使用 Adobe Illustrator 來維護的，但我們發現當我們決定要調整某個版本的 logo 識別時，需要花費大量的時間在逐一檢查哪裡有該版本的 logo，進行多次複製貼上替換成新的 logo 識別。另外還有一直在檢查確認過去的 logo 是否有在哪一個頁面是不對的版本。
這件事情是很浪費時間的。
因此後來我們決定使用 Sketch 來維護 brand guideline，他的 symbol 功能讓我們能夠確保 brand guideline 上面的 logo 識別都是一致的。
2. 用 Abstract 版本控管系統來整理協作與記錄變更項目
此時此刻我真的覺得能夠想出這樣一套版本控管系統的人真的很偉大，過去我曾經以為 GitHub 是個放程式碼給別人看，讓別人交流的地方，直到後來自己真正開始寫程式碼之後，才發現 GitHub 有所謂的 Git 版本控制系統。
版本控制系統主要是解決幾件事情：
(1) 解決你一直存檔最新版本還存到不知道自己哪個是最新版本
相信很多設計師都有遇過檔名叫「設計稿最終版.psd」「設計最終版1.psd」「設計最終版1–1.psd」等等的狀況。
版本控制系統則是可以幫你將每一份檔案紀錄都存起來並且告訴你先後順序依序是哪份，每份紀錄你可以記錄做了什麼變更，如果需要回復到上個版本紀錄，也可以輕鬆回去，自此再也不用煩惱命名了。
(2) 解決協作上會遇到的問題
如果團隊比較有規模性一點會共同一起編輯同份檔案，但因為不是即時連線，所以很容易會產生新的覆蓋舊的問題，等於強迫性的讓工作流變成瀑布式的，而版本控管系統則可以讓人同時協作，當人們上傳檔案時，系統會自動在合併檔案時，為你檢查有哪些變更的地方，把變更的項目更新進去，合併成新的一份，從此你再也不用人工檢查大家做的哪裡不同要合併在一起！
Git 這樣的思維大大地增進了工作效率，而目前也有多套專門給設計團隊使用的版本控管系統，我們則是決定選用 Abstract 來共同編輯整理 Star Rocket 的 Brand Guideline。
3. 用 Quip 文件紀錄設計檔案文件命名與設計相關資產擺放在哪
最後為避免未來的設計師朋友不知道我們目前所運行的設計流程與訂定方式，目前我們已經先寫好一份共同文件，交代將什麼東西放在哪，以及一些在做設計上的叮嚀，來減少未來每位設計師交接給下一位的時候，只交付了檔案，卻沒有提醒在製作上需要注意的細節。
另外，為了方便其他合作單位，以及讓所有人取得的檔案都是一致的，我們也在 Newsroom 上面公佈了品牌資源，讓外界也能夠知道該如何使用我們的品牌識別。
最後還需要理的債
對，我們重新優化了整個製作設計的流程，但是並不是這樣，就結束了 logo 百變怪的出現。在決定好最終幾個版本的 logo 之後，我們開始重新檢查了目前在線上線下使用的有使用到 logo ，陸續清點以及更改成線上的版本。
在這途中，也為了統一所有線上的識別，我們也將常見的 UI 按鈕顏色、標題大小與顏色一倂作了整理。所以像是 Newsroom、官網與週報上的色系也做了統一。
此外也許有人（也許根本沒有，哈哈）發現我們在線上所使用的主色調是另一種顏色，沒錯，由於我們希望 Star Rocket 帶有科技感，考量了許久後，決定顏色上使用將我們 logo 上的藍色用數值調整 RGB 後，將之定為網頁上的主色調，並且應用在 Star Rocket 的相關產品上面。
並且開始將有相同作用的元件的視覺一致化，像現在的官網與 newsroom 是使用一樣的 navigation bar 與 footer，未來也會請工程師協助將這些轉成同一套元件系統，方便未來工程師能夠維護。
用工程師的思維來做設計
以上是我們透過這次的設計債重新整理的過程，透過這次的整理，也優化了我們在做設計時的工作流。其實以前老實說從來沒有想過自己有天也會覺得工程師的思維還滿不錯的（誤），讓我間接的認為，多看一點工程師的世界與工程師交流他們如何寫程式碼，也許也是一件不錯的事。
過去在做設計時，總是用視覺優先（Visual-driven）來思考，但我發現工程師在寫程式碼的時候，還會思考怎麼樣寫可以讓工作效率變得更好，就像是 React 的出現，也是用了另一種思維來寫程式碼，讓工程師在未來維護程式碼的時候更為方便，因此儘管有些人（就是我）認為 React 概念很難懂，但其實長遠來看是好的。
當工程師們追求新技術的時候，也許並不只是因為潮，更多方面的考量有包含程式碼如何維護等等，所以設計師們，當工程師們在討論 Docker、API 的時候，也不妨參個一腳向工程師問問這些原理與概念或者是為何誕生的理由，也許會讓你在製作設計的工作流上有一些新的啟發囉！
最後如果有對 DesignOps 有興趣，不妨可以參考這些文章：
- DesignOps 101
- DesignOps: the questions you’re probably asking yourself now
- DesignOps Handbook
- 聊聊 DesignOps 設計營運 | 組織成長該面對的問題
有任何想補充與這些相關資訊或是單純分享回饋的，歡迎在這裡留言，或者是寄信到 venetia@starrocket.io，一起來聊聊做設計的甘苦談吧！
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出