敏捷設計，高效協同，凸顯設計端雲協同價值

DevUI團隊發表於2020-03-13

敏捷

DevUI是一支兼具設計視角和工程視角的團隊，服務於華為雲DevCloud平臺和華為內部數箇中後臺系統，服務於設計師和前端工程師。
官方網站：devui.design
Ng元件庫：ng-devui（歡迎Star）

引言

本文源自於DevUI團隊內部敏捷設計、開發/設計協同的實踐。

許多團隊選擇使用輕量級的設計軟體Sketch來快速繪製一些原型和設計稿，由此生成的標註設計稿，利於設計與開發的溝通。但設計價值不僅僅於此。

長久以來，設計圈與研發圈各自為戰，在規範化、規模化和一致性方面往往花費大量的溝通成本，導致了一系列的效率問題。本文會針對這些問題，從設計價值、設計效率問題、如何提效三個方面去講DevUI團隊實踐，最後做一些簡單呈現。

不論你是設計師、產品經理、開發工程師還是團隊Leader，閱讀本文，相信你都會有所收穫。

01 設計價值

設計價值趨向於賦能和牽引。

在現代網際網路產品競爭中，功能同質化越發嚴重，細節決定成敗，所以設計的作用越發顯得至關重要。

設計價值逐漸從支撐轉移到賦能，參與到產品的討論中。

許多企業面臨著相似的問題：產品體系龐大、持續擴充，人員與角色不斷擴充，設計跟不上產品演進速度。因此，如果設計師價值僅僅是支撐，已經是無法跟上現代化產品研發節奏，形成一個瓶頸，並且產品比拼中無法獲取優勢。

02 設計所面臨效率困境

當產品規模化時，設計資產繁重

華為雲應用研發管理平臺包括DevCloud、PaaS、雲龍等很多產品線，上百個微服務。幾十名設計師，每天都在產出大量的設計資產，包括產品、元件、圖示的設計等，同時不同設計資產有大量的版本。日積月累之下，要管理這麼多資產，是一件十分令人頭疼的事情。

讓我們設想一個場景，設計師小A在原有的稿上不斷修改，演進了10個版本之後，跟第一版有著天壤之別。此時，領導或產品經理PD又覺得第一稿比較好，但設計稿不像程式碼，還可以基於github進行分支管理，怎麼辦？設計師是不是要瘋掉。

產品、規範、元件等設計同步困難

隨著公司產品面不斷擴大，產品功能增多，團隊成員增長，角色增多，大家的協同是低效的。因為不同的角色有一套自己的工具和理解方式。當然產品從0到1的過程中，大家合作還是比較愉快的。

那麼問題就是產品不總是從0到1，而是在原有的功能新增、改變、替換等等，這會導致團隊的各個角色很難在積累資產的管理和資訊同步方面達成一致。

另外因為團隊之間存在地域隔閡，時間隔閡，目標隔閡，導致很多人不想同步老的資產。隨著時間的流逝，就會導致和加劇資訊不對稱，進而導致溝通障礙。

這個問題在設計與開發團隊之間尤為突出。

以DevUI的視覺按鈕為例，元件庫最初的版本，按鈕是圓角，顏色是綠色。

在18年的時候，我們按鈕圓角弧度變小，顏色也由紫色變成藍色，在未來，元件的視覺還會發生變化。如下圖所示：

如果我們的設計規則變化，設計師要花不少的時間精力去畫稿，校對，這個工作量很大但設計價值不高，卻又不得不做，即便花了很多力氣做，可能還是有一些不夠精確的地方。

視覺總會跟隨時代進步不斷改進，以滿足使用者需要。

冗繁、重複的設計工作導致產品創新乏力

網際網路時代，產品百花齊放，往往成功的只有老大。老大吃肉，後面的都只能喝湯。快速更新是產品研發過程中的一個顯著特徵和主要優勢。因此以整體流程的效率提升就變得至關重要。

基於DevOps理念的深刻實踐，在產品、大前端、後端開發、監控、運維等不同的階段實施流水線化、工具化，整個流程的效率得到了提升。

研發效率的提升伴隨可繼承資產的快速積累，極大地豐富了產品的功能。功能的豐富，導致業務功能很難具備足夠的競爭力。

聚焦於功能層面的核心競爭力往往擴充套件性較差，帶來的問題就是設計標準不統一，工作流冗繁，最終導致體驗差，質量問題嚴重。

設計稿版本化問題

