開發做的界面和設計稿差異巨大，或者完全不是一回事，是非常普遍的現象，也是最困擾 UI 設計師的問題之一。很多時候設計師辛辛苦苦設計了半天，最后落地的成品貨不對板，這就等于對之前設計的全盤否定，讓我們產生工作的內容毫無意義的想法。

所以，今天我們主要要分享的內容就是如何解決這個問題，讓設計師在團隊中實現更多價值。

更多開發技術知識干貨：

為什么開發做不出一致的界面

前端開發做的界面和設計稿不一致，90%以上的情況并不是因為代碼實現不了而做的妥協，絕大多數情況都是想做做得出來，但是沒有投入足夠的精力和時間。所以，這里就要具體問題具體分析，為什么開發沒有投入應有的精力和時間。

問題 1：前端的工作重心

在前端工作中，正常包含三個層，架構層、樣式層、行為層。結構層就是以 HTML 組織起來的頁面框架，樣式層是以 CSS 為主的界面樣式設置和美化，行為層則是以 JavaScript 腳本為基礎的動態指令執行和數據處理。

其中，HTML 即服務樣式也滿足行為層的實現，所以前端的工作核心可以簡化成樣式層（HTML+CSS）和邏輯層（HTML+JavaScript）兩個部分。

如果沒有前端的基礎可以不用糾結它們具體的內容和作用，但需要知道的一點是，前端工程師的工作，并不僅僅是把界面的樣式給寫出來，而是要兼顧很多邏輯問題的處理，數據的收發，以及和后端的聯調（前后端代碼能接通并運行）等。

對于所有前端工程師而言，邏輯層的價值和權重遠遠高于樣式層。因為樣式僅僅涉及頁面好看和不好看，最多影響了用戶的體驗，但行為層的實現直接決定了產品的功能能不能用。產品先能用再談好用，是基本常識，一切業務需求的滿足都以功能實現為先決條件，所以前端的首要目標必然是考慮怎么實現邏輯層的內容。

所以前端工作的順序通常是最低限度實現樣式層的內容（需要用于操作和顯示），然后投入邏輯層的工作中，后面有空再優化樣式的內容。

但很顯然，項目預留的時間永遠都是不夠的，往往滿足邏輯層的內容就疲于奔命了，哪有空管設計長什么樣。產品可用性沒有實現，是要實打實要被問責的，KPI 會受到影響，而界面做的和設計稿不同，又不是什么大事，自然后面再說。

這就是所有前端界面還原度差的根源，有非常客觀的原因。但這并不代表邏輯層的內容重要樣式層就完全可以隨便亂做或放棄治療，因為前面樣式做的太隨意往往會導致后續的修復和調整要投入大量的精力。

所以我們必須找到合理的解決方案，平衡兩者所要投入的時間，與其浪費時間在后續的修復，不如通過提升樣式層的實現效率來提高交付的質量。

具體的方法我們會在后面解釋。

問題 2：前端開源框架的應用

前端開源框架在今天的項目中已經完全普及了，很少有獨立開發完成所有前端代碼的項目。雖然前端框架可以極大的提高邏輯層的實現效率，但并不代表它在樣式層面能提供一樣的效果。

如果有下載和引用官方組件庫文件并用它們做設計的經歷，應該都知道這些文件用起來非常的麻煩，里面的組件、自動布局、響應式相互套娃，做個小改動就要調整一大堆文件和樣式，往往有修改它的功夫不如重新做個新的出來。

對于前端來說同理，開源框架雖然提供了豐富的默認樣式，但同樣也在樣式中應用了各種“套娃”，改起來遠遠比設計困難。

這就導致，如果前端開發使用了一款前端框架，那么設計稿中使用的組件是這套框架中帶的，那就直接調用這個樣式，只要功能實現出來，樣式上能不改那就盡量不改。包括圖表也是，圖表也基本使用第三方的框架，所以實現出來和設計稿最多就是顏色接近，其它哪里都不像，比如下面的真實案例。

只有組件庫中不包含的內容，才另外寫新的。但這又導致，新寫的東西會偏向設計稿（雖然實現得也不到位），但是實現的效果又和原來的開源框架效果相差甚遠，看起來非常的違和。

所以，這就是整個項目團隊都沒想清楚使用開源框架后怎么落實界面，以及匹配對應的工作流程，從而產生很多不必要的損失和內耗。

問題 3：細節部分的實現繁瑣

雖然用開源框架改起來很困難，但不代表把開源框架拿掉實現樣式也很容易。前端工程師還原設計稿，約等于用代碼把設計稿 “臨摹”一遍。即使是設計師自己臨摹一遍網上的飛機稿，也會發現臨摹完的結果差別很大，而代碼的臨摹遠遠比用設計軟件復雜，就更不是那么容易實現的了。

