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

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

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

問(wèn)題1：前端的工作重心

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

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

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

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

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

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

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

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

具體的方法我們會(huì)在后面解釋。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)尾

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

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

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

我們下篇再賤！

第8期B端產(chǎn)品設(shè)計(jì)全能班開啟預(yù)約了~給彼此一個(gè)機(jī)會(huì)，現(xiàn)在就預(yù)約變強(qiáng)！