視覺設(shè)計師怎樣讓前端100%實現(xiàn)設(shè)計效果?

一、效果實現(xiàn)難度 設(shè)計師天馬行空的大腦會迸發(fā)出各種奇思妙想，例如一個看起來酷炫的動畫，結(jié)果跑到工程師面前，工程師很犯難的表示做不了，或者硬著頭皮做到最后也發(fā)現(xiàn)不盡人意。所以前期對實現(xiàn)難度的基本溝通是必要的，很多時候，酷炫的效果并不是拯救設(shè)計的唯一方式，反而，大多時候我更傾向于樸素的手法來解決問題?？犰诺男Ч皇潜匾模清\上添花的，需量力而行。

二、明確的規(guī)范 任何時候不要小看規(guī)范的作用力，剛?cè)胄械哪骋欢螘r間我經(jīng)常喜歡不做規(guī)范，直接搬個凳子到開發(fā)工程師面前指指點點（好在和開發(fā)關(guān)系比較好，游戲好基友，不然我可能都沒命活到今天），看似非常具有效率，但這種效率僅僅適合單槍匹馬戰(zhàn)斗時，涉及到團隊協(xié)作，幾個設(shè)計師面對幾個開發(fā)甚至更多時，規(guī)范的作用力就顯得十足重要。 規(guī)范的編寫盡可能讓開發(fā)少動腦，例如交互原則「Don’t Make Me Think」一樣，不要讓開發(fā)費很多精力在理解規(guī)范，規(guī)范能多傻就多傻。試舉一例，如下：
見過太多設(shè)計師如右圖一樣標注規(guī)范，事實上，圖片的實際畫布尺寸是左側(cè)藍色框的范圍，所以在標注規(guī)范時一定要如左圖所示，否則開發(fā)還要量多一遍你的空白像素。
包括標注出不同情況（dock欄）時的不同規(guī)范，或在備注欄告知開發(fā)排列方法（例如控制邊距，橫向平均排列）

三、語言轉(zhuǎn)化 將視覺語言轉(zhuǎn)化為開發(fā)語言，每個人對形體的觀感是不同的，設(shè)計師很多接受過美術(shù)方面訓(xùn)練，對造型的比例有一定認知，可以感覺細微的視覺差異，但不意味著你可以要求開發(fā)同學(xué)也如你一樣，過去的工作經(jīng)驗中，也經(jīng)常聽到如下對話：

「天吶，這兩個圖完全不同啊，你怎么能做成這個樣子」
「??？不同么？我看上去差不多啊」
「你瞎啊，這么明顯的不同你都看不出來」
「。。?！?/span>

所以需要轉(zhuǎn)化語言讓開發(fā)能夠輕易的明白，將抽象的感性內(nèi)容轉(zhuǎn)化為可量化的理性數(shù)字。例如動畫運動軌跡，靠開發(fā)觀察運動軌跡幾乎是不可能的，所以需要轉(zhuǎn)化你的語言讓開發(fā)更容易明白。

四、反復(fù)驗收 對每一個節(jié)點都要進行驗收，多次驗收可以讓你及時了解最新動態(tài)，如出現(xiàn)問題也可以及時的做出修改反饋。即使做到以上幾點，開發(fā)也不是能完全理解你想表達，所以需要非常頻繁的同步信息，而不是做的七七八八了，突然發(fā)現(xiàn)這里有問題，那個時候再來改，時間可能已經(jīng)不夠用了。另外，只有做到以上幾點，你才能理直氣壯的和開發(fā)定責(zé)，否則，哪有臉找別人理論吶。 綜上所述，相信你已經(jīng)足夠明白「跟進還原能力」對一個設(shè)計師的重要性，會做「好看」的設(shè)計師這個世界上大把，dribbble上一抓一大把，但能做好商業(yè)設(shè)計，所需的能力遠遠不止于此，一個不具備將事情由始至終合格完成的設(shè)計師在任何時候都是不及格的，從結(jié)果導(dǎo)向上來看，甚至不如一個「你認為比你低級很多」的設(shè)計師，擁有全方位的素質(zhì)才是「稀缺物種」。 這個問題其實有兩個角色和一個目標：
角色1：視覺設(shè)計師
角色2：前端工程師（想必 Web 前端和 iOS, Android 開發(fā)也都在這了）
目標：100% 還原設(shè)計效果 先來看看這個目標設(shè)定是否靠譜，而要看這目標靠不靠譜，還需要看依賴條件了。如果前端工程師水平不足，你除了讓他提升水平外，想100%還原設(shè)計效果也是白說。所以以下我所說的默認是前端工程師實現(xiàn)能力足夠。若能力足夠，還無法實現(xiàn)設(shè)計效果，可能有以下幾個原因： 設(shè)計不合理，考慮不周密。
時間緊迫或不愿意實現(xiàn)
溝通不到位。