我們總是在不斷做選擇，比較，然後選擇最優的。所以對資產進行版本化是十分必要的。版本化在文件和程式碼類的資產非常常見。那為什麼設計不可以？

這些都是我們正在面臨的問題，下面做一個簡單的小結：

如何面對產品規模增長的設計資產管理問題？
如何解決人員增長、角色增多，產品、設計、工程師等角色協同問題？
如何解放設計生產力，讓設計脫離重複工作，聚焦設計對產品賦能？

03 怎麼提效

針對上一節提到的問題，我們聊一聊DevUI團隊是如何嘗試通過技術的手段去解決的。

程式碼維護設計資產

設計與開發屬於不同領域，我們所期待的協作與溝通方式是明確而不存在歧義的，從而達到提效的目的。

我們先梳理下平常設計與開發溝通內容，無外乎針對設計稿開發工程師經常向設計師確認以下幾點。

屬性

顏色值

字型大小

用什麼字型

圓角值

邊框寬度

陰影值

間距

...

我們經常聽到的溝通內容是，開發問設計師，說我們規範是A，設計稿怎麼是B呢，此時設計師說，細節方面沒有特別注意，所以設計稿100%還原其實是做不到的。

所以，進一步思考，如果設計稿能抽象成各種各樣的基本資料，用資料來約束設計，用資料來約束開發，那是不是就可以解決這樣的問題。開發天然對資料敏感，而設計師對這些設計資料也不陌生。

所以設計協同，本質上是資料協同。而JSON資料格式為我們提供了資料協同的橋樑。

產品開發裡有前端和後端的分離，前端和後端之間的互動語言是json資料，json資料是能夠被前端和後端都易懂的格式，這種約定俗成的格式提高了前後端溝通的效率，只要一開始把互動資料的格式給定義出來。

在監控產品中有一種錄屏功能，它的原理是，把使用者的操作和DOM的變化轉化成json資料，傳到後臺，再通過這些資料呈現出使用者的行為。

就設計協同而言，設計所使用的Sketch，最基本的就是幾種圖形，Sketch通過API封裝把圖形轉化成json資料格式，傳遞到上層，那js就完全可以處理這些json資料。

Sketch是設計師鍾愛的設計軟體，是因為其簡單易學，並且能夠高效進行設計。Sketch在49版本開放了底層API。

通過這些API，設計稿最終轉化成了JSON資料。有了JSON資料，我們就可以為設計師、開發者、產品經理等角色更好的協同做一些工作。如下圖所示：

這裡列舉一個按鈕例子，我們先抽象出我們關注的一些屬性：

export const primaryButtonInfo = {
  component: {
    title: 'DevUI按鈕/Primary按鈕',
  },
  textInfo: {
    title: '確定',
    style: {
      color: '#ffffff',
      fontFamily:'PingFang SC',
      fontSize: 14,
      height:20,
      lineHight: 20,
    }
  },
  lineInfo: {
    borderWidth:1,
    borderRadius:1,
    borderColor: 'transparent',
    backgroundColor: '#5170ff',
  },
  commonInfo: {
    flexDirection:'row',
    justifyContent: 'center',
    alignItems: 'center',
    verticalAlign: 'middle',
    paddingTop:5,
    paddingBottom:5,
    paddingLeft:20,
    paddingRight:20,
    width: 100,
  }
};複製程式碼

最後我們再總結下帶來的價值。程式碼維護設計資產帶來兩大價值：

價值之一：減少設計重複勞動，極大提高設計效率，給設計創新騰出時間進行創新設計，甚至開發人員都可以對設計稿進行維護；
價值之二：程式碼所維護的設計資產是精確的，避免前端開發不斷指引設計稿間距、邊框、顏色跟規範不一致。

當互動設計稿設計好之後，如果後續在視覺方面需要就改，我們不希望還要針對性的去調整設計稿。而是修改資料就可以批量完成，如下圖所示：

設計資產版本化，選擇最優版本

對於同一個Feature或者元件的設計，幾易其稿是經常的事情，版本化管理是必然的。先看看DevUI對設計稿版本化歷程。

比較條目/方法	Espace	上傳到專案管理附件&文件	上傳DevUI文件	雲狐 + DevUI文件
設計稿檔案	混亂	分散化	集中化	自由集中化
設計稿檢視	需解壓檢視	下載，解壓	線上預覽	線上預覽
設計稿版本化	無	無	弱	強
設計稿查詢	困難	一般	中等	方便
設計稿協同	無	無	無	強