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