設計配合&溝通系統

來自專欄 貓看你的時候在想什麼

時間如果你想造一艘船， 先不用鼓動人們去收集木頭、分配工作和下達命令，而是，激發他們對浩瀚汪洋的渴望。

《小王子》安托萬·德·聖·埃克蘇佩里

近來隨著公司產品、人員的增多，需要整理一套公司多專業的配合系統，目的是為了提高配合辦事效率。配合的前提根本在於宏觀價值觀的認同和微觀上對背景／目標的理解一致，而為了達到這個效果的重要方式在於溝通。

關鍵字：價值觀、溝通配合、自我主動性、橫向維度、縱向維度、時間維度、流程化、規範、最小單元實驗思維

溝通是個很寬泛的說法，具體下去在不同背景下有不同方式。單從微觀角度結合這次整理配合系統總結下思路，對於業務簡單來說大家直介面頭溝通是最便捷有效的方式，而對於業務、人員繁多則需要條理的溝通配合系統來做基礎，它並不僅僅是文件系統、配合規範這些零散的點，而是一種配合的動態方式，它是一種有機體，是隨著業務變化而調整的，它不是墨守成規的戒律，它是溝通配合的共同框架基礎。

首先是對各崗位工作／配合流程、使用工具、產出內容等收集整理，詢問對配合方式、交互意見、固有交付物的規範，意圖在原有基礎上建構整體配合系統。由於大部分產品是OEM,每個產品的相關工作還不至於需要拆分成不同的小組負責，所以對於項目管理來說最大的兩塊分別是：不同產品的時間軸關係和同一產品時間軸關係

1.不同產品時間軸

2.同一產品時間軸：

針對實踐中整體系統的關係可以理解為時間維度和在時間點上的橫縱維度，時間維度指的是不同時間點上的配合，橫維度指的是不同的人、不同平台、不同角度的配合、縱維度指的的個人的溝通配合，同時個人溝通配合也涉及橫維度和時間維度；

橫向維度

多人配合的重點在於需求理解的一致以及打破個體之間的牆壁，這道牆是由於每個人工作內容的不同以及交付成果的可復用性差而帶來的，達到此目的的方式有保持實時同步、產出成果的可復用、重複操作流程化或者自動化、通用規範等方式。需求理解的一致配合的開始是要保證大家目標理解的一致，多專業討論是常用方式，需求文檔是討論確定之後的共同契約，形式不限。實時同步

項目進度可視化：利用項目整體進度可視化，自己會主動自主的去想現在什麼階段、還有什麼該做；任務管理同步協作過程同步：設計之間（Figma)／開發之間的實時同步(Git）； 交付成果同步：不同或相同崗位之間配合資料的同步（同步盤、sever），

成果可復用比如設計和開發之間的斷層很明顯，拿到設計成果，開發往往需要從零開始。現在有很多團隊在做打破設計和開發之間牆壁的嘗試，比如react for sketch（開發組件和設計組件）、webflow（網站可視化建設）、framer（動效代碼利用）、zeplin（直接查看，不要標註）；重複操作流程化或者自動化

針對產品相關物料涉及銷售、設計、供應商多方配合，每次成果交接需要核查，一開始經常出現問題：銷售文案更改頻繁、設計更改遺漏、供應商用錯圖檔等問題，帶來時間和成本的消耗。因此針對流程化的相關事項列成Checking list作為大家共同基準。

定義規範

不管是產品、設計、開發，不說多人配合，即使是一個人，他在不同的心情，時間，環境下也是有不同想法的，如果沒有一個系統作為基礎，任由發揮，那真的是亂套了。

文件命名規範移動端／web端設計規範包裝物料設計規範等

時間維度

工作中經常有如下情形：「誒，這個當時為什麼這麼做來著？」、「『如果這樣設計呢？』『這個以前設計過，用戶反饋不好，因為balabala』」、「啊，上一版我為什麼這麼設定這樣的流程？」。版本管理正是基於如上問題提出：

大的時間維度：記錄版本變化以及更改原因，便於團隊以及新同事對產品歷史有概念；

小的時間維度：多方案多角度嘗試探索，每個分支都是有價值的；

縱向維度

縱向維度是指自己與自己的配合，也涉及到橫向、縱向和時間維度的考慮。橫向是不同工具、文件的配合，縱向時間維度是項目管理。個體在工作中做具體事情時候，開始和結束都要多回到宏觀角度來看待具體事物，去想如果自己是負責人該去做什麼，自己是老闆會想什麼？該做什麼？做到分層次深入淺出。

具體事物之間是有關聯性的：聯動流程邏輯關係：不要僅僅關注自己做的具體事情，了解整體邏輯關係，考慮成因和影響同步邏輯關係：做當下事情時候，也要考慮是否還有其他關聯的東西需要調整。

結

總結了一些「術」，都是為了更有效率的辦事，最大的挑戰也在於不要囿於形式，其實那些方法都不重要，重點還是解決思路。而根本更多還在於大家價值觀認同、目標理解一致，這樣才會充分調動自我主動性。

思

程序之間溝通 vs 人與人之間溝通？

• 不同模塊負責不同處理
• 不同模塊負責鏈接不同模塊

Reference

Setup a design system

photo from 「FRAMED」