2023-9-14 ui設(shè)計(jì)分享達(dá)人
開發(fā)做的界面和設(shè)計(jì)稿差異巨大，或者完全不是一回事，是非常普遍的現(xiàn)象，也是最困擾UI設(shè)計(jì)師的問題之一。很多時(shí)候設(shè)計(jì)師辛辛苦苦設(shè)計(jì)了半天，最后落地的成品貨不對板，這就等于對之前設(shè)計(jì)的全盤否定，讓我們產(chǎn)生工作的內(nèi)容毫無意義的想法。
所以，今天我們主要要分享的內(nèi)容就是如何解決這個(gè)問題，讓設(shè)計(jì)師在團(tuán)隊(duì)中實(shí)現(xiàn)更多價(jià)值。
為什么開發(fā)做不出一致的界面？
前端開發(fā)做的界面和設(shè)計(jì)稿不一致，90%以上的情況并不是因?yàn)榇a實(shí)現(xiàn)不了而做的妥協(xié)，絕大多數(shù)情況都是想做做得出來，但是沒有投入足夠的精力和時(shí)間。所以，這里就要具體問題具體分析，為什么開發(fā)沒有投入應(yīng)有的精力和時(shí)間。
問題1：前端的工作重心
在前端工作中，正常包含三個(gè)層，架構(gòu)層、樣式層、行為層。結(jié)構(gòu)層就是以 HTML 組織起來的頁面框架，樣式層是以CSS為主的界面樣式設(shè)置和美化，行為層則是以 JavaScript 腳本為基礎(chǔ)的動(dòng)態(tài)指令執(zhí)行和數(shù)據(jù)處理。
其中，HTML 即服務(wù)樣式也滿足行為層的實(shí)現(xiàn)，所以前端的工作核心可以簡化成樣式層（HTML+CSS）和邏輯層（HTML+JavaScript）兩個(gè)部分。
如果沒有前端的基礎(chǔ)可以不用糾結(jié)它們具體的內(nèi)容和作用，但需要知道的一點(diǎn)是，前端工程師的工作，并不僅僅是把界面的樣式給寫出來，而是要兼顧很多邏輯問題的處理，數(shù)據(jù)的收發(fā)，以及和后端的聯(lián)調(diào)（前后端代碼能接通并運(yùn)行）等。
對于所有前端工程師而言，邏輯層的價(jià)值和權(quán)重遠(yuǎn)遠(yuǎn)高于樣式層。因?yàn)闃邮絻H僅涉及頁面好看和不好看，最多影響了用戶的體驗(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ì)長什么樣。產(chǎn)品可用性沒有實(shí)現(xiàn)，是要實(shí)打?qū)嵰粏栘?zé)的，KPI會(huì)受到影響，而界面做的和設(shè)計(jì)稿不同，又不是什么大事，自然后面再說。
這就是所有前端界面還原度差的根源，有非常客觀的原因。但這并不代表邏輯層的內(nèi)容重要樣式層就完全可以隨便亂做或放棄治療，因?yàn)榍懊鏄邮阶龅奶S意往往會(huì)導(dǎo)致后續(xù)的修復(fù)和調(diào)整要投入大量的精力。
所以我們必須找到合理的解決方案，平衡兩者所要投入的時(shí)間，與其浪費(fèi)時(shí)間在后續(xù)的修復(fù)，不如通過提升樣式層的實(shí)現(xiàn)效率來提高交付的質(zhì)量。
具體的方法我們會(huì)在后面解釋。
問題2：前端開源框架的應(yīng)用
前端開源框架在今天的項(xiàng)目中已經(jīng)完全普及了，很少有獨(dú)立開發(fā)完成所有前端代碼的項(xiàng)目。雖然前端框架可以極大的提高邏輯層的實(shí)現(xiàn)效率，但并不代表它在樣式層面能提供一樣的效果。
如果有下載和引用官方組件庫文件并用它們做設(shè)計(jì)的經(jīng)歷，應(yīng)該都知道這些文件用起來非常的麻煩，里面的組件、自動(dòng)布局、響應(yīng)式相互套娃，做個(gè)小改動(dòng)就要調(diào)整一大堆文件和樣式，往往有修改它的功夫不如重新做個(gè)新的出來。
對于前端來說同理，開源框架雖然提供了豐富的默認(rèn)樣式，但同樣也在樣式中應(yīng)用了各種“套娃”，改起來遠(yuǎn)遠(yuǎn)比設(shè)計(jì)困難。
這就導(dǎo)致，如果前端開發(fā)使用了一款前端框架，那么設(shè)計(jì)稿中使用的組件是這套框架中帶的，那就直接調(diào)用這個(gè)樣式，只要功能實(shí)現(xiàn)出來，樣式上能不改那就盡量不改。包括圖表也是，圖表也基本使用第三方的框架，所以實(shí)現(xiàn)出來和設(shè)計(jì)稿最多就是顏色接近，其它哪里都不像，比如下面的真實(shí)案例。
只有組件庫中不包含的內(nèi)容，才另外寫新的。但這又導(dǎo)致，新寫的東西會(huì)偏向設(shè)計(jì)稿（雖然實(shí)現(xiàn)得也不到位），但是實(shí)現(xiàn)的效果又和原來的開源框架效果相差甚遠(yuǎn)，看起來非常的違和。
所以，這就是整個(gè)項(xiàng)目團(tuán)隊(duì)都沒想清楚使用開源框架后怎么落實(shí)界面，以及匹配對應(yīng)的工作流程，從而產(chǎn)生很多不必要的損失和內(nèi)耗。
問題3：細(xì)節(jié)部分的實(shí)現(xiàn)繁瑣
雖然用開源框架改起來很困難，但不代表把開源框架拿掉實(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ì)有疑問，不是現(xiàn)在的設(shè)計(jì)軟件都支持標(biāo)注中包含前端樣式代碼了，直接復(fù)制就行，為什么還會(huì)出錯(cuò)？
這就是一直建議設(shè)計(jì)師也要學(xué)習(xí) HTML+CSS 代碼的原因，用前端代碼布局實(shí)現(xiàn)樣式的過程和設(shè)計(jì)軟件操作有很大差異，上下層級(jí)和間距的控制邏輯是不等同于設(shè)計(jì)稿。想要和設(shè)計(jì)稿的參數(shù)完全一致，就一定要脫離設(shè)計(jì)標(biāo)注，手動(dòng)對特定的標(biāo)簽做參數(shù)的微調(diào)。
這個(gè)問題不在這里做太詳細(xì)的講解，只要你們根據(jù)自己的設(shè)計(jì)稿去寫一個(gè)靜態(tài)頁面，就會(huì)理解為什么你每個(gè)參數(shù)好像都跟著原設(shè)計(jì)的標(biāo)注做，但最后做出來的樣式就是不一致。
要解決這個(gè)問題不僅僅是指望前端工程師用超乎尋常的責(zé)任心和毅力去完成，而是需要設(shè)計(jì)師本身理解這個(gè)轉(zhuǎn)化過程的阻力，并能在這個(gè)基礎(chǔ)上發(fā)揮主觀能動(dòng)性來提供有效的設(shè)計(jì)思路和工作流。
換句話說，經(jīng)驗(yàn)豐富的設(shè)計(jì)師不是使用魔法讓自己的設(shè)計(jì)稿完美落地，而是在一開始就直面開發(fā)阻力來規(guī)范自己的設(shè)計(jì)方式和文件格式，讓它們能被最簡單的轉(zhuǎn)化成代碼樣式并落地。我稱這個(gè)過程叫——面向開發(fā)設(shè)計(jì)。
當(dāng)然，具體的方法我們也會(huì)在后面的分享中說明。
問題4：樣式的復(fù)用和沖突
還有個(gè)非常常見的問題，就是樣式復(fù)用導(dǎo)致的沖突。在設(shè)計(jì)軟件中，我們可以定義一個(gè)字體、圖形的標(biāo)準(zhǔn)樣式，并運(yùn)用到不同的圖層中去，只要我們修改該樣式，那么所有引用這個(gè)樣式的圖層都會(huì)同步更改。
在前端實(shí)現(xiàn)中同理，樣式層中 CSS 樣式表就是用來控制頁面樣式的中心，可以在不同頁面，不同標(biāo)簽（約等于圖層）中使用這個(gè)樣式。
科學(xué)的前端管理必然是定義好一些通用的樣式，然后在不同的頁面和元素中復(fù)用，讓效率和統(tǒng)一性最大化。但問題是，很多時(shí)候前期定義的樣式不夠完整，比如間距、字號(hào)、色彩、透明度等等。
當(dāng)前端工程師完成了第一階段的樣式表制定，那么在頁面開發(fā)過程中，出現(xiàn)了很多和前期樣式不匹配的新細(xì)節(jié)，最好的做法是停下來做統(tǒng)計(jì)和梳理，更新一波樣式再做下去。但這個(gè)過程顯然很麻煩，所以前端工程師就會(huì)挑個(gè)順手的樣式（Class類）替代，即使它實(shí)現(xiàn)的效果和設(shè)計(jì)稿并不一致。
這種操作導(dǎo)致的后果必然是和原設(shè)計(jì)頁面差距越來越大，并且在后期修改中，因?yàn)楸缓喜⒌臉邮郊?xì)節(jié)太多，想要修改就得把錯(cuò)誤的對象樣式分離出來創(chuàng)建成新的，光是識(shí)別哪些標(biāo)簽需要分離出來做合并，就需要耗費(fèi)大量的精力，這也是項(xiàng)目完成度越大，前端工程師越不想改文件的原因。
但又因?yàn)楹芏噙€原度的測試是留在項(xiàng)目結(jié)尾，在流程中直接固化了這種矛盾，同時(shí)又?jǐn)D入了大量邏輯層的問題需要修復(fù)，就更導(dǎo)致前端開發(fā)不會(huì)愿意修復(fù)樣式的錯(cuò)誤，將這些問題保留到最終上線。
只是簡單的丟一份設(shè)計(jì)規(guī)范的標(biāo)注給前端等結(jié)尾驗(yàn)收最后的界面效果，是絕對不可能獲得滿意的結(jié)果的。
這就同樣需要優(yōu)化設(shè)計(jì)和開發(fā)的協(xié)作流程，樣式的驗(yàn)收環(huán)節(jié)必須前置化，需要有獨(dú)立的流程來消化樣式定義中的問題，而不是留到已經(jīng)快發(fā)版的測試階段再急著解決。 所以設(shè)計(jì)師需要在滿足前面所說的面向開發(fā)設(shè)計(jì)的思路外，還要結(jié)合前端工程師本身的工作順序和習(xí)慣，創(chuàng)建一個(gè)便捷高效的敏捷型驗(yàn)收模式，來提升前期樣式層開發(fā)的質(zhì)量，減輕測試階段的壓力。
除此之外，還原度問題還包含切圖格式、投影樣式、動(dòng)畫效果等眾多細(xì)節(jié)，我就不一一例舉，這些問題都是在可以建立有效的設(shè)計(jì)和前端協(xié)作方式后可以被輕松解決的問題。
而設(shè)計(jì)師要做的，就是必須站在開發(fā)的角度，從不同層面來思考為什么他們不能實(shí)現(xiàn)和設(shè)計(jì)稿一致的效果！
設(shè)計(jì)師和前端開發(fā)，如何實(shí)現(xiàn)高效協(xié)同的工作流
上一篇內(nèi)容我們簡單分享了為什么項(xiàng)目中前端的界面還原度無法達(dá)標(biāo)，這一篇內(nèi)容我們就要討論如何有效解決這個(gè)問題。
設(shè)計(jì)稿的落實(shí)是一個(gè)系統(tǒng)性的工程，中間的每一個(gè)階段都不是獨(dú)立存在的，都包含對前面要素的繼承和對后續(xù)工作的影響。在此，我要借鑒 DevOps 的模式，來構(gòu)建一個(gè)設(shè)計(jì)師和前端協(xié)同的工作流。
設(shè)計(jì)和開發(fā)有個(gè)根本的矛盾，那就是一個(gè)是方案，一個(gè)是實(shí)施。
方案可以各種天馬行空發(fā)揮想象力，而在實(shí)施階段卻要受到各方面的制約和損耗，例如時(shí)間、預(yù)算、人力、專業(yè)程度等。
在部分項(xiàng)目中，方案的權(quán)威性不容挑戰(zhàn)，實(shí)施方要想盡一切方法去實(shí)現(xiàn)，并對最終的效果負(fù)責(zé)。但在多數(shù)情況下，實(shí)施方的權(quán)重更高，方案的實(shí)現(xiàn)由實(shí)施方?jīng)Q定。所以，100分的方案往往只能得到 5、60分的結(jié)果，不管你對結(jié)果怎么交涉也很難再有實(shí)質(zhì)性的提升。
很多項(xiàng)目如果本來只有做到60分的水平，那么從一開始奔著100分的水平去設(shè)計(jì)和交涉，都是在浪費(fèi)精力和降低項(xiàng)目執(zhí)行效率，要花費(fèi)雙方更多的時(shí)間。所以前期的分析核心的目標(biāo)，就是搞明白項(xiàng)目需要做到什么程度，可以實(shí)現(xiàn)什么標(biāo)準(zhǔn)。
設(shè)計(jì)的分析點(diǎn)主要包含下面幾個(gè)：
設(shè)計(jì)權(quán)重分析
設(shè)計(jì)工作排期
前端資源認(rèn)識(shí)
1.1 設(shè)計(jì)權(quán)重分析
即重點(diǎn)認(rèn)識(shí)項(xiàng)目、尤其是領(lǐng)導(dǎo)上級(jí)對設(shè)計(jì)的重視程度，設(shè)計(jì)結(jié)果在項(xiàng)目中的重要性。
例如一個(gè)直播軟件，針對禮物打賞這種創(chuàng)收場景，那自然是要把設(shè)計(jì)做到極致，不僅要讓用戶看著爽，甚至還要優(yōu)于競爭對手。而一個(gè)內(nèi)部使用的ERP管理系統(tǒng)，自然不會(huì)有多高的設(shè)計(jì)要求，只要界面能看懂不出錯(cuò)就行（又不是不能用）。
兩種完全不同的場景決定了設(shè)計(jì)實(shí)現(xiàn)的上限在哪里，如果在第二種情況下用第一種的要求來完成設(shè)計(jì)，那么設(shè)計(jì)的產(chǎn)出注定是要被浪費(fèi)的，因?yàn)閳鼍安患嫒荨?/p>
所以我們必須根據(jù)場景來判斷設(shè)計(jì)應(yīng)該做到哪個(gè)程度，而這個(gè)程度雖然不能直接量化出等級(jí)（每個(gè)人的高中低認(rèn)識(shí)是不一致的），但可以通過找到對應(yīng)的案例作為參照。
同時(shí)，項(xiàng)目實(shí)際的要求還分成兩種，一種是項(xiàng)目真實(shí)需要的，另一種是滿足“領(lǐng)導(dǎo)要求”的。這在可視化項(xiàng)目中非常普遍，前期對設(shè)計(jì)稿和實(shí)現(xiàn)效果的要求極高，因?yàn)榱㈨?xiàng)階段還要給其他大領(lǐng)導(dǎo)過目或者要競標(biāo)勝出，而幾個(gè)月后相關(guān)領(lǐng)導(dǎo)根本不記得前面看過什么方案，所以實(shí)現(xiàn)成什么樣就是什么樣（開發(fā)Freestyle）。
這也就意味著，設(shè)計(jì)是設(shè)計(jì)的，落地是落地的，兩件事是獨(dú)立的，不需要建立錯(cuò)誤的預(yù)期。
1.2 設(shè)計(jì)工作排期
即分析項(xiàng)目中所需設(shè)計(jì)內(nèi)容的明細(xì)，并評(píng)估所需的時(shí)間成本并安排時(shí)間節(jié)點(diǎn)。在工排期分析中，主要要結(jié)合三個(gè)要素分析，設(shè)計(jì)工作總量、交付時(shí)間節(jié)點(diǎn)、設(shè)計(jì)權(quán)重要求。
設(shè)計(jì)工作總量的分析是非常重要的前期分析，一個(gè)有經(jīng)驗(yàn)的設(shè)計(jì)師應(yīng)該在設(shè)計(jì)工作開展前，就把本次項(xiàng)目所需的工作明細(xì)都整理出來，包含要設(shè)計(jì)多少個(gè)頁面、整理哪些文檔、對接哪些工作和會(huì)議。
有了這些明細(xì)就可以估算所需的時(shí)間范圍，之所以是范圍，原因就是設(shè)計(jì)任務(wù)的完成度是有彈性的，往淺的做自然很快可以完成，往深的做可能就要多花幾倍的時(shí)間。所以這就受到前面設(shè)計(jì)權(quán)重的影響，需要項(xiàng)目的設(shè)計(jì)做到什么水平，必須有個(gè)清晰的判斷。
同時(shí)，交付時(shí)間也不是全憑設(shè)計(jì)師個(gè)人決定，而是要緊跟項(xiàng)目的整體排期。所以當(dāng)分析工作所需時(shí)間遠(yuǎn)超排期時(shí)，就肯定要做工作調(diào)整，一方面協(xié)商減少工作量，另一方面要適當(dāng)降低工作質(zhì)量的要求，跟上排期的進(jìn)度。
之所以提這個(gè)，是因?yàn)樵O(shè)計(jì)還原度的實(shí)現(xiàn)是需要投入時(shí)間的，如果設(shè)計(jì)任務(wù)本身的工作就把你全部精力占用了，那么在前期就肯定預(yù)留不出時(shí)間去做和還原度有關(guān)的工作。所以建議設(shè)計(jì)的工作量安排至少預(yù)留出20%左右的時(shí)間，一方面應(yīng)對需求的調(diào)整和突發(fā)情況，另一方面要用于和還原度有關(guān)的任務(wù)上。
1.3 前端資源認(rèn)識(shí)
搞清楚負(fù)責(zé)界面樣式的前端人數(shù)、精力和技術(shù)水平。
前面說過前端開發(fā)中，樣式和邏輯是分開的，如果邏輯部分的工作量大，那么留給樣式部分的精力就少，所以需要和相關(guān)技術(shù)負(fù)責(zé)人確定，他們有多少人力和精力投入到樣式的開發(fā)中。
同時(shí)前端本身的技術(shù)水平認(rèn)知也很關(guān)鍵，技術(shù)水平高的可以完成一些復(fù)雜的樣式、交互、動(dòng)效，但一些水平較低的就不行。主要是在移動(dòng)端和可視化的強(qiáng)視覺項(xiàng)目中，前端的水平?jīng)Q定了還原度的上限，設(shè)計(jì)師必須跟著前端的水平范圍輸出，否則前端完全實(shí)現(xiàn)不了的設(shè)計(jì)只能變成飛機(jī)稿。
如果前期對技術(shù)一無所知，就盡量在一些復(fù)雜的設(shè)計(jì)場景中多和前端溝通，確定設(shè)計(jì)方案的可行性，隨著經(jīng)驗(yàn)的積累你就慢慢可以知道相關(guān)技術(shù)的邊界在哪里。
以上三個(gè)要素的分析，是對全局狀況的認(rèn)識(shí)，會(huì)對后續(xù)實(shí)踐產(chǎn)生重要的影響，成為很多決策的依據(jù)。在一個(gè)團(tuán)隊(duì)中協(xié)作的時(shí)間越久，那么完成前期分析的過程也就越短越容易。
共識(shí)建立，就是設(shè)計(jì)師要和前端開發(fā)，以及產(chǎn)品、測試等相關(guān)成員共同確立設(shè)計(jì)和落地的要求，對最終的產(chǎn)出結(jié)果建立相同的目標(biāo)和預(yù)期，
要建立共識(shí)就需要通過會(huì)議或者溝通，來解決以下幾個(gè)議題：
設(shè)計(jì)做到什么程度
設(shè)計(jì)和前端的對接方式
資源管理和命名標(biāo)準(zhǔn)
開發(fā)順序和檢查方式
2.1 設(shè)計(jì)做到什么程度
前面說過設(shè)計(jì)要分析設(shè)計(jì)的權(quán)重，還要結(jié)合項(xiàng)目的排期做進(jìn)一步的調(diào)整，單這些想法僅僅是你自己的結(jié)論，不代表其他人知道并且認(rèn)可。所以必須要在會(huì)上進(jìn)行溝通，確定本次項(xiàng)目要實(shí)現(xiàn)的標(biāo)準(zhǔn)是什么樣的。
光靠口述是說不清的，所以需要找到相應(yīng)的圖例或線上案例，來解釋要實(shí)現(xiàn)的設(shè)計(jì)水平。復(fù)雜的視覺項(xiàng)目還要和開發(fā)確定應(yīng)用的技術(shù)類型、設(shè)計(jì)的邊界。之所以還要在會(huì)上再提一次，是因?yàn)樾枰谡降沫h(huán)境中告知，避免只有設(shè)計(jì)和技術(shù)決定了，但是老板、產(chǎn)品并不清楚，認(rèn)為設(shè)計(jì)師的方案是在劃水。
同時(shí)，還要在會(huì)上拋出一個(gè)關(guān)鍵的問題 —— 前端打算把還原度做到什么程度？
這個(gè)一定要問，也一定也要讓負(fù)責(zé)視覺部分的前端自己來回答，因?yàn)樵谶@種公開場合下他很難真的說出 “項(xiàng)目時(shí)間很趕，視覺隨便做做能用就行” 這樣的話來。可能會(huì)有其它理由說自己的任務(wù)很重，留給還樣式的時(shí)間可能不夠，但這種不明確就意味著有商量的空間，需要趁熱打鐵讓他們愿意盡可能配合設(shè)計(jì)的工作實(shí)現(xiàn)更好的還原度。
主要的工作要由設(shè)計(jì)主導(dǎo)，這個(gè)后面會(huì)提。但是，如果前端本身任務(wù)就不重，那他就沒有理由不對還原度負(fù)責(zé)，所以提前確認(rèn)像素級(jí)的還原度標(biāo)準(zhǔn)是天經(jīng)地義的。
只要會(huì)上給出承諾，后面就有追責(zé)和背鍋的條件，所以與其留到后面相互扯皮，不如從初期就明確責(zé)任的歸屬。
2.2 設(shè)計(jì)和前端的對接方式
設(shè)計(jì)師完成設(shè)計(jì)評(píng)審后要和前端進(jìn)行對接，交付設(shè)計(jì)的產(chǎn)出物，既然要交付當(dāng)然就有交付的方法。在新的項(xiàng)目和團(tuán)隊(duì)中，這個(gè)交付的方式也要提前確認(rèn)。主要交付內(nèi)容包含規(guī)范、設(shè)計(jì)稿、演示、標(biāo)注、切圖等。
在這方面，我的建議是用越少的工具輔助設(shè)計(jì)的交付越好，因?yàn)楣ぞ咴蕉啵S護(hù)的成本就越大，對效率的影響也越大。比如有的項(xiàng)目設(shè)計(jì)用 Sketch，標(biāo)注切圖用藍(lán)湖，規(guī)范文檔用飛書，還要用網(wǎng)盤查看演示視頻等，只會(huì)讓項(xiàng)目變得異常的復(fù)雜。
所以，我始終建議設(shè)計(jì)師自己要優(yōu)化工作流，最理想的做法就是用云端的設(shè)計(jì)軟件如即時(shí)、Figma等來實(shí)現(xiàn)界面、交互、規(guī)范、演示、標(biāo)注和切圖的集合。
如果前端對這些工具不熟悉，就需要提供對應(yīng)的說明和上手使用的簡單培訓(xùn)。部分前端可能會(huì)因?yàn)槁窂揭蕾嚲芙^使用新工具，指定像素大廚、藍(lán)湖、語雀等，就需要你去總結(jié)優(yōu)缺點(diǎn)來說服他們了。
當(dāng)然，這個(gè)前提是你對為什么這么做有充分的理解，也能給出讓人信服的理由。如果你自己都想不明白，無法說服開發(fā)，就根據(jù)他們的習(xí)慣來做，避免讓前端有無條件得犧牲自己來適應(yīng)你的感受，這會(huì)讓其它的工作變得更難推進(jìn)。
2.3 資源管理和命名標(biāo)準(zhǔn)
這一步，則是和前端同步項(xiàng)目中的各類文件保存的方法，頁面展示的邏輯，以及便于檢索流通的各類文件、圖層的命名標(biāo)準(zhǔn)。
這和上一步的對接模式緊密關(guān)聯(lián)，一個(gè)完整的項(xiàng)目必然包含各類文件和層級(jí)關(guān)系，比如移動(dòng)端、WEB端，不同的版本，歷史文件，以及在畫布中頁面的排序方式。需要設(shè)計(jì)師提前確定好標(biāo)準(zhǔn)，讓開發(fā)可以在你搭建的體系下輕松的找到指定的文件。
另外，命名也是需要被重點(diǎn)確認(rèn)的標(biāo)準(zhǔn)，因?yàn)檫@同樣涉及到后續(xù)協(xié)作的效率。命名雖然包含資源管理中的文件夾和文件，但那些只要你結(jié)構(gòu)定好了，命名不亂寫都不會(huì)出錯(cuò)。主要要關(guān)注的是設(shè)計(jì)文件內(nèi)畫板、切圖文件、Token 的命名。
要切記，標(biāo)準(zhǔn)的命名不是網(wǎng)上去找那些寫給設(shè)計(jì)師看的英文切圖命名詞匯大全，而是得同步開發(fā)的命名習(xí)慣，因?yàn)?9%的情況不管你怎么命開發(fā)拿到切圖的第一件事就是根據(jù)自己的習(xí)慣重命一遍。所以很多設(shè)計(jì)師費(fèi)心費(fèi)力整出來的命名僅僅是自我感動(dòng)而已，對實(shí)際交付沒有任何幫助。 （命名規(guī)范的系列文章可以去超人的電話亭查看）
命名的價(jià)值是為了后期的檢索，隨著項(xiàng)目的畫布、文件、切圖數(shù)量膨脹而價(jià)值越大，所以項(xiàng)目初期很難感受到命名的價(jià)值，但隨著項(xiàng)目的推進(jìn)它能帶來的負(fù)面影響就越來越大，所以盡量花一點(diǎn)點(diǎn)時(shí)間在前期進(jìn)行標(biāo)準(zhǔn)化，就可以帶來成倍的收益。
2.4 開發(fā)順序和檢查方式
開發(fā)順序就是前端完成頁面樣式開發(fā)的過程順序，而檢查方式就是如何對每個(gè)開發(fā)完成的節(jié)點(diǎn)進(jìn)行檢查的過程。
想必有經(jīng)驗(yàn)的同學(xué)也能看出這是敏捷的快速迭代并檢驗(yàn)的流程思路。但畢竟樣式開發(fā)只是整個(gè)開發(fā)流程中的一環(huán)，不可能依照完整的敏捷流程，所以必須要要做簡化。（敏捷的系列文章可以去超人的電話亭查看）
我的建議是先把開發(fā)的模塊全部羅列出來并安排順序，每個(gè)模塊作為一個(gè)任務(wù)（Sprint）并有相關(guān)的開發(fā)負(fù)責(zé)人和驗(yàn)收人（設(shè)計(jì)，ProductOwner）。每個(gè)任務(wù)都要分配對應(yīng)的完成標(biāo)準(zhǔn)（Story），即負(fù)責(zé)人自己說這個(gè)模塊要實(shí)現(xiàn)什么目標(biāo)以及還原到哪個(gè)程度。
這里的任務(wù)模塊并不是只跟著設(shè)計(jì)的進(jìn)度或設(shè)計(jì)稿的模塊來列，而是要包含所有和樣式相關(guān)的工作內(nèi)容，比如引入第三方圖表庫并搭建基礎(chǔ)圖表模塊，實(shí)現(xiàn)線上 Fonticon 文件引用，項(xiàng)目基礎(chǔ)規(guī)范樣式創(chuàng)建等等……
每件任務(wù)都應(yīng)該是可以被檢驗(yàn)的，所以還要確定檢驗(yàn)的方式。前端的開發(fā)很多時(shí)候是本地編寫，想要查看寫好的部分就需要他們將完成的代碼進(jìn)行服務(wù)器（云端或內(nèi)網(wǎng)）部署，再提供給你訪問網(wǎng)址。當(dāng)然，也可以用其它的方法實(shí)現(xiàn)，如直接發(fā)文件給你，搭建公共的虛擬機(jī)，或者干脆你到他電腦上看，直接做檢查。使用哪種方式不重要，重要的是你能在對應(yīng)節(jié)點(diǎn)對開發(fā)的內(nèi)容做出檢查即可。
共識(shí)之所以重要，就是要避免設(shè)計(jì)做設(shè)計(jì)的，開發(fā)做開發(fā)的，互不過問，互不干涉，互不擔(dān)責(zé)的孤立狀態(tài)。
通過建立共同的目標(biāo)和行事準(zhǔn)則，為后續(xù)更緊密順暢的協(xié)作和溝通打下基礎(chǔ)。
以上四點(diǎn)就是共識(shí)建立的過程，需要通過會(huì)議的形式來進(jìn)行交流和確定。
而上面提到的問題只有在團(tuán)隊(duì)第一次合作中會(huì)耗費(fèi)比較多的精力，只要走通一次流程，就可以慢慢形成標(biāo)準(zhǔn)化。如對接方式、資源管理、命名規(guī)范、任務(wù)檢查的方式，都是在后續(xù)項(xiàng)目迭代中可以沿用的，所以不用擔(dān)心每次項(xiàng)目迭代都要耗費(fèi)大量的精力搭建共識(shí)。
規(guī)范的整理即項(xiàng)目設(shè)計(jì)相關(guān)規(guī)范的制定和統(tǒng)一過程，很多人以為它僅僅是設(shè)計(jì)師自己決定就可以的，實(shí)際上它是需要前端深度參與的。
因?yàn)橐?guī)范是整個(gè)項(xiàng)目的視覺引擎，所有專業(yè)項(xiàng)目的界面都是圍繞規(guī)范延伸而出的，在設(shè)計(jì)軟件中規(guī)范文件就是外部引用的樣式文件，而在網(wǎng)頁開發(fā)中規(guī)范就是主要的 CSS 樣式文件，其它端也有自己的樣式文件。設(shè)計(jì)規(guī)范文件和開發(fā)的規(guī)范文件內(nèi)樣式數(shù)值越一致，還原度的結(jié)實(shí)現(xiàn)水平越高。
再規(guī)范整理階段，主要要完成的工作，包含下面這些：
確認(rèn)前端框架
規(guī)范架構(gòu)治理
同步基礎(chǔ)樣式
3.1 確認(rèn)前端框架
規(guī)范在正式整理之前，是需要先了解前端應(yīng)用了哪些框架的。
因?yàn)榇蠖鄶?shù)項(xiàng)目的前端都不是從零開始寫，而是應(yīng)用了第三方框架的基礎(chǔ)上開發(fā)，比如網(wǎng)頁端用的 AntDesign、Bootstrap，桌面端用的 Electron，可視化項(xiàng)目用的 D3.js。包括一些特定的模塊也有相應(yīng)的開源框架，如圖表的 Echart、Highcharts，或者富文本編輯器用的 Editable等等。
只要用了第三方框架，就等于樣式上直接受限，因?yàn)槌墒斓牡谌娇蚣芏紩?huì)提供一套相對完整的規(guī)范和樣式，可以做小的改動(dòng)，但要大改或不受約束的另外開發(fā)是不可能的了，這在前文也說過。
但這不代表設(shè)計(jì)可以躺平了，因?yàn)榈谌降囊?guī)范雖然做出了范圍限制，但具體的細(xì)節(jié)要素可沒有指定，同時(shí)很多規(guī)范中不能滿足項(xiàng)目實(shí)際需求的地方，就要做調(diào)整或增加新的內(nèi)容。所以，設(shè)計(jì)師一定要熟悉前端涉及到樣式的這些框架內(nèi)容，并基于這個(gè)基礎(chǔ)完成設(shè)計(jì)和創(chuàng)建項(xiàng)目專屬的規(guī)范。
3.2 規(guī)范架構(gòu)治理
這是一個(gè)比較復(fù)雜的話題，也是很依賴經(jīng)驗(yàn)的東西，架構(gòu)并不是只有前端開發(fā)獨(dú)有，隨著設(shè)計(jì)軟件功能功能的增長（主要是Figma），對于樣式管控的方法就更復(fù)雜，更多樣化。
其中，比較復(fù)雜的就是基于 Design Token 實(shí)現(xiàn)的樣式管理模式，包括組件切換狀態(tài)和樣式，整套設(shè)計(jì)文件的主題變更等應(yīng)用。
Token 的指定雖然看起來和命名規(guī)則很類似，但它不僅僅只是命名規(guī)則，是需要由開發(fā)主導(dǎo)的一種變量管理系統(tǒng)。最常見的應(yīng)用場景就是用 Token 來管理色彩。
騰訊文檔顏色變量表 網(wǎng)上有很多關(guān)于如何使用軟件色彩樣式命名的方式來實(shí)現(xiàn) Token 應(yīng)用的案例，但隨著 Figma 的 Variables 功能的上線，新的應(yīng)用方式已經(jīng)改寫。同時(shí)，Variables 可以實(shí)現(xiàn)除了色彩以外的更多屬性的更改，從而讓 Token 的應(yīng)用范圍在設(shè)計(jì)軟件中進(jìn)一步擴(kuò)大（國產(chǎn)軟件跟上也勢在必行）。
所以，規(guī)范架構(gòu)治理的意思，就是在確定 Token 規(guī)則的基礎(chǔ)上，把它正確應(yīng)用在軟件規(guī)范的實(shí)現(xiàn)中，并且這個(gè)實(shí)現(xiàn)的邏輯能和開發(fā)落地的邏輯同步，保證設(shè)計(jì)和研發(fā)的一致。
這需要設(shè)計(jì)師在制訂規(guī)范前也有大量的溝通和交流，具體應(yīng)用方式會(huì)在以后的分享中說明，已經(jīng)有使用經(jīng)驗(yàn)的同學(xué)只要記得這是在規(guī)范階段要溝通并確定的工作之一即可。
3.3 同步基礎(chǔ)樣式
設(shè)計(jì)規(guī)范中包含的基礎(chǔ)樣式，有色彩、字體、投影、模糊、遮罩等，還有一些非常基礎(chǔ)的標(biāo)準(zhǔn)控件如按鈕、滑塊、輸入框等等。
只要設(shè)計(jì)師規(guī)范給的及時(shí)，包含了這些內(nèi)容，那么樣式開發(fā)中必然要先搭建這些樣式的屬性和參數(shù)。這些內(nèi)容的校對要在開發(fā)搭建完成之后就進(jìn)行，也就是前面開發(fā)順序和檢查中的其中一個(gè)重要節(jié)點(diǎn)。
有一定經(jīng)驗(yàn)的同學(xué)可能會(huì)有疑問，沒有已經(jīng)實(shí)現(xiàn)的頁面樣式，怎么校對規(guī)范的準(zhǔn)確性？是這個(gè)道理沒錯(cuò)，我們不可能直接檢查樣式的代碼，但是開發(fā)可以創(chuàng)建樣式的應(yīng)用實(shí)例供我們校對。比如看 AntD 等站點(diǎn)時(shí)，你會(huì)發(fā)現(xiàn)設(shè)計(jì)規(guī)范解釋中，那些樣式、控件都是實(shí)現(xiàn)出來的而不是截圖。
所以，開發(fā)想要呈現(xiàn)基礎(chǔ)規(guī)范的樣式用于檢查，只要將這色元素置入到一些空白的頁面、背景中，能在客戶端進(jìn)行查看和操作即可，接著就是檢查規(guī)范的還原度，提交相關(guān)的修改 issue，實(shí)現(xiàn)兩端數(shù)值的一致。
以上三步規(guī)范的落實(shí)，是加快后續(xù)效率最關(guān)鍵的一步，因?yàn)檫€原度問題中 80% 的問題都來源于基礎(chǔ)規(guī)范數(shù)值的偏差，而這些問題積累起來要修改就不再只是修改樣式參數(shù)那么簡單（和前端實(shí)現(xiàn)邏輯有關(guān)），所以到發(fā)版前期修改起來又累又慢。
而規(guī)范的落實(shí)是雙向的，一方面我們要保證開發(fā)能夠在樣式應(yīng)用上和我們保持一致，另一方面，我們在進(jìn)行后續(xù)頁面設(shè)計(jì)中，也要對樣式的應(yīng)用有嚴(yán)格的要求和落實(shí)。
設(shè)計(jì)產(chǎn)出物的交付，是前面共識(shí)階段中需要和前端商議并確定的內(nèi)容。而在這里，我們要分享設(shè)計(jì)交付中需要掌握的具體知識(shí)和行為習(xí)慣。
首先要認(rèn)識(shí)一點(diǎn)，就是設(shè)計(jì)的交付和前端的交付一樣，不應(yīng)該是一次性的，而是要分節(jié)點(diǎn)分批交付。比如前面說的設(shè)計(jì)規(guī)范，就是最早要交付的內(nèi)容之一。然后，我們再根據(jù)前端的排期提前將他們要開發(fā)的模塊頁面交付出去。
這些分批次交付的過程中，需要注意以下的交付事項(xiàng)：
標(biāo)注的交付
切圖的交付
動(dòng)效的交付
4.1 標(biāo)注的交付
自從在線設(shè)計(jì)軟件開始普及以后，我是非常不喜歡在設(shè)計(jì)的交付中使用類 Zeplin 的線上標(biāo)注工具的。因?yàn)橛盟鼈兪巧蟼€(gè)時(shí)代的妥協(xié)產(chǎn)物，憑空多了一套需要維護(hù)的系統(tǒng)，并且導(dǎo)入設(shè)計(jì)后還需要進(jìn)行二次操作，如備注、畫板排列、連線，這都是額外的工作量。
并且，設(shè)計(jì)文件再初期定稿后還做調(diào)整是很普遍的，后續(xù)再增刪頁面，還要同步切圖的內(nèi)容就會(huì)產(chǎn)生極大的壓力。如果團(tuán)隊(duì)還在使用本地設(shè)計(jì)軟件，那么只能繼續(xù)使用 Zeplin、藍(lán)湖、Coding 等工具。
這里重點(diǎn)要討論的是如何在云設(shè)計(jì)軟件中輸出交付文件，很多團(tuán)隊(duì)開發(fā)抗拒他們還想使用標(biāo)注工具的原因，就是因?yàn)樵O(shè)計(jì)師壓根沒有做適合查看標(biāo)注的處理，提交一份亂糟糟的工程源文件的話不會(huì)有任何前端喜歡看這樣的文件。而標(biāo)注工具會(huì)強(qiáng)制你做這些操作，自然看起來更順眼。
想要解決這個(gè)問題，就要讓開發(fā)查看的設(shè)計(jì)源文件中確定標(biāo)準(zhǔn)的、有效的布局形式。
包含側(cè)邊欄Page應(yīng)用，頁面排布，連線說明三個(gè)要素。
Page 就是軟件左上的畫布列表，一個(gè)項(xiàng)目如果頁面多，就一定要用 Page做拆分。而在我們當(dāng)前的場景中，就可以根據(jù)交付的模塊階段劃分，每個(gè)模塊創(chuàng)建一個(gè) Page，這樣開發(fā)在本次項(xiàng)目中只需要查看這個(gè)源文件就可以。
雖然拆分了模塊，但是每個(gè)模塊中包含的頁面數(shù)量可能也不少，除了不同頁面外還包含了不同的狀態(tài)、事件、彈窗等樣式的展示。
所以，我們要做出二次拆分，建議創(chuàng)建 100px 字號(hào)以上的文字作為標(biāo)題，命名和標(biāo)識(shí)這些二級(jí)模塊。然后再在它的下方羅列相關(guān)的頁面。
排列頁面時(shí)，也需要具有一定的邏輯，橫向一般表示不同的頁面，縱向表示同一個(gè)頁面的事件和狀態(tài)。并且橫豎間距盡量保持統(tǒng)一，建議左右不低于 800px，上下不低于200px 的間隔，這樣即不影響后續(xù)添加說明，也不影響前端查看頁面時(shí)被其它頁面干擾。
完成這些操作，可以對一些比較晦澀的跳轉(zhuǎn)和交互做示意，比如用箭頭工具直接畫連線（角度對象到頁面，交互工具實(shí)現(xiàn)不了的內(nèi)容），以及在旁邊創(chuàng)建一個(gè)畫布，專門放相關(guān)的說明備注。關(guān)于備注，我更建議使用能直接觀看到的形式擺放出來，而不是使用評(píng)論功能打點(diǎn)，需要鼠標(biāo)移到上面才看得見。
在前期，這個(gè)交付的文件需要單獨(dú)創(chuàng)建，要從設(shè)計(jì)工程文件中復(fù)制進(jìn)來排列，但只要完成規(guī)范，以及前面一兩個(gè)模塊的整理以后，適應(yīng)了這些布局就可以直接在這個(gè)文件中創(chuàng)建新的 Page 進(jìn)行設(shè)計(jì)，加快進(jìn)度。
4.2 切圖的交付
很多人會(huì)認(rèn)為即使標(biāo)注解決了，還是應(yīng)該用標(biāo)注工具，原因是他們可以讓開發(fā)導(dǎo)出切圖。這也是一個(gè)非常不合理的操作，因?yàn)榍袌D全部讓開發(fā)自己從頁面中導(dǎo)出往往難以檢查到切圖本身的錯(cuò)誤，并且會(huì)有切圖缺失的問題（類似圖標(biāo)不同的狀態(tài)）。
我一直建議切圖要由設(shè)計(jì)師自己來完成的觀點(diǎn)，即使不由我們完成，也要讓前端有更好更直觀的導(dǎo)出形式。所以，處理的方法可以在界面畫布的側(cè)邊，將這個(gè)頁面相關(guān)的切圖的元素全部羅列出來。
這里面的每個(gè)切圖都應(yīng)該用一個(gè)畫板包裹，導(dǎo)出切圖，就是框選它們后再選擇規(guī)格即可。一方面導(dǎo)出并不復(fù)雜，另一方面這種形式可以幫助設(shè)計(jì)師檢查切圖文件，并做出優(yōu)化和補(bǔ)全。
這里還有個(gè)細(xì)節(jié)，就是切圖中尤其是圖標(biāo)，往往是留在項(xiàng)目最后才統(tǒng)一設(shè)計(jì)。而前期交付中應(yīng)用的圖形可以只是臨時(shí)的替代品或占位符，只要一開始切圖畫布規(guī)格和命名確定過，那么后期再統(tǒng)一導(dǎo)出，就可以非常輕易的替換之前的內(nèi)容。
4.3 動(dòng)效的交付
除了平面的設(shè)計(jì)標(biāo)注，動(dòng)效也是一個(gè)需要進(jìn)行交付的設(shè)計(jì)內(nèi)容。正常的動(dòng)效內(nèi)容是和所在模塊一起提交，如果項(xiàng)目優(yōu)先級(jí)低，也可以留在項(xiàng)目結(jié)尾在一起輸出后交付。
但是，動(dòng)效的交付要保證最后能落地，首先自己要有判斷做的是什么動(dòng)效，是交互動(dòng)效，還是場景動(dòng)畫，以及對動(dòng)效的開發(fā)成本要符合前期分析的項(xiàng)目實(shí)際情況。而不是自己做得特別上頭，然后開發(fā)直接說實(shí)現(xiàn)不了，或者要花的時(shí)間太多沒排期。
在制作復(fù)雜動(dòng)效的過程中，盡量在制作 demo 環(huán)節(jié)和前端做個(gè)簡單的溝通，商議實(shí)現(xiàn)方案的可行性。很多動(dòng)效的做法往往可以在這個(gè)階段就得到優(yōu)化，而不是等到開發(fā)階段再一起愁眉苦臉想怎么實(shí)現(xiàn)出來。
同時(shí)，交付的過程需要提供非常具體的演示和標(biāo)注內(nèi)容，每個(gè)動(dòng)效都要包含下面這些材料：
動(dòng)效演示視頻/Gif
動(dòng)效的切圖文件
動(dòng)效的標(biāo)注內(nèi)容
動(dòng)效的標(biāo)注需要非常具體，要有針對象的時(shí)間、屬性值、緩動(dòng)效果做出準(zhǔn)確的描述。
如果是使用 AE 制作的場景動(dòng)畫，則可以直接使用 Lottie 導(dǎo)出，但是，Lottie 的導(dǎo)出不是萬能的，它存在非常多的限制和BUG，需要設(shè)計(jì)師每次導(dǎo)出后自己用別的軟件檢查導(dǎo)出文件的有效性。
復(fù)雜的動(dòng)效實(shí)現(xiàn)只要標(biāo)注給清楚還原度就高，落實(shí)就容易。真正麻煩的是頁面中大量的微動(dòng)效，比如鼠標(biāo)懸浮的各種動(dòng)畫、氣泡浮層、模態(tài)彈窗的動(dòng)畫，所以還想進(jìn)一步提升開發(fā)和還原度水平的話，就是要對動(dòng)效的內(nèi)容進(jìn)行標(biāo)準(zhǔn)化，如動(dòng)效時(shí)間定義、類型統(tǒng)一、緩動(dòng)統(tǒng)一等等。
具體的內(nèi)容不在這里展開，可以在 TDesign 官網(wǎng)中查看它們對于動(dòng)效規(guī)范定義的模式，這可以極大的改善項(xiàng)目交互反饋的體驗(yàn)，也可以加快制作和開發(fā)的速率。
要有好的還原度就要提供完善的 交付內(nèi)容，并能依據(jù)開發(fā)的查看、使用習(xí)慣建立工作流。
只要項(xiàng)目進(jìn)入到樣式開發(fā)的階段，就代表設(shè)計(jì)和前端的協(xié)作開始建立并推進(jìn)設(shè)計(jì)落地了。這個(gè)過程前面說過我們可以借鑒敏捷的方式來完成。
為了確保設(shè)計(jì)師和前端都能接受這種工作流，在設(shè)計(jì)流程的時(shí)候就一定要注意流程化的要素一定得少，不能讓流程解釋起來費(fèi)勁，執(zhí)行起來也很困難（比如正統(tǒng)敏捷）。
下面分享有關(guān)敏捷推進(jìn)所需的工作，主要包含三個(gè)部分：
看板的創(chuàng)建
每日的“站會(huì)”
問題的修復(fù)
5.1 看板的創(chuàng)建
看板是敏捷最常用的工具，想要在這個(gè)過程中推進(jìn)樣式的開發(fā)，自然也要用上。而基于精簡的原則，這里我要用的看板并不是獨(dú)立創(chuàng)建的看板，而是結(jié)合設(shè)計(jì)還原度檢測 issue 的看板進(jìn)行合并。
在看板工具中創(chuàng)建待開始、進(jìn)行中、待檢查、修復(fù)中、已完成5個(gè)步驟，然后開始在待開始內(nèi)創(chuàng)建相關(guān)的任務(wù)卡片。
這里要注意任務(wù)卡片的創(chuàng)建中，設(shè)計(jì)的任務(wù)和前端的開發(fā)任務(wù)可以共同添加進(jìn)去，因?yàn)槲覀円谶@個(gè)看板中相互查看和跟蹤對方的進(jìn)度。
添加任務(wù)時(shí)，可以用標(biāo)簽或標(biāo)題前綴，來區(qū)分設(shè)計(jì)還是開發(fā)的任務(wù)。這個(gè)創(chuàng)建的過程盡量在前面說到的共識(shí)建立的溝通會(huì)議中進(jìn)行，并對每個(gè)任務(wù)內(nèi)添加實(shí)現(xiàn)的目標(biāo)和水平，以及對應(yīng)的負(fù)責(zé)人。
在任務(wù)開始進(jìn)行時(shí)，則把卡片移動(dòng)到進(jìn)行中狀態(tài)，做完后移入待檢查，任何完成的任務(wù)都需要進(jìn)行檢查，設(shè)計(jì)做完的任務(wù)要讓前端檢查完整性和可行性，而前端做完的則需要讓設(shè)計(jì)進(jìn)行測試和檢查。
檢查完成后的任務(wù)需要移入到修復(fù)狀態(tài)，等修復(fù)完成后再移回檢查，等到這項(xiàng)任務(wù)已經(jīng)完成了，再把任務(wù)移入完成列表中實(shí)現(xiàn)歸檔。設(shè)計(jì)的任務(wù)要由開發(fā)來歸檔，而開發(fā)的任務(wù)要由設(shè)計(jì)來歸檔。
5.2 每日的“站會(huì)”
這里的每日“站會(huì)”打上引號(hào)，是因?yàn)樗恍枰驼y(tǒng)敏捷一樣每天早上在會(huì)議室里過個(gè)10分鐘內(nèi)的站會(huì)（能實(shí)現(xiàn)當(dāng)然最好），可以更靈活的改成別的時(shí)間，或者使用線上的方式也行。
要進(jìn)行一個(gè)相關(guān)人員都參與的簡會(huì)，來相互匯報(bào)目前工作的進(jìn)度，以及中間出現(xiàn)的問題，需要其他人確認(rèn)和幫助的地方。在上文中說過很多需要和開發(fā)溝通校對的步驟，都可以留到這個(gè)時(shí)候進(jìn)行。因?yàn)樗槠膯栴}沒有限制反復(fù)打擾其他人并不是解決問題的方式，所以盡量集中到一起解決。
這個(gè)站會(huì)的時(shí)間需要控制在盡可能短的時(shí)間內(nèi)，如果發(fā)現(xiàn)每日站會(huì)可以交流的東西少，不需要那么頻繁的話，也可以改成兩天一開。
站會(huì)的目的是為了促進(jìn)溝通，前面反復(fù)強(qiáng)調(diào)的優(yōu)秀的還原度需要有效的協(xié)作來支持，沒有站會(huì)來促進(jìn)團(tuán)隊(duì)成員對其他人工作進(jìn)度和質(zhì)量的認(rèn)識(shí)，就很難讓他們實(shí)現(xiàn)更緊密的溝通和協(xié)作。
5.3 問題的修復(fù)
最后一點(diǎn)，就是關(guān)于還原度問題的修復(fù)。因?yàn)榍懊嫖覀円呀?jīng)說過，這個(gè)看板本身和還原度 issue 提交工具是合并的，所以我們可以直接在這里面提交還原度的問題。
所以，當(dāng)一個(gè)開發(fā)任務(wù)進(jìn)入待檢查狀態(tài)時(shí)，設(shè)計(jì)師就可以對已經(jīng)做好的內(nèi)容進(jìn)行檢查，并提交相關(guān)的 issue了。大多數(shù)看板工具都可以添加描述內(nèi)容或下級(jí)任務(wù)，要利用它們來提交相關(guān)的還原度 issue。
要有心理準(zhǔn)備，前面幾個(gè)模塊任務(wù)完成以后產(chǎn)生的問題可能就非常多，可以提交的錯(cuò)誤也很多。這些任務(wù)的修改必然會(huì)占用很多精力時(shí)間，擠壓后續(xù)還沒完成的工作的時(shí)間，前端肯定會(huì)非常反感在這個(gè)階段進(jìn)行樣式的修復(fù)。
所以這需要設(shè)計(jì)師和前端做出充分的溝通，并不是直接說服他接受這種“低效”的模式，而是得讓他明白這么做是更高效合理的。
原因是因?yàn)檫€原度影響最大的不僅僅是規(guī)范部分的實(shí)現(xiàn)，還包括前端對樣式實(shí)現(xiàn)的編寫邏輯。相比大家都知道 CSS 中盒模型，可以用于實(shí)現(xiàn)元素的排版和定位，一個(gè)元素的位置由相關(guān)所有元素的盒模型中的參數(shù)應(yīng)用決定，
比如一個(gè)標(biāo)題欄中標(biāo)題的位置，可以文字基于欄的垂直居中，也可以是欄給內(nèi)間距，或標(biāo)題加外間距（內(nèi)間距也行）。寫法多種多樣，而出現(xiàn)和原稿不一致的原因就是寫法中某些地方出錯(cuò)或者不匹配，而這種錯(cuò)誤往往和習(xí)慣有關(guān)。
越早能檢查到這些習(xí)慣導(dǎo)致的錯(cuò)誤，越可以讓前端注意并進(jìn)行檢查和改進(jìn)。這些調(diào)整沉淀下來，就可以在后續(xù)的推進(jìn)中減少同類問題產(chǎn)生，也就會(huì)讓后續(xù)模塊中的還原度問題越來越少。
所以，前期的修復(fù)是絕對值得投入時(shí)間去完善的，因?yàn)楹竺娴男蕰?huì)越來越高，結(jié)果也越來越可控，與其把炸彈留到結(jié)尾引爆，不如趁早開始排出風(fēng)險(xiǎn)。
當(dāng)絕大多數(shù)任務(wù)都完成以后進(jìn)入正式的測試階段，那么就可以在這個(gè)看板中繼續(xù)添加BUG修復(fù)的卡片，來對結(jié)果進(jìn)行檢查并收尾了。
在敏捷的推進(jìn)過程中，任務(wù)的推動(dòng)是雙方共同投入精力協(xié)作的，任務(wù)的制定、分配、檢查、提交、修復(fù)、站會(huì)都包含了需要交流的部分，所以必然需要通過實(shí)踐去磨合。
想要建立一套有效的系統(tǒng)，就需要實(shí)踐，并且反思和改進(jìn)。所以每當(dāng)我們完成一次完整的項(xiàng)目以后，就需要找時(shí)間和前端開一個(gè)總結(jié)會(huì)議，找出此次項(xiàng)目中存在的問題，并結(jié)合大家的意見如何在后面進(jìn)行改進(jìn)。
比如開會(huì)的時(shí)間，任務(wù)創(chuàng)建和安排的方式，資源管理的方法，測試版本發(fā)布的優(yōu)化等等。而這些討論優(yōu)化的結(jié)果，都可以在下一次項(xiàng)目中進(jìn)行實(shí)踐，檢驗(yàn)它們的有效性。
所有對流程的優(yōu)化和調(diào)整都可以用圖文的形式記錄下來并形成規(guī)范，不僅是用于后期新加入同事的培訓(xùn)，也方便對它進(jìn)行討論和修改。
同時(shí)，這些流程看似非常繁瑣，但面對的項(xiàng)目周期并不是只有一兩天的小迭代，而是起碼超過一周以上或幾個(gè)月的項(xiàng)目，這些工作被分散到這個(gè)跨度中占比就并不高，而它們能產(chǎn)生的效率也注定遠(yuǎn)遠(yuǎn)大于投入的成本。
一定要以發(fā)展的眼光看待這套還原度管理的方法和系統(tǒng)工程，不要因?yàn)榍捌诘膰L試受挫而停止對它的信心和探索。多做總結(jié)和反思，你才能在失敗中成長并實(shí)現(xiàn)目標(biāo)。
結(jié)尾
說實(shí)話關(guān)于還原度所需要做的工作，還有很多想寫的沒寫進(jìn)來，忍住了，否則就太長了。這些工作全部執(zhí)行下來對設(shè)計(jì)師本身的要求是比較高的，因?yàn)槿绻讲粔颍A(chǔ)知識(shí)積累不足和對前端沒任何理解，是無法管控中間涉及的細(xì)節(jié)的。
還有很多同學(xué)可能在這個(gè)問題上還是會(huì)抱怨各種 “團(tuán)隊(duì)不在意設(shè)計(jì)”、“前端永遠(yuǎn)說沒時(shí)間”、“設(shè)計(jì)對項(xiàng)目一點(diǎn)價(jià)值也沒有” 之類的話。這些抱怨的潛臺(tái)詞就是，你需要團(tuán)隊(duì)主動(dòng)給你空間，主動(dòng)配合你工作，這是不可能得。重點(diǎn)不是團(tuán)隊(duì)給你什么樣的設(shè)計(jì)環(huán)境，而是 —— 你想實(shí)現(xiàn)什么樣的設(shè)計(jì)環(huán)境。
只有團(tuán)隊(duì)出現(xiàn)其他各類無法調(diào)和的矛盾時(shí)，比如需求不確定，發(fā)不出工資，內(nèi)部斗爭等，那么設(shè)計(jì)的落地才會(huì)沒有著落。
除此之外，專業(yè)的設(shè)計(jì)師應(yīng)該在能做好自己本職工作的基礎(chǔ)上，去發(fā)揮影響力，逐步建立和前端的共識(shí)，并形成對高水平設(shè)計(jì)產(chǎn)出的追求。羅馬不是一天建成的，但不代表它永遠(yuǎn)建不成，區(qū)別在于你想不想，和有沒有能力。
我一直秉持的想法就是，當(dāng)自己足夠?qū)I(yè)的時(shí)候，環(huán)境硬想擺爛，那它們自己擺自己的，影響不了我。但當(dāng)環(huán)境需要我發(fā)揮專業(yè)性的時(shí)候，那我就要具備足夠的專業(yè)能力和來征服所有對象。
作者：酸梅干超人
鏈接：https://www.zcool.com.cn/article/ZMTU4MDYyMA==.html
來源：站酷
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群，每天會(huì)分享國內(nèi)外的一些優(yōu)秀設(shè)計(jì)，如果有興趣的話，可以進(jìn)入一起成長學(xué)習(xí)，請加藍(lán)小助，微信號(hào):ben_lanlan，報(bào)下信息，藍(lán)小助會(huì)請您入群。歡迎您加入噢～希望得到建議咨詢、商務(wù)合作，也請與我們聯(lián)系01063334945
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責(zé)聲明：藍(lán)藍(lán)設(shè)計(jì)尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請及時(shí)與我們?nèi)〉寐?lián)系，我們立即更正或刪除。
藍(lán)藍(lán)設(shè)計(jì)( ssll180.com )是一家專注而深入的界面設(shè)計(jì)公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)、UI設(shè)計(jì)公司、界面設(shè)計(jì)公司、UI設(shè)計(jì)服務(wù)公司、數(shù)據(jù)可視化設(shè)計(jì)公司、UI交互設(shè)計(jì)公司、高端網(wǎng)站設(shè)計(jì)公司、UI咨詢、用戶體驗(yàn)公司、軟件界面設(shè)計(jì)公司
藍(lán)藍(lán)設(shè)計(jì)的小編 http://ssll180.com