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

時間 2020-05-12

標籤敏捷設計高效協同凸顯價值欄目快樂工作简体版

原文原文鏈接

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

引言

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

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

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

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

01 設計價值

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

在現代互聯網產品競爭中，功能同質化愈加嚴重，細節決定成敗，因此設計的做用愈加顯得相當重要。後端

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

許多企業面臨着類似的問題：產品體系龐大、持續擴充，人員與角色不斷擴充，設計跟不上產品演進速度。所以，若是設計師價值僅僅是支撐，已是沒法跟上現代化產品研發節奏，造成一個瓶頸，而且產品比拼中沒法獲取優點。運維

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,
  }
};

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