讓設計安全著陸

經過眾多Web2.0優秀應用的薰陶，HTTP://www.aliyun.com/zixun/aggregation/4581.html">互聯網使用者變得越來越挑剔，對易用性的要求越來越高。 傳統意義上的「美工」已經不能勝任使用者體驗設計的工作。 產品遇到設計問題時的狀況通常是，工程師花了很大力氣做出來的各種強大功能是使用者不需要的，而使用者的一些簡單的核心需求卻得不到滿足。 為了突破產品設計的瓶頸，有的公司請來了使用者體驗設計師，建立了自己的使用者體驗設計團隊，有的公司直接將產品的設計外包給專業的使用者體驗設計團隊。 很快產品都有了好的設計，但是事情好像沒有那麼簡單。

我們的資訊架構師Maklu童鞋最近在推上抱怨：「各種行銷活動的代號直接當成業務放在了介面裡，系統還有各種的錯誤，好設計頂個錘子，最後出來的還是一個樣子，還是那坨屎。 」這是他參與一個設計外包專案，並目睹專案上線之後發出的感概。

在為客戶提供設計外包服務的過程中，如何讓我們的設計更好的被實現，而不會出現白天鵝變醜小鴨的悲劇，是一直是困擾著我們的難題。 經歷了無數次的失敗、反思和總結的迴圈之後，我們積累了一些經驗和心得，在這裡與大家分享。

在設計落地的過程中，我們遇到的最普遍的問題是設計師與工程師之間缺乏溝通。 設計師指責工程師沒有100%的還原設計，工程師則反擊設計師「站著說話不腰疼」，設計圖的效果無法實現或者成本太高。 後來就發展成兩方各自為政、互不信任，最後系統開發出來完全走樣。 為了避免這樣的問題，我們採取的方案是，工程師從一開始就參與到設計中來，設計師的每一個階段性成果物都需要跟工程師討論，確認技術上是否OK、成本是否適中。 這樣既能避免產生天馬行空無法落地的設計，又能加深工程師對設計圖的理解。

另一個讓我們摳腦殼的問題是，工程師對設計圖的執行力參差不齊。 設計師在製作設計圖時對留白、字體大小、字體顏色這些細節都是嚴格控制的，然而大多數工程師在開發的時候並不會考慮的那麼嚴謹和細緻，有的工程師處理元素間的留白靠的是自由發揮，有的在處理文字時則是「跟著感覺走，差不多就行」， 每個人的標準都不一樣，最後的結果就是同一個系統的頁面有不同的視覺效果，跟設計圖相比都有差距。 為了解決這個問題，我們在設計成果交付物中引入了視覺規範文檔。 視覺規範文檔的形式可以是ppt或者psd，裡面嚴格規定了設計圖中的每一個細節，包括元素的高寬、留白，字體的大小、顏色等，是指導前端開發的標準文檔。

另外，在與客戶的開發人員合作的過程中，我們發現前端開發的效率普遍比較低。 問題主要在於前端開發資源的重用性不高，沒有積累，前端開發人員之間缺乏協作和分享。 典型的情況是，同一個前端元件在不同的頁面被開發了兩次，或者前任工程師在離職之後沒有留下文檔造成一些複雜的元件無法擴展和維護。 為了説明客戶解決這類問題，更順利的實現我們的設計，我們為不同的專案建立了前端UI元件庫，將專案中重用性高的複雜元件放到元件庫中，以demo加文檔的形式組織起來，讓前端開發資源能夠積累和分享。 目前我們的UI庫還沒有開放，但是我們正在策劃一個前端UI元件開放平臺，大家可以在上面進行前端開發的協作、積累和分享，我們也將把兩年來積累的前端開發資源開放出來，相信很快就能與大家見面。

有視覺規範這樣的起落架減震，有良好的溝通作為降落傘減速，還有前端元件庫這樣的反作用力引擎，這三重保險讓我們的優秀設計在著陸的時候不至於臉蛋先著地，變成Maklu所說的一陀屎。

源位址：HTTP://mycolorway.com/blo......esign-safely/