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

所以，今天我們主要要分享的內(nèi)容就是如何解決這個問題，讓設(shè)計師在團(tuán)隊(duì)中實(shí)現(xiàn)更多價值。

更多開發(fā)技術(shù)知識干貨：

為什么開發(fā)做不出一致的界面

前端開發(fā)做的界面和設(shè)計稿不一致，90%以上的情況并不是因?yàn)榇a實(shí)現(xiàn)不了而做的妥協(xié)，絕大多數(shù)情況都是想做做得出來，但是沒有投入足夠的精力和時間。所以，這里就要具體問題具體分析，為什么開發(fā)沒有投入應(yīng)有的精力和時間。

問題 1：前端的工作重心

在前端工作中，正常包含三個層，架構(gòu)層、樣式層、行為層。結(jié)構(gòu)層就是以 HTML 組織起來的頁面框架，樣式層是以 CSS 為主的界面樣式設(shè)置和美化，行為層則是以 JavaScript 腳本為基礎(chǔ)的動態(tài)指令執(zhí)行和數(shù)據(jù)處理。

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

如果沒有前端的基礎(chǔ)可以不用糾結(jié)它們具體的內(nèi)容和作用，但需要知道的一點(diǎn)是，前端工程師的工作，并不僅僅是把界面的樣式給寫出來，而是要兼顧很多邏輯問題的處理，數(shù)據(jù)的收發(fā)，以及和后端的聯(lián)調(diào)（前后端代碼能接通并運(yùn)行）等。

對于所有前端工程師而言，邏輯層的價值和權(quán)重遠(yuǎn)遠(yuǎn)高于樣式層。因?yàn)闃邮絻H僅涉及頁面好看和不好看，最多影響了用戶的體驗(yàn)，但行為層的實(shí)現(xiàn)直接決定了產(chǎn)品的功能能不能用。產(chǎn)品先能用再談好用，是基本常識，一切業(yè)務(wù)需求的滿足都以功能實(shí)現(xiàn)為先決條件，所以前端的首要目標(biāo)必然是考慮怎么實(shí)現(xiàn)邏輯層的內(nèi)容。

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

但很顯然，項(xiàng)目預(yù)留的時間永遠(yuǎn)都是不夠的，往往滿足邏輯層的內(nèi)容就疲于奔命了，哪有空管設(shè)計長什么樣。產(chǎn)品可用性沒有實(shí)現(xiàn)，是要實(shí)打?qū)嵰粏栘?zé)的，KPI 會受到影響，而界面做的和設(shè)計稿不同，又不是什么大事，自然后面再說。

這就是所有前端界面還原度差的根源，有非常客觀的原因。但這并不代表邏輯層的內(nèi)容重要樣式層就完全可以隨便亂做或放棄治療，因?yàn)榍懊鏄邮阶龅奶S意往往會導(dǎo)致后續(xù)的修復(fù)和調(diào)整要投入大量的精力。

所以我們必須找到合理的解決方案，平衡兩者所要投入的時間，與其浪費(fèi)時間在后續(xù)的修復(fù)，不如通過提升樣式層的實(shí)現(xiàn)效率來提高交付的質(zhì)量。

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

問題 2：前端開源框架的應(yīng)用

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

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

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

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

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

所以，這就是整個項(xiàng)目團(tuán)隊(duì)都沒想清楚使用開源框架后怎么落實(shí)界面，以及匹配對應(yīng)的工作流程，從而產(chǎn)生很多不必要的損失和內(nèi)耗。

問題 3：細(xì)節(jié)部分的實(shí)現(xiàn)繁瑣

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

很多同學(xué)會有疑問，不是現(xiàn)在的設(shè)計軟件都支持標(biāo)注中包含前端樣式代碼了，直接復(fù)制就行，為什么還會出錯？

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

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

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

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

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

問題 4：樣式的復(fù)用和沖突

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

在前端實(shí)現(xiàn)中同理，樣式層中 CSS 樣式表就是用來控制頁面樣式的中心，可以在不同頁面，不同標(biāo)簽（約等于圖層）中使用這個樣式。

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

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

這種操作導(dǎo)致的后果必然是和原設(shè)計頁面差距越來越大，并且在后期修改中，因?yàn)楸缓喜⒌臉邮郊?xì)節(jié)太多，想要修改就得把錯誤的對象樣式分離出來創(chuàng)建成新的，光是識別哪些標(biāo)簽需要分離出來做合并，就需要耗費(fèi)大量的精力，這也是項(xiàng)目完成度越大，前端工程師越不想改文件的原因。

但又因?yàn)楹芏噙€原度的測試是留在項(xiàng)目結(jié)尾，在流程中直接固化了這種矛盾，同時又?jǐn)D入了大量邏輯層的問題需要修復(fù)，就更導(dǎo)致前端開發(fā)不會愿意修復(fù)樣式的錯誤，將這些問題保留到最終上線。

只是簡單的丟一份設(shè)計規(guī)范的標(biāo)注給前端等結(jié)尾驗(yàn)收最后的界面效果，是絕對不可能獲得滿意的結(jié)果的。

這就同樣需要優(yōu)化設(shè)計和開發(fā)的協(xié)作流程，樣式的驗(yàn)收環(huán)節(jié)必須前置化，需要有獨(dú)立的流程來消化樣式定義中的問題，而不是留到已經(jīng)快發(fā)版的測試階段再急著解決。

所以設(shè)計師需要在滿足前面所說的面向開發(fā)設(shè)計的思路外，還要結(jié)合前端工程師本身的工作順序和習(xí)慣，創(chuàng)建一個便捷高效的敏捷型驗(yàn)收模式，來提升前期樣式層開發(fā)的質(zhì)量，減輕測試階段的壓力。

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

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

結(jié)尾

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

B 端設(shè)計做的越多，你們就越會明白成熟的設(shè)計是根據(jù)對結(jié)果的限制做判斷來指導(dǎo)前期的行為，我們是針對項(xiàng)目做設(shè)計而不是僅僅針對什么是 “高級的”、“個性的”、“有設(shè)計感的”、“高大上的”。

當(dāng)然，如果你們認(rèn)為自己有現(xiàn)實(shí)扭曲立場，認(rèn)為開發(fā)就應(yīng)該給設(shè)計當(dāng)苦力，做什么就應(yīng)該實(shí)現(xiàn)什么也行，隨便你……

我們下篇再賤！

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