設(shè)計不合理 前面提到的角色1就是視覺設(shè)計師，普遍來說，視覺設(shè)計師下是利用視覺符號來傳遞各種信息的設(shè)計的，而縱觀各類崗位職責(zé)，并沒有嚴格要求視覺設(shè)計師擁有 HTML/CSS/Javascript 技能。事實上大部分的視覺設(shè)計師不懂技術(shù)，像 CSS 盒子模型，F(xiàn)loat，絕對定位相對定位，if..else..then 這些也不懂。這是客觀情況，如果視覺設(shè)計師有這些知識技能自然是可以避免一些問題，但術(shù)業(yè)有專攻，無法強迫。 除了提高自己的知識水平，還可以有一些其他的方式： 設(shè)計評審。在還是交互原型時，就邀請技術(shù)經(jīng)理一起 Reveiw。 曾經(jīng)我司在某銀行實施項目時，做的是 Hybrid 應(yīng)用，也就是 Web 和 Native 混合型的，用了一些框架，也有一些技術(shù)上的限制。但交互和視覺設(shè)計的過程中，并未與技術(shù)經(jīng)理溝通，直到視覺做完后，交付給 H5 工程師時，工程師就傻眼了，這幫設(shè)計瞎搞，這實現(xiàn)不了啊…而后只有重新設(shè)計了，進度也被拖慢了很多。 在交互階段就把技術(shù)人員引進來，會有極大的幫助，同時也利于技術(shù)人員確定技術(shù)選型。

時間緊迫或者不愿意實現(xiàn) 所有的項目和產(chǎn)品都會有開發(fā)計劃，雖然很多情況下計劃總是趕不上變化（需求變更啦，上線時間提前啦），但是大體上每個開發(fā)人員對自己所負責(zé)的部分有自己的優(yōu)先級排序。在我所做的產(chǎn)品和項目中，研發(fā)人員大部分情況下的關(guān)注度是：功能實現(xiàn)>效果實現(xiàn)。這個時候其實更重要的是統(tǒng)一對優(yōu)先級的認識。 如果開發(fā)計劃已指定，同時研發(fā)人員也認可交付時間點，那么在開發(fā)任務(wù)內(nèi)的計劃，視覺設(shè)計師撒潑打滾躺地賣萌，曉之以情動之以理，怎么打動前端工程師，網(wǎng)上也有很多同仁的經(jīng)驗技巧，總是能實現(xiàn)的。 設(shè)計的實現(xiàn)，不僅僅是前端工程師的工作，有時候也需要后臺的配合，想要實現(xiàn)，那就得給咱們工程師時間，不能又想馬兒跑，又不給馬吃草吧？ 同時設(shè)計和程序是息息相關(guān)的，有時候并不是不想實現(xiàn)這樣的設(shè)計，而是因為確實有一些問題，比如說在 Digg 還流行的那段時間，他們的首席設(shè)計師和首席程序員之間的爭論： 丹尼爾·博卡（Daniel Burka）（Digg 的首席設(shè)計師）和喬·思湯普（Digg 首席程序員）之間有一場非常著名的爭論。那個時候丹尼爾想要在 Digg 的「按鈕」上做出一次設(shè)計上的變動。對于丹尼爾來說，這個變動就是微小的一點；但對于首席程序員喬來說，即便設(shè)計上微小的一點變動都會對整個網(wǎng)站的響應(yīng)時間產(chǎn)生巨大的影響。為了適應(yīng)這一點點的變化 Digg 網(wǎng)站必須提升自己的處理效率，改善服務(wù)器的內(nèi)部架構(gòu)：http://tech2ipo.com 所以在我們團隊做一些設(shè)計咨詢項目時，會把技術(shù)人員引入進來。

溝通不到位 切好圖，標注好。 用對方聽得懂的語言。前面說了很多視覺設(shè)計師并沒有技術(shù)基礎(chǔ)，但是理解一些術(shù)語對于和程序員溝通是非常有效的。比如說動效里有很多，你說了半天「從這里到那里」，「速度稍微慢一點」，可能也很難做到你想要的那種效果。但是如果你說，這個動畫的 Tension（拉力） 數(shù)值，F(xiàn)riction（摩擦力）數(shù)值，cubic-bezier函數(shù)是多少，那程序人員相對會比較好理解。 可以參考這個網(wǎng)站，找到很多動畫效果的名稱： Form Follows Function 不斷跟進。設(shè)計給完圖之后不能不聞不問，等到代碼寫完后才傲嬌地說：“哎呀，沒按我的設(shè)計效果來”。確保設(shè)計效果的實現(xiàn)也是設(shè)計人員的職責(zé)，建立 Bug 文檔，貼圖對比，描述清楚，因為并不是每個人都是像素眼，對美的認識也不一樣。

總結(jié)一下 過程：溝通—>設(shè)計評審—>交付設(shè)計圖—>再次溝通—> 跟進追蹤 每一份工作都不是看上去的那么簡單，設(shè)計不僅僅只是個畫圖把東西變得好看些的人，程序員也不只是寫寫代碼（在我們團隊的一些項目中，很多設(shè)計不合理的地方都是程序員指出來的），最重要的相互間的溝通和理解。 其實我建議能修改下這個問題的說辭，什么叫「是怎樣讓前端工程師100%實現(xiàn)設(shè)計效果的呢」，這并不只是前端工程師的工作，不是「怎么樣讓人去實現(xiàn)的」，而是「怎么配合」的問題。