<b>本文講的是别再設計你的應用界面了，在使用者體驗上下點功夫吧，</b>
<b></b>
這篇文章是我們新釋出的界面指南的一部分
八個月前，在一個機構工作一段時間後，我終于決定給自己一個新的挑戰。現在可以很自豪地說，我加入 BlaBlaCar 的設計團隊。
在剛到這家公司的前幾周時，我是真的對他們的工作方式有些無語。 他們的工具僅僅是一個空空的 Sketch 檔案，一塊兒白闆和兩部用來給應用做測試截屏的手機。
BlaBlaCar 的設計師們所使用的工具: 一個空的 Sketch 檔案和兩部測試機。
他們通過直接向 Sketch 裡導入截屏的方式來設計一個頁面或流程——裁剪截圖，直接在截圖上編輯，遮蓋或是建立一些新的元素，也有時候從之前完成的檔案中拿點兒什麼之前完成的元件...從始至終都能聽到他們的自言自語，比如，“邊距多少是合适的？”，“這個按鈕要設計成什麼尺寸？”，“哪個顔色最好看？”等等。 我發現，我自己為了避免重新建立一些已經有了的元件，總是在問我的同僚諸如去哪個檔案裡找到我需要的按鈕或者導航欄這樣的問題...
這分别是同一個私人資料界面在 Android, iOS, MWeb 和 Web 上的樣式。為什麼要差的這麼多呢？
我總會記得問自己：“他們是如何管理這麼多不同平台，不同邏輯甚至不同設計的同一個界面的呢？”其實答案很簡單：他們根本沒有花心思管理這件事兒。。
這種工作方式可能僅僅适用于兩三人的團隊。其實，我們都知道這樣的工作方式對于維持一個快速擴張的團隊是非常有挑戰性的。我們都認為應該将工作重心放到使用者體驗上而不是繼續在界面設計上浪費時間。
我們決定用一個簡單的方法來解決這個問題：
采用樂高的設計模式，将我們使用者界面的元件子產品化。
LEGOS! 你也許已經聽說過仿照樂高風格的設計。是的，給我一箱樂高的磚塊，我就能做出所有東西！
一架水上飛機, 一輛肌肉車（譯者注：常見于北美的一種車型，國人最熟悉的應該是大黃蜂）甚至一條恐龍。
是以我們建立了一個”樂高磚塊“風格的元件庫，這樣我們的設計師就可以用一樣的素材了！那麼來看看我們的“樂高磚塊”（譯者注：這裡作者想要表達的是可複用等方面的樂高模式，而并不是模仿樂高外觀上的設計）
這是一些 BlaBlaCar 設計師使用的使用者界面元件的樣本
他們可以很快完成一個頁面或流程的設計，并加速疊代和測試的過程。
你也許好奇我們通過這種方法究竟能省下多少時間。我們其實也好奇這點，于是就做了一個樣本測試。我們删掉個人資料的頁面，然後讓我們的設計師分成兩組重新設計它，一組用我們的“樂高元件庫”，另一組不用。
這是被重新設計的界面。
我們對他們的設計過程計時了，結果是肯定的: 在不使用我們的“樂高庫”的時候他們要花費 24 分鐘去完成它，而使用的話就隻需要 13 分鐘了！我不是想表達我們有多專注于高效，這不是重點，重點是我們的設計師現在可以少在樣式設計上花費 50% 的時間，而在使用者體驗上多花費這 50% 的時間，這正是我們期待的結果。
在 BlaBlaCar，我們從未如此滿足于此，我們相信通過不斷的疊代改善這些界面庫，我們可以省下更多的時間。
嘗到甜頭之後，我們試圖繼續找出一些重複性又消耗了大量時間的任務。在不斷的探索下，我們發現了一個巨大的問題，也是每個設計師每天都會遇到的問題，那就是多平台處理。
一個元件 = 多個平台
所有人都知道，先給 iOS 設計一個界面以後還要再重新給 Android 和移動端網頁設計同樣界面是多麼煩人的一件事。我們緻力于建立一個元件庫，使我們能夠在每個平台上使用同樣的元件的同時保持相容性。現在我們的設計師隻需要設計一個平台的就夠了，因為他知道相容性完全沒有問題。比如，一個前端開發者可以用 iOS 或是 Android 的設計去設計一個同樣的移動端網頁。
我們通過這樣的管理使設計師們省去了 50% 用于設計界面的時間，也讓他們不再需要設計多個平台的界面。不過我們還不滿足，我們想要節省更多的時間。現在我們在 BlaBlaCar 所使用的流程如下所示：
設計略圖 → 設計架構 → 設計原型 → 最終設計 → 投入開發
你應該已經明白了，我們并不想讓設計師花費時間在這麼幾個像素點上! 是以接下來我們要做的就是讓我們的設計師直接從設計略圖這一步跳到開發這一步。
我們很自信，通過我們的元件庫，設計師将一個設計略圖交給開發人員以後，開發人員可以輕松的開發出一個完全符合略圖的生産版本。
我們不希望讓設計師再花費任何時間在設計樣式上了，他們需要專注于使用者體驗
我們把這個方法完美緊密的套用在了前面提及的樂高磚塊模式上，這幫助我們有效的溝通。大家都可以很快的了解并交流我們的意見。公司裡任意一個領域的人都無需我們的講解就能很容易的分享自己的見解。
在實行了這個設計模式幾個月後，我總結了一些關于如何使用它的重要準則。這不是什麼激動人心的科學成果，不過它确實可以讓我們少走些彎路：
比喻： 一定要找到一個有力的比喻，來使别人毫不費力的了解你的觀點（甚至你無需解釋）。 我們選擇了樂高，但你也可以選擇一些别的 (化學，福特主義，生态學等等)
溝通：這是使你的項目不緻失敗的最重要的一點。 盡可能早的和公司裡所有的人溝通好：開發人員, 産品經理, 資料工程師, 設計師, 甚至首席執行官——讓他們參與其中。
共同的語言： 沒名字的東西是不存在的。確定每個人都知道（并習慣）你在元件上使用的詞彙。你不需要太專業，隻要確定每個人用同樣的方法去叫它就可以了。
準則： 對于選用每一個界面元件都要有準則。如果你不能很好的解釋為什麼要使用一個元件，那就規定要使用他。 (我會在另一篇文章裡談論這點)
沒有例外：任何例外都很容易讓你們不在保持一緻性。即使成品看起來很奇怪，在一開始也要遵守那些準則群組件的設計，千萬别搞例外。例外情況往往在你嚴格遵守準則後都能不攻自破。
我并不是想說我們的方法就一定是正确的。我可能更傾向于說我們的方法更适用于我們的産品視覺設計，而不一定适用于所有公司。我見過許多感興趣設計系統的人，我很樂于跟他們讨論，擷取他們的回報，和他們辯論，當然也包括你。不久的将來我會繼續寫一些文章來更精細的描述我們是如何建立現有的這套系統的，在這期間，如果你想了解更多，請聯系我。
<b>原文釋出時間為：2016年08月13日</b>
<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>