很多同學會有疑問，不是現在的設計軟件都支持標注中包含前端樣式代碼了，直接復制就行，為什么還會出錯？

這就是一直建議設計師也要學習 HTML+CSS 代碼的原因，用前端代碼布局實現樣式的過程和設計軟件操作有很大差異，上下層級和間距的控制邏輯是不等同于設計稿。想要和設計稿的參數完全一致，就一定要脫離設計標注，手動對特定的標簽做參數的微調。

這個問題不在這里做太詳細的講解，只要你們根據自己的設計稿去寫一個靜態頁面，就會理解為什么你每個參數好像都跟著原設計的標注做，但最后做出來的樣式就是不一致。

要解決這個問題不僅僅是指望前端工程師用超乎尋常的責任心和毅力去完成，而是需要設計師本身理解這個轉化過程的阻力，并能在這個基礎上發揮主觀能動性來提供有效的設計思路和工作流。

換句話說，經驗豐富的設計師不是使用魔法讓自己的設計稿完美落地，而是在一開始就直面開發阻力來規范自己的設計方式和文件格式，讓它們能被最簡單的轉化成代碼樣式并落地。我稱這個過程叫——面向開發設計。

當然，具體的方法我們也會在后面的分享中說明。

問題 4：樣式的復用和沖突

還有個非常常見的問題，就是樣式復用導致的沖突。在設計軟件中，我們可以定義一個字體、圖形的標準樣式，并運用到不同的圖層中去，只要我們修改該樣式，那么所有引用這個樣式的圖層都會同步更改。

在前端實現中同理，樣式層中 CSS 樣式表就是用來控制頁面樣式的中心，可以在不同頁面，不同標簽（約等于圖層）中使用這個樣式。

科學的前端管理必然是定義好一些通用的樣式，然后在不同的頁面和元素中復用，讓效率和統一性最大化。但問題是，很多時候前期定義的樣式不夠完整，比如間距、字號、色彩、透明度等等。

當前端工程師完成了第一階段的樣式表制定，那么在頁面開發過程中，出現了很多和前期樣式不匹配的新細節，最好的做法是停下來做統計和梳理，更新一波樣式再做下去。但這個過程顯然很麻煩，所以前端工程師就會挑個順手的樣式（Class 類）替代，即使它實現的效果和設計稿并不一致。

這種操作導致的后果必然是和原設計頁面差距越來越大，并且在后期修改中，因為被合并的樣式細節太多，想要修改就得把錯誤的對象樣式分離出來創建成新的，光是識別哪些標簽需要分離出來做合并，就需要耗費大量的精力，這也是項目完成度越大，前端工程師越不想改文件的原因。

但又因為很多還原度的測試是留在項目結尾，在流程中直接固化了這種矛盾，同時又擠入了大量邏輯層的問題需要修復，就更導致前端開發不會愿意修復樣式的錯誤，將這些問題保留到最終上線。

只是簡單的丟一份設計規范的標注給前端等結尾驗收最后的界面效果，是絕對不可能獲得滿意的結果的。

這就同樣需要優化設計和開發的協作流程，樣式的驗收環節必須前置化，需要有獨立的流程來消化樣式定義中的問題，而不是留到已經快發版的測試階段再急著解決。

所以設計師需要在滿足前面所說的面向開發設計的思路外，還要結合前端工程師本身的工作順序和習慣，創建一個便捷高效的敏捷型驗收模式，來提升前期樣式層開發的質量，減輕測試階段的壓力。

除此之外，還原度問題還包含切圖格式、投影樣式、動畫效果等眾多細節，我就不一一例舉，這些問題都是在可以建立有效的設計和前端協作方式后可以被輕松解決的問題。

而設計師要做的，就是必須站在開發的角度，從不同層面來思考為什么他們不能實現和設計稿一致的效果！

結尾

今天的解釋就先寫到這里，到下篇內容分享的合作方式，全都是基于已有問題創建出來的，所以不理解問題的根源也就不會理解那么設置流程的原因。

B 端設計做的越多，你們就越會明白成熟的設計是根據對結果的限制做判斷來指導前期的行為，我們是針對項目做設計而不是僅僅針對什么是 “高級的”、“個性的”、“有設計感的”、“高大上的”。

當然，如果你們認為自己有現實扭曲立場，認為開發就應該給設計當苦力，做什么就應該實現什么也行，隨便你……

我們下篇再賤！

歡迎關注作者的微信公眾號：「超人的電話亭」