我們都學得會的時空旅行
淺談給設計師的版本控制
這個一個半小時我們會...
說明問題
版控介紹
實作
讓我們先了解 設計 這件事
設計由一個團隊來負責
我們在意設計語言、紀錄與分工
對於網頁/app設計來說
我們在意設計語言、紀錄與分工
對於網頁/app設計來說
設計 遇到的問題
命名、命名、還是命名
常見問題 1/3 —命名
在 Sketch 或許我們有這個辦法...
常見問題 1/3 —命名
為了保留每一個版本，避免覆蓋舊的設計
常見問題 1/3 —命名
我們不斷產生新的檔案、頁面
還得針對每個新頁面去想命名😵
guideline.sketch
guideline_v2.sketch
guideline_v2_copy.sketch
guideline_v2_copy_final.sketch
為了方便我們將檔案放在 google drive
常見問題 2/3 —存放
咦，不對
應該在我的電腦上才是最新版的
常見問題 3/3 —分工
「我修改登入頁面後再傳給你
這之前你先不要動 」
「你除了做這頁，沒多改了哪邊 ?
我要合併版本了 」
👩🏻💻 👨🏻💻
🚫
👩🏻💻 👨🏻💻
💭
🦄
於是，我去訪談了不同類型的設計師
接案設計師K
訪談—解決之道
👨🏻💻 👨🏻💼
與案主直接溝通
複製並用 日期 當作檔名
用 接力 的方式協作
或先分配好工作內容
👩🏻💻 👨🏻💻
App 設計師A
訪談—解決之道
👩🏼💼
: 美華，照著 Roadmap version 2 進行
👩🏻💻
：好的我會照著需求畫頁面出來
👩🏼💼
: 對了，等等早上的會再把這禮拜進度做個確認
某方面來說 PM 還是得當面跟設計師確認進度
矽谷 Design Lead
訪談—解決之道
👨🏻
: 通常一個設計師會負責到十個案子
不太會有兩名設計師做同一個區塊
👨🏻
: 我們沒有直接使用版本控制
但還是能透過 規範 與 工具 管理好檔案
其實，你們可以試試看版控工具!
關於工程師口中常說的
能啟發我們什麼
Git flow
Git 介紹 1/3 — 開發紀錄
不再考慮檔案命名，而是留下開發日誌
Git 介紹 1/3 — 開發紀錄
也能方便比較版本之間的差異
Git 介紹 1/3 — 開發紀錄
記錄不只是為了他人，也是幫助自己日後查看
Git 介紹 2/3 — 工作模式
如果我們先分工再合體...
Git 介紹 2/3 — 工作模式
時間寶貴，我們應該要分工開發再整合檔案
Git 介紹 3/3 — 存放與規範
統一要繳交到遠端 server 存放 (Github)
依照規範 push (上傳) 或是需要先 pull (下載)
確資料一致再繼續開發
說那麼多，讓我們試試看
我是素材
從剛剛到現在
你大概也不用想二次命名了
你還會發現
大家都有最新版本的設計
你會記下每一次工作日誌
能看到每次變動的檔案
甚至回到某個版本
訊息的整合
快速版本對照
專注在設計上面
才能發揮設計師最大的價值
示意圖 — 龍珠超:身勝手の極意
如果，我們還能跟 Github 連結...
不再考慮檔案命名，而是留下開發日誌
issue (任務) / commit (日記)也有對應
PM/Designer 都能專注在同一個問題
在查看差異 Kactus 甚至更方便、直覺
Branch: 分工的意義所在
來源: 設計檔 版本控制流程建立
小結
讓我們回顧一下
常見問題 1/3 —命名
google drive？ 我電腦？你電腦？
常見問題 2/3 —存放
咦，我也不知道
常見問題 3/3 —分工
「...所以我可以動頁面了嗎 」
「...忘了跟你說有一整個缺塊要更新」
👩🏻💻 👨🏻💻
🚫
👩🏻💻 👨🏻💻
💭
🦄
因為時間寶貴
何不讓我們一起學著版控
在溝通上面，我們可以讓設計過程被拆解
事情變得有條理，各方人員就更好追蹤與管理
不同風格的設計都會被留下來
PM 可以很快速地給客戶最後幾版的反覆比較
但現在起這就是給新人最重要的文件
傳承與交接 是我們費時又未改進的地方
在結束前補充一下
自帶版控、可以同時多人編輯、感覺是來打垮 Sketch 的
繼 doc, spreadsheet, 表單之後，google設計協作產品
目前功能完善，介面最美的版本控制工具
Lichin Lin 🤙🏼
懂些設計的工程師 @動畫、前端
Medium:
Codepen:
Github:
我們都學得會的時空旅行: 淺談給設計師的版本控制
By lichin
