版本控制與設計規範協作經驗分享
在企業中，設計師要協作的不只是開發者和工程師，更包括不同的團隊成員、產品經理、QA以及其他不同的設計師要去合作。
小編一直都很喜歡在公司推行新工具或是新工作流程，只要是可以讓大家合作更為順暢和有效率，都會想要嘗試推行，而這篇文章主要是分享小編設計團隊在公司推行版本控制以及設計規範工具的一些挑戰以及心得。
團隊背景
以小編參與的一個項目為例，產品團隊(包括軟體、硬體以及韌體)包括：
軟體團隊: UX Designer, Visual Designer, Developer數名(不同OS，也包括遠端團隊), Software Engineer, Product Manager, Project Manager, System Engineer, QA, Content Strategist等
硬體團隊: UX Designer, Industrial Designer, Mechanical Engineer 數名, Project Manager, System Engineer, QA, Content Strategist和針對我們公司產品的DSP Engineer,RF Engineer和Compliance等等。
一般來說在硬體上UX Designer參與較多的是早期定義產品互動設計，而在韌體上與DSP Engineer, Product Engineer參與互動的部分比較多，畢竟在軟硬體都有的產品軟體的功能是跟隨韌體和硬體的。
有一點我們比較特別的是有個System Engineer(系統工程師)這個職位的存在，目的是幫忙紀錄所有的產品需求以及每個release的不同。可能是純硬體時代公司產生特別的職位。
版本控制的由來
版本控制不只是讓自己的設計檔案命名有效率的處理，設計檔案的版本控制更是讓其他設計可以清楚地了解每個版本的不同處，哪些版本是被批准而哪些版本是正在進行中，跟開發者也可以有更為清楚的流程。
而在推行版本控制的原因以小編的經驗如下：
設計師的吹毛求疵
體驗設計師總會隨時想要增進產品的使用性、介面和視覺，根據調研或是Analytics發現可以增進產品的體驗時，有時候可能是同個”功能”但是新的設計會增進使用性。
當然要如何讓產品團隊真的在做”改進相同的功能“是另一個話題，但是在此需要一個清楚讓團隊知道每個設計版本不同的差異性，以清楚溝通開發的需求，尤其在跨國協作上面，以小編公司為例除了當地的開發者，也有像是印度團隊和哥本哈根團隊的開發者等需要合作，無法每個時區都花上時間去說明設計的差異。
設計團隊協作
有時候同個產品會有數個設計師共同工作，當一方更新了設計文件，如何有效率地讓其他設計師看到更改？倘若同時其他設計師也做了其他更改，如何確定沒有重疊的部分？ 當然現在有許多協作工具像是Figma，但是對於習慣其他工具的人並不適應，也不適用於使用其他非純介面設計的設計方式（像是前端，或是使用其他一些互動原型設計工具）的設計師。
產品開發時間需求
產品開發團隊擁有需要優先化的需求去開發，項目經理(Project Manager)或是Product Owner會去根據產品上市或是每個更新要注重的功能去規劃Sprint，在時程上不可能會等設計團隊在最後一刻再把完美的設計交出來，團隊是當然遵循Lean的精神，若有版本控制的話可以利用最簡可行產品(Minimum Viable Product)的方式，一步一步的去迭代產品設計。
品質保證的需求
QA(Quality Assurance)主要是在確保產品的使用功能是否遵循設計，以及產品要求，當設計不斷迭代的前提下，QA需要在譬如「發行版本」的設計去品質測試，或是在前兩個版本去做測試，若可以看到前幾個版本的產品設計會幫助他們清楚的了解產品。
產品的特殊性
並不是所有產品都能完全享有超級敏捷的這種奢侈性，以小編公司為例，某些音樂科技產品包括了硬體、韌體以及軟體。硬體及韌體的部分更新頻率較低，「上市版本」鎖住了也會間歇影響軟體的功能以及擴展性，所以軟體團隊也必須配合硬體開發本身的瀑布式開發模式，韌體在某個階段下有其限制，而產品設計必須遵循該版本韌體的可行性去做設計。
當然，你可以選擇命名你的設計檔為v1.0.1, v1.1.0, v2.0.1…等等，現在也有比較制式的版本規則，像是major.minor.patch。但一來為設計版本命名的標準不一，二來對於其他跨部門的溝通方面也是會比較不順暢。
想像一下以下對話多麽複雜且有趣：QA問你：「欸我想看最新版本的設計，在那裡可以看到？是那個v1.0.1嗎？」你回答：「喔不是，我最近更新到v1.2.0，有新的介面可以看。」「啊那個v1.0.1是什麼？」「喔那個是我們修了一些設計的bug」「v1.2.0有多哪些東西？」….無限循環下去你光開會就飽了😂
四神湯的Shandy也曾經分享如何更有效率地去命名以及整理你的設計檔案：
設計規範協作需求及挑戰
許多設計師可能已經知道或是正在使用Zeplin以及Marvel這類設計規範分享工具，小編團隊也曾經使用Zeplin用過一陣子的設計規範協作工具，不得不說真的非常方便，設計師可以設定Design Guideline，開發者可以在上面下載icons，團隊也可以在上面詢問問題和提供意見等等。
然而，我們團隊用了不到一年就取消了，原因如下：
1. 版本控制並不符合團隊開發流程的需求
針對以上的需求，團隊需要的版本控制是整份設計文件，而目前這些工具都是適合更敏捷的模式，而設計輸出到Zeplin永遠都是最新更新版，雖然Zeplin提供了版本控制，但是是存在於每個設計頁面，對於針對我們以上的需求非常不實用。
2. 需要更正式的交接和批准
可能設計師的天性就是不停的改進設計😅而團隊想要更正式的在每個設計任務都有正式的流程讓團隊去做批准，畢竟產品設計更改對於我們影響的更多是韌體方面，需要確保團隊所有人都能瞭解哪些是必要，而哪些還是未知的設計。
而這也我們在實際使用起來以及不斷的跟團隊所有人試驗所得知的答案，所以並不是所有團隊都是一定要版本控制，或是一定要使用設計規範的。建議在推行新工具或流程之前，以使用者經驗的方式去訪談開發者、產品經理等與設計師密切合作的對象，先去了解團隊目前在開發上遇到什麼困難，而設計如何更和諧地與開發團隊合作，再來探索不同可能性。
Git
Git為一套分散式版本控制系統，最初的目的是用來管理Linux而開發設計，意及為在伺服器上有一套遠端的資料庫(Remote Repository)，而在每個開發者有個當地的資料庫(Local Repository)，所以當每個不同的開發者同時在同個產品上工作時，Git可以去釐清有什麼衝突(Conflict)，而Git也可以追溯到前面的版本。
而設計師為何要使用Git? 當有不同設計師在同個產品上工作時，使用Git可追溯每個版本的差異，讓彼此更和諧的工作。
以下是範例Git如何不同設計師之間協作：
Master在此就是大家去當作基礎的版本，Designer A可以再Master建立自己的當地資料庫(Pull)，而在自己的電腦上去做不同版本的更改(Commit)，而Designer B也可以在某一個Master版本上開始工作，而最終Designer A和Designer B都可以把自己設計合併在Master(Push)，而Master都會包含不同的修改。
聽起來很和諧，但是對於設計師畢竟不是工程師，需要更視覺化的看每個版本的差異，而且Git對於單一設計師使用性上也不大，不過！如果可以同時當作設計規範工具就更好了。
所以現在又衍伸出Abstract這種工具：
Abstract
Abstract是利用Git的概念，而去更視覺化的讓團隊可以看到版本的設計差異，可以在設計上提供回饋，開發者也可以直接在上面下載所需的Assets等等。
對於設計師，設定起來很輕鬆方便，對於產品經理也有網頁版可以去觀看，對於QA也可以追溯到不同版本的整個設計。
有一蠻酷的功能，設計師可以在Master上建立一個分支(Branch)做設計任務，在Abstract上面可以要求團員去”批准”，而在去合併設計檔案。所以以後誰說「這個東西改了我怎麼不知道？」你就可以大聲的說出「你批准了😠😠😠」
當然，並不是所有工具都完美的。Abstract目前是建立於Sketch之上的版本控制工具，所以設計師不是用Sketch就只能乾瞪眼，而小編試驗時也發現給回饋的功能有點不是很直覺，當其他人在某版本給回饋時看看不太出是在哪個版本，而要找回饋時常常找不太到。
其他工具
其他像Dropbox等雲端工也有給予基本的版本控制，但是功能非常少小編就不贅述了。
最後做了以下表來做個比較:
我們目前的使用方式為下：
我們也在使用Jira和Trello一些其他工具在追蹤設計任務，Abstract和Git的Master我們設定為團隊都同意開發的設計檔。每次有新的想法，或是團隊有需求時我們都會在任務追蹤工具裡建立新的任務，之後會在Abstract或是Git上建立分支，命名為該設計任務並在內容裡直接加上任務的內容或是連結。這樣在最後合併時團隊都會很清楚是哪個任務完成。
結語
分享了我們嘗試不同工具所遇到的問題和解決方案，最後想說，這段時間發現每個人其實都希望能夠更和諧的互相合作，而不同職位的需求以及注重的方向並不太一樣，並不代表他們不重視使用者體驗，而身為使用者體驗設計師，團隊成員都是我們的夥伴以及客戶，當然要以身作則多去傾聽對方的想法，多去讓大家了解使用者體驗的精神，而嘗試讓大家的合作更為順暢。
最後謝謝大家收看！也請喜歡的朋友麻煩不吝嗇給我們拍手👏👏🏻👏🏽和幫忙分享呦😁
-Wei
