視覺設計師是怎樣讓前端工程師 100% 實現設計效果的？
發現自己設計的app和網頁，在前端顯示總是和設計效果偏差很遠。和工程師溝通卻說不可能100%呈現的，但實際上80%都沒達到。想了解下，各位設計界的前輩是怎麼做的，才能讓前端顯示盡量和設計效果一致。
專欄里正好寫到這個話題，總結起來就是：1）做好標註 2）準備好素材 3）和工程師互相信任達成共識。
下面先說如何 做一份讓工程師淚流滿面的標註
在搬著小板凳坐工程師 buddy 旁邊送果汁送零食的日子裡，我受 Google Material Design 的啟發，折騰出一套自認提高雙方溝通效率的標註規則，心情挺好還為此做了模板，最下面有源文件的下載地址。
是的我曾經也很寄希望於 Zeplin，參與第一批內測後就寫了長長的自帶說明配圖的郵件給他們，期待 1.0 的發布，那就可以解決我這篇文章里寫的所有問題了，以下內容大家就不用看啦。論偷懶工具的重要性啊盆友們……想起昨晚看見 FB 新玩出來的 sketch 插件，用 HTML+CSS 實現的動態布局。
================================================
為什麼傳統的標註方法讓人難受？
沒錯，Markman 是傳說中的標註神器，看起來也確實方便快捷，但是當一個頁面中，要同時標註間距、大小、顏色和字型大小時，過多的信息一齊扔給工程師，就會讓人有些抓狂。比如這樣：
這裡的標註雖然都有清晰的箭頭指示，但卻並不具有視覺邏輯，或者說呈現出來的視覺邏輯並不符合開發邏輯。工程師在搭建一個頁面的時候，會先去架構布局，一塊內容一塊內容劃分好，接著填充進內容，最後來修改視覺的樣式。那麼我們也應該按照順序，先告訴人家每個模塊的間距啦大小啦，再告訴人家用什麼字體和顏色，也就是先有布局標註，再有樣式標註。
用2個頁面解釋布局，再用1個頁面解釋樣式
這就是我的做法，視覺稿完成後，每一個頁面拿出來放在左邊，再用三個畫板來說明它。
- 橫向布局：解釋元素左右的外間距、內間距和橫向寬度。（這裡要考慮到針對不同寬度屏幕的適配，標註是給固定值還是百分比）
- 縱向布局：解釋元素的上下間距和高度。（有時要確保頁面里最重要的信息——比如一個 CFA btn——在不同屏幕大小中是否都出現在了首屏，判斷標註是向上定位還是向下定位 ）
- 視覺樣式：字體、字型大小、行高、顏色、透明度、圓角。
標註信息分類之後，我還會給標註本身設置共享樣式：塊面通常用藍色的遮罩，區別不同百分比時則用紅黃綠的遮罩，數字間距用紅底白字，視覺樣式則用藍底白字，這樣的好處是：對與設計師，可以快捷修改所有標註樣式；對於工程師，快速建立對這套標註視覺語言的認知，明白不同顏色所代表的信息屬性，更方便的找到他所需要的信息。
單獨拎出可復用的組件，統一標註
設計實現之前，就和工程師們一起統一一套樣式規範，除了常見的顏色和字體之外，我還會把通用的 UI 組件拿出來，一半是針對系統原生控制項的樣式定製（alert/toast/radio btn/switch…），一半則是完全自定義的 UI 組件（產品自己的 UI kit）可以是任何會高頻復用的產品功能性的東西，比如這裡的 SKU 選擇器和按鈕。
在項目進程中，我甚至會和工程師們溝通好，然後在每個組件旁寫上這個組件是誰正在實現或已經實現，附在項目共享文件或者郵件里，避免重複勞動。
統一標註的好處不僅是我們自己在後續的設計中可以復用和遵守， 對於 web/iOS/Andriod 的工程師而言，也能提高代碼效率同時保持不同平台最終效果的統一，後續迭代的時候也不會出現莫名其妙的樣式和代碼。如果遇到產品的大版本更新，也正好趁此機會和工程師們一起好好梳理一遍現有的樣式，清除掉不再使用的樣式，指定好新的層級。
DOs DON』Ts
- 始終遵循，視覺邏輯符合工程師的開發邏輯。
- 合理劃分，再複雜的頁面，用三步也足夠能說清楚，信息不要擠在一起。
- 考慮到頁面在不同屏幕大小下的變化，間距是否固定，比例是否縮放，圖片和按鈕寬度是否自適應。
- 任何細節和要求都寫清楚寫清楚，寫，清，楚，不要指望任何人「意會」你的設計，任何決定都要有據可查。
- 每一個標註本身也要注意對齊方式，更乾淨整潔的標註能讓大家一眼找到所需。
好了，看完之後大概會有人吐槽說有必要麼這樣的標註多浪費時間啊，那麼請去看看@圭多達萊佐這位朋友的樂譜，get it? 就是要追求極致啊（仰天……
- 在做標註的過程中，你會再次仔細審視自己的設計，總會發現之前被忽略/沒考慮周全的細節，比如間距字型大小顏色是否遵守了統一的規則，比如不同屏幕大小如何適配。
- 耍聰明會偷懶的話，shared style 設置好，插件快捷鍵背好，能復用的樣式提煉出來，你便會發現，雖然投入到標註的時間增加了30%，但是和工程師後期反覆溝通的時間減少了80%。
- 他們如果第一次拿 demo 給你看，你還會驚喜的發現有很高的視覺還原度，個別小細節微微調整就好了。大家都討厭改改改，一次通過多有成就感呢。
最後，這次模板是我自己的一個 redesign concept， 基於foundmyanimal.com，（一家 base 在 Brooklyn 的工作室，手工製作非常有愛的銘牌、項圈等動物飾品）圖片素材全部源自其網站和 Instagram，不得轉載。
至於我的源文件，大家隨便用，I don』t give a fuck.
- 去 Dribbble?—?看我的完整設計稿
- 去雲盤?—?下載 measurement_template.Sketch
當然，這是一套還不夠嚴謹不夠科學的自創標註，設計師盆友們，特別是工程師盆友們！覺得有任何值得改進的地方請隨時跟我討論~ help me improve : P
Happy designing~
匡
================================================
這是我自己最常用的兩個 Sketch 插件：
- Sketch Measure—?目前最好用的標註插件
- Sketch Style Inventory Master?—?主打功能是幫你自動生成設計稿中的 style guide，但最好用的卻是可以智能選擇頁面中統一樣式的文本和圖形
記得在 Github 上給作者小星星喲~
這是一個經常被討論的問題，「創新設計能力 跟進還原能力」。這是一個商業設計師而非藝術家的兩重技能要素，同樣重要，缺一不可，甚至在很多時候後者的作用力會更大，畢竟我們還是要做一個落地的商業產品而不是意淫的概念稿。這是任何一個在職的商業設計師能力模型之內不能被忽視的要素之一。
1：效果實現難度
設計師天馬行空的大腦會迸發出各種奇思妙想，例如一個看起來酷炫的動畫，結果跑到工程師面前，工程師很犯難的表示做不了，或者硬著頭皮做到最後也發現不盡人意。所以前期對實現難度的基本溝通是必要的，很多時候，酷炫的效果並不是拯救設計的唯一方式，反而，大多時候我更傾向於樸素的手法來解決問題。酷炫的效果往往不是必要的，而是錦上添花的，需量力而行。
2：明確的規範
任何時候不要小看規範的作用力，剛入行的某一段時間我經常喜歡不做規範，直接搬個凳子到開發工程師面前指指點點（好在和開發關係比較好，遊戲好基友，不然我可能都沒命活到今天），看似非常具有效率，但這種效率僅僅適合單槍匹馬戰鬥時，涉及到團隊協作，幾個設計師面對幾個開發甚至更多時，規範的作用力就顯得十足重要。
規範的編寫儘可能讓開發少動腦，例如交互原則「Don』t Make Me Think」一樣，不要讓開發費很多精力在理解規範，規範能多傻就多傻。試舉一例，如下：
見過太多設計師如右圖一樣標註規範，事實上，圖片的實際畫布尺寸是左側藍色框的範圍，所以在標註規範時一定要如左圖所示，否則開發還要量多一遍你的空白像素。
包括標註出不同情況（dock欄）時的不同規範，或在備註欄告知開發排列方法（例如控制邊距，橫向平均排列）
3：語言轉化
將視覺語言轉化為開發語言，每個人對形體的觀感是不同的，設計師很多接受過美術方面訓練，對造型的比例有一定認知，可以感覺細微的視覺差異，但不意味著你可以要求開發同學也如你一樣，過去的工作經驗中，也經常聽到如下對話：
「天吶，這兩個圖完全不同啊，你怎麼能做成這個樣子」
「啊？不同么？我看上去差不多啊」
「你瞎啊，這麼明顯的不同你都看不出來」
「。。。」
所以需要轉化語言讓開發能夠輕易的明白，將抽象的感性內容轉化為可量化的理性數字。例如動畫運動軌跡，靠開發觀察運動軌跡幾乎是不可能的，所以需要轉化你的語言讓開發更容易明白。
4：反覆驗收
對每一個節點都要進行驗收，多次驗收可以讓你及時了解最新動態，如出現問題也可以及時的做出修改反饋。即使做到以上幾點，開發也不是能完全理解你想表達，所以需要非常頻繁的同步信息，而不是做的七七八八了，突然發現這裡有問題，那個時候再來改，時間可能已經不夠用了。另外，只有做到以上幾點，你才能理直氣壯的和開發定責，否則，哪有臉找別人理論吶。
綜上所述，相信你已經足夠明白「跟進還原能力」對一個設計師的重要性，會做「好看」的設計師這個世界上大把，dribbble上一抓一大把，但能做好商業設計，所需的能力遠遠不止於此，一個不具備將事情由始至終合格完成的設計師在任何時候都是不及格的，從結果導向上來看，甚至不如一個「你認為比你低級很多」的設計師，擁有全方位的素質才是「稀缺物種」。
首先，作為一個設計師，尤其是UI設計師，請跟我一起大聲念：必須掌握前端切圖流程！！
這可能意味著你得學會HTML+CSS，或者要長時間和IOS或者安卓開發人員交流他們是怎麼把圖片和文字排進屏幕內的。別老是抱怨你是設計怎麼能去學碼農的東西，設計人員對這些看似高深的源碼有本能的畏懼和厭惡。無論你所在的公司在項目人員配置上如何貼心到位，但如果你自己沒有掌握這些知識點，就不要妄想最後實現環節上能順利收尾，因為你從出發點開始和程序員的認知就不對稱，這些不對稱是矛盾和偏差的根源。
讓我們來舉舉例子：
例如你設計了這麼個樣式，傾斜、層疊，你有沒有在設計的過程中考慮過這麼設計的後果（國內外高能前端請不要加入此列）？你在當前寬度畫布中設計效果似乎還不錯，這註定該是個填滿瀏覽器顯示區域的設計，但是放大後呢？1920寬下怎麼辦，難道得是這個模樣？？
因為在水平線上無法直接延伸平鋪的設計，在前端部分你讓開發人員怎麼幫你填補這兩個區域的空白，你從設計初就不知道在對應設計類型下應該創建的畫布大小（滿屏響應式設計要準備好大小兩種或多種方案），那進入切圖環節我已經能腦補出你和開發人員是怎麼撕逼的盛況了。
再者，假如我們填滿這個設計稿（咳咳，比較粗糙的填上）：
這些沒有內容被紅線框出的背景區域最後怎麼呈現出來？這裡面幾個主要的傾斜圖形上面還疊加了對應內容、圖片、文字，還有前後關係，別指望前端設計人員能輕鬆實現，如果你用一張背景圖填充，那這張背景圖的大小控制得住？載入過程要多久？導出WEB用途格式圖片是選擇「連續」還是「優化」？
再類似這樣的案例：
現在很多小年輕們迷戀追波上大神們做的牛逼的動效，於是設計的時候光靜態稿件不甘心，也來做個AE特效玩玩，壓根沒有考慮IOS或者安卓在實現這樣的效果時，需要哪些運行機制，有沒有這樣的控制項支持，會不會不流暢等等！自己用了一整晚的時間折騰這麼酷炫高大上的動畫，開發這些土鱉居然告訴我不能實現恩？？撕逼ING.........
再普遍點的，是不是每次前端開發完你發現絕大多數元素和字體都不對，沒有對齊，大小加粗等細節沒有注意，但是開發拿設計稿就是沒辦法100%實現的借口的來搪塞你？？
下面就來講重點~~~
==============================重點==================================
1、設計前請審核原型
在原型步驟就想好對應的圖層結構，交互特效，並和開發人員做好交流，是否可以實現，功能的評估一定要細緻，否則會浪費大量的人力成本。還有原型是挺嚴肅一玩意兒，但是大多數團隊或者設計都沒有認識到它們的價值，在這裡不展開原型的細節了，這還可以再寫一個長評，你們懂意思就好拉，畫在紙上的手稿也比沒有強。
下面放我自己平時做的原型：
2、熟悉設計環境規範
無論是WEB還是IOS、安卓、WP等等，都有對應的設計規範文檔，我下面會帖出來。如果連最基礎的設計規範都不知道就開始做設計，那麼你要自己承擔項目拖延和被整個開發組人員問責的後果。在你動手前，請好好的做完功課，並且在每次環境大升級時跟進關注（例如新的iPhone6、6+發布的尺寸變更等）。
前人已經栽好了樹，你需要做的就是在既定框架內完成設計即可。你要牢記自己的設計是基於相應的運行環境的，沒有足夠的能力前，不要有認為這套體系下的設計都很「土」，你是一個要成「大神」的男人，打破限制和規範是你的嗜好和品位。如有以上想法，請對著鏡子里的自己說：Naive（被你們這些可惡的人類發現拼錯了，摔）！
例如WEB設計下，12PX以下的中文字體無法被正常顯示，文本只支持本地客戶端已有字型檔，IOS的TABBAR、TOPBAR等高度是不能被隨意變更任意增減層級等等。這樣的稿子如果被交付，並沒有強有力的邏輯說服別人，只會讓你的團隊感受到你的不專業，增加矛盾隱患。SO，好好看看這些文章：
基礎知識學起來！為設計師量身打造的DPI指南
ios安卓設計標準規範
iPhone APP設計規範/iPad
擦！！突然發現一些收藏不見了~~後面慢慢更
3、制定項目設計規範
這也是提升效率和整體視覺和諧感的重點，你要在大框架下建立小體系，這是你展示自己個性的部分，記得也要用文檔記錄下來，在以後的改版和開發過程中，嚴格遵守規範的參數，減少溝（si）通（bi）成本。
例如：主色色值、按鈕的大小邊框、各文字類型顏色大小、模塊間隔距離等等。
請看這個：@souhlin採集到設計規範(76圖)_花瓣UI 交互設計
4、學會怎麼切圖
我一直認為做完PSD還是SKETCH文件，往開發那邊一扔，任務搞定的想法，是相當不負責任的一種行為。因為設計不合理的部分導致導出切圖的工作變困難，因你的爛攤子，開發效率降低，完全是因為你的失誤，不要抱怨和找任何借口。
比如水平可平鋪的背景是怎麼最優化導出的？安卓適應多屏幕解析度下，點九圖是怎麼進行標記和拉伸的，應該使用什麼工具？需要應用透明背景的圖片知道應該使用什麼格式？你必須設計出自己獨立也能完成切圖工作的設計稿，再要求開發能夠完整實現，而不是讓他們又來找你抱（si）怨（bi）哪裡哪裡是不行的你得重做。
5、一定要有標註說明
標註的作用何其重要，開發人員對於元素的間距和文字大小還有透明元素的參數設置，是沒有耐心一點點查看和檢測的（沒錯，大部分情況會——憑！！感！！覺！！），你不好好把這些製作成文件白紙黑字，那麼這個最重要的還原環節上出差錯的幾率也是最多的，往後修改最困難的。
下面推薦兩軟體：
markman：index.title
pixcook:FancyNode - PxCook
用它們做出詳盡的標註文件，交付開發，最後如果出現偏差，就有證據可以找出是誰的問題了。
6、結果對比調適
開發完成視覺部分內容以後，要開始校對，那麼儘可能給出參照物，參照物是什麼呢？
高保真原型
只有同意平台下可運行的高保證原型可以最直觀對比設計到實現之間有什麼偏差，並以此檢查參數設置上的錯誤，逐個調整。
在這裡強烈推薦——Invision在線原型工具
Free Web Mobile (iOS, Android) Prototyping and UI Mockup Tool
可以製作APP和WEBSITE，並分享遠程連接在手機和別的電腦上預覽，下面放我之前做過一個小項目的實例（最好翻牆訪問比較快）：
傳送門——InVision
或者PSPLAY，這個請訪問官網看詳情，也是可以在移動設備直接查看設計文件的工具，不過更適合設計過程中使用，但不妨結尾的時候做對比
傳送門——Ps Play – 移動設計零阻力
還有就是MAC的童鞋們，使用SKETCH的MIRROR~這就不多做贅述，最近風頭正勁的設計軟體。
傳送門——Bohemian Coding
好了~一下午打了那麼多內容，還有磚要去搬了~~還有很多內容沒空放上來，以後一點點更新，很多疏漏之處，歡迎指正。說了這麼多，就是要告訴所有做UI設計的同行新手們，能正確的分析問題，從自身的知識能力出發來看待問題。我們和程序都是項目的執行人，需要相互間的磨合和協助共同輸出產品，在對方的結果不盡人意時，請先從上面的幾個點力反思，自己有哪些不足，再和對方討論，這樣不但給自己帶來進步，也為團隊節省更多的時間。
請一起為更好的產品努力吧！！
答案很簡單。你不需要做這件事。換句話說，你不需要前端工程師100%實現你的視覺稿。
你需要做的是，如何讓前端工程師實現的效果是最好的。
這兩者有什麼區別呢？舉個例子，有兩份視覺稿。視覺稿A，效果100分，因為一些效果難以實現，實現效果60分。視覺稿B，效果80分，但實現效果也是80分。
那麼，你會怎麼選擇？
如果覺得，我負責視覺，工程師負責實現。工程師能不能實現是他自己的問題。所以我選擇A。那也是可以的。那我們就一直想著怎麼把視覺稿畫得酷炫屌炸天就好，後面換工作，再拿些這些圖去面試，繼續酷炫屌炸天，至於產品做成什麼樣，跟我半毛錢關係都沒有的。
不過，這種工作定位，真的有人想要嗎？
這時有人會問了，我能不能選擇A，然後逼著工程師實現出至少90分的效果？答案是，這個很難，除非你比工程師還懂實現，那或許可以。那，如果工程師忽悠我，其實沒那麼難呢？有一句話叫，你永遠不能叫醒一個裝睡的人...
所以前面說，我們不需要讓工程師實現100%的視覺效果。這種可遇而不可求。
不過，題主的傾向，明顯還是選擇B的。如果你care實現效果，就得明白不能實現的效果真的是一點價值都沒有的；你也需要明白，視覺稿只是中介，設計師的目標是把產品（而不是一個PSD）做得美好。那你要做的，就是下面的兩步：
第一步 標註
讓工程師明白你想要的是什麼。不然工程師不知道怎麼做，接著自己按感覺來，最後你再讓他改。浪費了時間，還傷了感情。
1、把稿件上的尺寸間距都標註清楚。
2、充分考慮好，界面在每個設備尺寸上的表現。
至於怎麼標註，其他答主的回答都非常有參考價值，就不展開了。
第二步 合作
如果工程師告訴你哪裡不能實現的話，按以下步驟走：
1、首先詢問為什麼不能實現。他會告訴你不能實現的原因，問題一二三四等等。聽懂這些問題，你的開發能力就提升了。
2、試著用任何方法去解決這些問題。
3、可以解決，那是最好。那就按照誰方便誰來做的原則去干。如果我來解決比你省事，只要改一張切圖，那我來；如果你來解決比我省事，只要改一行代碼，那你來。
4、萬一真的不能解決，就討論替代方案。在討論替代方案時，要找事半功倍的，不要找事倍功半的。即用更少的開發工作量可以做出更好的實現效果。
這樣，你就很容易變成一個既懂技術又懂設計，又會溝通，真正在創造價值的設計師。完成視覺稿的定稿和評審並不意味著視覺的工作已經完成，視覺定稿只算是完成了75%的視覺工作進度，要跟進後期的視覺還原直到上線才能算是100%完成。
我跟過一些WEB/iOS項目的視覺還原，覺得「溝通」最重要。
溝通可分為3個階段：
1.前期：多方確認
視覺定稿前的溝通，正常的項目管理中，視覺稿除了要給產品、策劃確認之外，還需要和技術溝通確認。把全部頁面都和技術過一遍，確保你的視覺稿是可實現的，不然視覺稿定稿後技術做了兩天跑過來和你說這裡做不了那裡做不了，你又要返工修改視覺稿，還要再次和產品、技術確認，這樣太沒效率。一般視覺還原偏差大的地方往往是動畫效果或是一些像素級的視覺呈現，比如iOS端有個加入購物袋的動畫，如果你只是口頭和技術說點擊「加入購物袋」按鈕後會有個圓形飛進購物袋的ICON，那後期技術實現出來的效果90%不是你想要的效果，因為技術不知道這個飛的弧線是怎麼樣的，不知道圓形在飛的過程中有沒有大小的變化，不知道需要設定多長時間飛進去等很多細節問題。
你要多站在技術的角度去思考，單憑口頭表達他們肯定是無法準確理解視覺的意思，他們需要的是一份直觀的動畫演示視頻。在這裡只是舉一個動畫的例子，實際工作中會遇到很多不同的複雜的頁面，你只要把技術想像成一個完全不懂設計的小白然後該如何讓他明白你的視覺稿該實現成什麼樣就行了。
2.中期：視覺規範
前期的視覺稿和項目組相關的上下游確認後，就該做一份詳細的視覺規範和頁面標註了。
視覺規範可以理解成視覺和技術之間的書面溝通，越是複雜的大型項目就越需要一份視覺規範。原因有二，其一是大型項目會有好幾個技術來同時實現頁面，視覺規範可減少溝通成本。其二是詳盡有效的視覺規範可以標出細緻的視覺狀態供技術參考。
至於頁面標註，確實是挺讓視覺設計師頭疼的，這本身是一個很無趣的工作，但是多大情況下還是要花時間去做。至於標註的詳細程度，則取決於技術對PSD、視覺的理解了，我遇到過對視覺完全沒概念和對PS完全不懂的技術，當時我沒標得很仔細，最後還原出來的視覺頁面連我都不認識，可以想像後期的跟進有多累？遇到這種技術你就老老實實仔仔細細的標註吧，視覺還原程度取決於你的標註詳細程度。
我還遇到過對視覺有一定理解，PS操作也比較熟悉的技術，像這樣的技術就比較省心了，只需要大體框架標一下，然後把PSD給他就行了，他會自己去測量間距、色值、字體、字型大小等，最後技術首次還原的效果至少都80%以上，剩下20%就自己跟進一下就好了，不太費心。
3.後期：還原跟進
後期的視覺還原跟進最重要的是要有細心和耐心。
技術初步完成頁面實現後，就得靠視覺主動去跟進還原了。
如果是在小公司，可以買飲料和零食坐在技術旁邊，對照著視覺稿一一修改。
如果是在大公司，一般都會有項目管理平台，需要把看到的視覺問題記錄在視覺BUG文檔，提交到平台上，技術會對照著文檔來修改，一般這種視覺修改會有2次以上才能還原到視覺稿95%的程度。
這個視覺跟進的過程中極其需要細心和耐心，缺一不可。視覺設計師的細心程度要達到像素級才能高度還原，如果你不夠細心，每個頁面都有一些元素偏移幾個像素，那全部頁面會有很多出入。如果你不夠細心在測試環境下逐一測試不同的狀態頁面，那很可能到上線後你才發現有些頁面的視覺還原有重要的問題。還有，你需要耐下心來把檢測到的視覺BUG寫進文檔里，提交給技術。視覺BUG多的時候可能會寫好幾十條，夠寫個半天了，沒耐心還真不行。
第一次在知乎上寫這麼長的文字。先這樣吧，後面有需要再補充。
設計師如果會 CSS 那他的設計稿幾乎一定是可以被還原出來的…
實際上，大部分行業設計師都是非常尊重工程師的。
比如汽車、建築、電器等等。
你的設計，我的實現，需要的是可行性。
網頁設計、應用設計關鍵的幾點：
所有原件標註尺寸。
邊距必須標註尺寸。
所有元素尺寸必須符合標準。
背景、前景顏色標註RGB值。
透明部分標註alpha值。
標註所有字體，字型大小，字間距，行間距。
以及其他。
這點建築師比你們嚴謹多了。
前端自己做不就得了？
-------------------------再補兩句--------------
產品九十幾頁的設計說明，才做了很小一部分功能，還有很多視覺的specs沒定義。要是真挖到交互，這個東西寫完得多少頁就不得而知了。
所以嚴肅的說，最簡單的辦法真的是自己寫一部分前端。web來說簡單的css/html都應該會，javascript什麼的，寫不好哪怕讓真前端優化一下呢？搞不定的也可以請人出山教一教。最起碼比寫一堆document寫起來快。
當然還是得有document的，不然很多東西做著做著就忘了
完。別做華而不實的設計，這是前提。
兩點。
1. 在設計之前就定好規範。規範不但於你自己方便，於程序員也方便，例如一條分割線，定好深淺兩種後，程序員定義個全局分割線樣式即可輕鬆調用。規範大致包括但不局限於：配色、線條樣式、邊距、控制項間距、不同控制項圓角大小等等。
2. 可行性。我自己是計算機專業畢業，因此非常了解代碼實現的流程，不了解的同學請與程序員多做溝通，最好能請他解釋一個小功能實現的原理。不論設計什麼，務必先在自己腦子裡假象一遍實現的過程。過後覺得可行，再向程序員求證。如果是動畫效果請盡量用AE先行呈現。
我自己的設計大部分是110%被實現，沒錯，一個好的程序員會給你額外10%的驚喜。在知乎上看到過很多精彩的回答， 得分票數高的幾位，內容都寫得的很棒，但是我個人認為這個問題還需要細分一下。
這個問題其實有兩個角色和一個目標：
- 角色1：視覺設計師
- 角色2：前端工程師（想必 Web 前端和 iOS, Android 開發也都在這了）
- 目標：100% 還原設計效果
先來看看這個目標設定是否靠譜，而要看這目標靠不靠譜，還需要看依賴條件了。如果前端工程師水平不足，你除了讓他提升水平外，想100%還原設計效果也是白說。所以以下我所說的默認是前端工程師實現能力足夠。若能力足夠，還無法實現設計效果，可能有以下幾個原因：
- 設計不合理，考慮不周密。
- 時間緊迫或不願意實現
- 溝通不到位。
### 設計不合理
前面提到的角色1就是視覺設計師，普遍來說，視覺設計師下是利用視覺符號來傳遞各種信息的設計的，而縱觀各類崗位職責，並沒有嚴格要求視覺設計師擁有 HTML/CSS/JavaScript 技能。事實上大部分的視覺設計師不懂技術，像 CSS 盒子模型，Float，絕對定位相對定位，if..else..then 這些也不懂。這是客觀情況，如果視覺設計師有這些知識技能自然是可以避免一些問題，但術業有專攻，無法強迫。
除了提高自己的知識水平，還可以有一些其他的方式：
- 設計評審。在還是交互原型時，就邀請技術經理一起 Reveiw。
曾經我司在某銀行實施項目時，做的是 Hybrid 應用，也就是 Web 和 Native 混合型的，用了一些框架，也有一些技術上的限制。但交互和視覺設計的過程中，並未與技術經理溝通，直到視覺做完後，交付給 H5 工程師時，工程師就傻眼了，這幫設計瞎搞，這實現不了啊...而後只有重新設計了，進度也被拖慢了很多。
在交互階段就把技術人員引進來，會有極大的幫助，同時也利於技術人員確定技術選型。
### 時間緊迫或者不願意實現
所有的項目和產品都會有開發計劃，雖然很多情況下計劃總是趕不上變化（需求變更啦，上線時間提前啦），但是大體上每個開發人員對自己所負責的部分有自己的優先順序排序。在我所做的產品和項目中，研發人員大部分情況下的關注度是：功能實現&>效果實現。這個時候其實更重要的是統一對優先順序的認識。
如果開發計劃已指定，同時研發人員也認可交付時間點，那麼在開發任務內的計劃，視覺設計師撒潑打滾躺地賣萌，曉之以情動之以理，怎麼打動前端工程師，網上也有很多同仁的經驗技巧，總是能實現的。
設計的實現，不僅僅是前端工程師的工作，有時候也需要後台的配合，想要實現，那就得給咱們工程師時間，不能又想馬兒跑，又不給馬吃草吧？
同時設計和程序是息息相關的，有時候並不是不想實現這樣的設計，而是因為確實有一些問題，比如說在 Digg 還流行的那段時間，他們的首席設計師和首席程序員之間的爭論：
丹尼爾·博卡（Daniel Burka）（Digg 的首席設計師）和喬·思湯普（Digg 首席程序員）之間有一場非常著名的爭論。那個時候丹尼爾想要在 Digg 的「按鈕」上做出一次設計上的變動。對於丹尼爾來說，這個變動就是微小的一點；但對於首席程序員喬來說，即便設計上微小的一點變動都會對整個網站的響應時間產生巨大的影響。為了適應這一點點的變化 Digg 網站必須提升自己的處理效率，改善伺服器的內部架構。
http://tech2ipo.com/93780
http://www.smashingmagazine.com/2014/11/21/why-you-should-include-your-developer-in-the-design-process/
所以在我們團隊做一些設計諮詢項目時，會把技術人員引入進來。
### 溝通不到位
- 切好圖，標註好。這裡面有很多講究，這個問題下回答里也有很多很好的建議，建議查看
- 用對方聽得懂的語言。前面說了很多視覺設計師並沒有技術基礎，但是理解一些術語對於和程序員溝通是非常有效的。比如說動效里有很多，你說了半天「從這裡到那裡」，「速度稍微慢一點」，可能也很難做到你想要的那種效果。但是如果你說，這個動畫的 Tension（拉力） 數值，Friction（摩擦力）數值，cubic-bezier函數是多少，那程序人員相對會比較好理解
可以參考這個網站，找到很多動畫效果的名稱： Form Follows Function
- 不斷跟進。設計給完圖之後不能不聞不問，等到代碼寫完後才傲嬌地說：「哎呀，沒按我的設計效果來」。確保設計效果的實現也是設計人員的職責，建立 Bug 文檔，貼圖對比，描述清楚，因為並不是每個人都是像素眼，對美的認識也不一樣。
### 總結一下
過程：溝通—&>設計評審—&>交付設計圖—&>再次溝通—&> 跟進追蹤
每一份工作都不是看上去的那麼簡單，設計不僅僅只是個畫圖把東西變得好看些的人，程序員也不只是寫寫代碼（在我們團隊的一些項目中，很多設計不合理的地方都是程序員指出來的），最重要的相互間的溝通和理解。
其實我建議能修改下這個問題的說辭，什麼叫「是怎樣讓前端工程師100%實現設計效果的呢」，這並不只是前端工程師的工作，不是「怎麼樣讓人去實現的」，而是「怎麼配合」的問題。如果可以的話，建立一個design system是個好方法：）
salesforce的lightning design system是個很好的例子， Angular material也類似。
簡單來說就是把所有用到的components建立成一個前端的庫，設計師要把document寫好，告訴前端工程師什麼情況下用哪一個component，哪個class，然後保證庫裡面的每個components都是pixel perfect就好了。 這樣無論是designer之間還是工程師之間都避免了出錯，保持高度的consistency ：）
連後期的spec都免了，因為工程師copy的都是pixel perfect的code。
而且庫里要包含所有的assets，color，icon等等，基本上可以做到hand off的時候給個最終的mockup ＋ flow，結合pm的story就可以做到完美的產出了。
以前做網頁設計，是把psd丟給前端的，前端是邊開ps自己量，邊寫代碼。那時候都不關注還原，因為還原的很好嘛。
現在做遊戲UI，還原就一直是個頭痛的問題。
先說說現在的做法。
以前我的標註是這樣的：
這個倒過來是因為坐標點是在左下角。
這種標註的缺點就是標註一多線就交叉，亂七八糟，不清晰。還有不精確，比如投影的邊界，看圖並不好確定。
所以現在標註是這樣了：
更精確，因為是ps里看的坐標。
更清爽，不拉線，直接量好了寫出來。
圖也變正了，前端喜聞樂見。
測量是在ps里看的，因為坐標是左下（cocos2d），所以是倒過來的，我們控制項坐標在中心的，所以要自己換算下x=x+w/2，不過這都不是事，標註花不了多少時間，大約在0.5~1.5h。
程序實現的時候會把一塊功能作為一塊，所以和前端指定了個規則，如
01 w100 h50 x10 y10
j01 x20 y20
這是指j01的坐標是以01這個控制項為基準的。這樣能不能100%還原？理論上是可以的。
但在實際工作中有以下問題：
除了UI，沒人在意界面的還原度（有時候UI自己都不在意），前端不看標註或者標註有誤不溝通，UI讓前端改，只能看前端心情。
要解決上面的問題，應該把美術的還原當成bug來做，程序的bug有測試來把關，美術的bug也應該由美術（UI、動畫等）來測試，測試通過才能上線。
以上方案還在慢慢實施，如果你有更好的方法，記得告訴我。
我認為投票數最高的不太具備策略性。
最有效的策略是設計師（可以聯合設計師）把那位還原最好的「前端開發工程師」捧起來當「前端開發總監」。
當上總監了，還原率這事兒一了百了。首先要明白一個道理，視覺設計師的最終產出物不僅僅是視覺稿，還有一份非常重要的文檔：
Visual Guideline (視覺指引手冊)
最終產品視覺上實現的程度，和這份文檔的完整度息息相關。
當一個項目的迭代周期很長，是半年、整年、甚至好多年。所以設計也需要不停的迭代，這個時候怎麼辦？
在整個團隊中，一個設計是由多個設計師完成的，如何保證每一位設計師視覺上的統一性？
當由你負責設計的部分需要面對不僅僅是幾位工程師，而是幾十個，甚至上百個工程師，怎麼辦？
當和你對接的開發人員不在一幢樓，不在一個城市，甚至不同國家，不同時區，怎麼辦？
所以說，光是一份設計稿是沒辦法讓工程師實現你的視覺設計的，需要一份文檔，來對你所有的設計進行介紹、標記、說明。每一位視覺設計師都應該對自己的設計稿負責，所以這份文檔是必不可少的。
這份文檔沒有固定的格式。但在一家公司，或者一個項目組中，儘可能保證格式和結構的一致性有利於後期的維護更新。如果有條件把這份文檔維護成Wiki頁，方便檢查更新日誌和搜索內容，那對開發和設計來說都是一種優雅的體驗。
簡單說說我們團隊是怎麼做的吧。由於項目文檔的保密原因，我會對相關圖片進行模糊處理。
——————————————————————————————
視覺設計師設計工具：Sketch
設計稿標記工具： Sketch Measure (Sketch的插件) 或者 PxCook
文檔製作工具：PPT
文檔輸出格式：PDF (所有內容正在往公司內部的Wiki Page上遷移)
——————————————————————————————
0 準備工作
在這份文檔開始製作之前，需要設計風格定稿，整體設計方向不會有太多變化的情況下，才開始著手創建文檔。
和工程師溝通好開發的細節，比如重要的Style部分。（我們稱之為語義定義，我下面會介紹這部分內容）
1 明確職責
明確各位設計師的工作職責。哪個人負責哪個模塊的視覺設計，哪些人負責控制項的設計，哪些人負責對源文件進行標記，哪些人負責文檔的撰寫。這樣，某個環節出問題了，很容易找到對應的設計師。
2 文檔結構
我們的文檔整體上分為Update Log, Style, Layout, 和 Page Mark 四大部分：
Update Log用於追溯文檔的每個版本，由誰在什麼時間做了哪些改動。
Style部分定義了整套設計所用到的所有字體、字型大小、顏色以及字體顏色字型大小的組合。
Layout部分定義了整套設計中，每個頁面的框架結構，該頁面總共用到了哪些控制項。
Page Mark部分，則是對控制項和獨立頁面的尺寸標記和typography的定義。
3 語義定義
因為某些項目非常龐大，涉及大量的設計師和工程師，而當某個控制項或者頁面有視覺上的調整的時候，如何廣播給每一個開發人員和設計師？一個字型大小的改變導致所有涉及到的頁面的改變，如何保證改動更新的一致性？這是一個非常難處理的問題。
所以我們在創建文檔開始，就把顏色、字型大小、字體、以及字體顏色的組合統統定義好，這是一個非常謹慎和重要的過程。
我們把一個項目中用到的所有字體字型大小還有顏色，用這種方式表達出來。
字體字型大小部分：
顏色部分:
Name 是我們對某個字體字型大小或者顏色的命名，LESS Variable是工程師人員用來維護這套樣式的代碼命名。Remark則是一些說明性的內容，比如這個顏色是滑鼠懸停的高亮之類的。
當顏色，字型大小都定義好了之後，我們接下來需要定義的就是兩者的組合了。
我們把整套設計中文本分為幾大類：Heading, Content, Title, Button, Table.
不同區域的文本再做細分，比如Heading類：
（我們在不同平台同樣的種類的文字使用不同的字型大小，所以會由for pad 和 for phone兩種樣式）
我來解釋下這個定義的含義。
Font6 是我們定義的Arial 24 Normal
Color1 是我們定義的#474747 這個顏色
那麼
Heading 1表示這個文本樣式是
Font: Arial 24 Normal
Color: #474747
LESS Variable 是開發人員維護這個樣式的代碼命名。
這
樣，我們在標記某個頁面或者控制項的時候，我們只需要標這裡用的這個樣式叫做Heading
1即可。而當我們需要更新一個顏色的時候，只需要更新Color這個顏色代碼，所有涉及到這個顏色的文本樣式都會跟著一起變化，而我們的文檔標記部分也不
需要做任何的改動，保證了整體的一致性，同時也降低了維護成本。
這個就是我們稱作的語義定義。這是一個全局的定義，所有的設計師創建新的顏色和字型大小的時候都要匯總到這個地方。然後會有專門的開發人員把這部分樣式轉換成代碼，做相應的更新。
4 Layout 結構說明
這部分內容是對整個設計的頁面結構的說明。
同一類的頁面，比如列表頁，詳情頁，這一類的頁面是可以復用的。
獨立頁面，比如首頁，這一類的頁面只出現一次，是不可復用的。
比如在列表頁
我們用到了Tab, Filter, Form, Tool Bar, Button 這些控制項
再把結構結構說明清楚。
這樣，開發在搭建這個頁面的時候，會清楚的知道信息結構和所使用的控制項。
5 Page Mark
這個部分就是體力活了。內容主要分為通用控制項和頁面部分。
先把控制項挑出來Title, Footer, Tab, Filter, Button, Table, Popup Menu.
把這些控制項的尺寸，顏色，文字樣式單獨標記出來，這樣開發可以單獨做控制項庫。
我們自己維護頁面起來也非常簡單，因為頁面是由控制項來構成的。
然後再把頁面通用頁面以及獨立頁面的對齊方式，尺寸距離完整的標記出來。
——————————————————————————————————————————
以上就是我們一份完整的Viusal Guideline的內容。當然，這份文檔的製作是非常耗費精力的，需要大量的人力成本，比我們完成設計稿的時間要多的多。
當一個項目大到一定程度，我們不得不標準化才能解決設計一致性的問題。
當這份文檔大到上百頁的時候，每一個工程師只負責其中一小部分的時候，通常他們是沒有耐心看完整個文檔的。而設計師又不可呢一對一面對面的來說明頁面應該怎麼調整。
你要把你遵循的原則整理出來給工程師看，比如你要用哪些顏色、字體等，它們各表示什麼視覺含義，用在什麼場景。設計合理的間距規則，讓程序員不用做多少特殊處理就可以實現。
這種文件我們稱為style guide（風格指南）。
高票幾個UI設計師的答案不錯，相當專業。
不過在實際開發中，無法實現的原因可能相當簡單：
做UI的不專業，拿出來的東西光顧著光鮮亮麗，實際根本不能用。以iOS開發為例，
低級錯誤1: 拿iPhone5甚至iPhone6的屏幕尺寸為基礎做UI布局，不考慮iPhone4／4S的尺寸。昨天一個合同工設計師就提交了這樣的玩意，被我直接一屁打回去重做。我管你做得多漂亮，連有多少地都沒搞清楚你也敢來做設計？
低級錯誤2: 拿Web上的常見組件直接套到mobile上。比如滾動下拉框。在mobile那麼小的尺寸上，已經滾動的屏幕上你再給我套一個更小的滾動組件，這叫沒有常識好嗎？iOS UI在iPhone上的原生組件就沒有滾動下拉框，是Apple做不出來嗎？那是Apple根本不希望你鼓搗這個東西！
低級錯誤3: 對可能呈現的數據形式和量根本沒概念，哪個組件好看就扒拉哪個。定死3～4個的動態圖片位，他給我弄個全屏gallery view。
以上都是混飯吃的混子UI設計師，不多說；但做UI門檻低，很容易就遇上，尤其是創業小公司。
＝＝＝＝
至於那些天馬行空的構思——本座也見得多了，99%是光漂亮，實際是繡花枕頭，在UX上根本是一塌糊塗，不能用的。縱觀整個App Store，革命性的UI又真正好用的又能有幾個？踏踏實實把開發做下去就知道，把那些大家都用爛的常規布局做好已經是很難了，需要考究的細節其實無處不在，。酷炫絕不是出一張效果圖就行的。你自己先搞懂CSS的BOX模型（margin，border，padding）再和前端談行不行，你以為前端都是在用畫圖工具做界面嗎？
對於前端來說，UI的美需要，代碼的美更加需要。
我都不想說了，都是淚……
衹懂得上網找幾個PSD隨便替換一下就覺得美輪美奐的蠢妹子，壓根就沒想過我的感受……
重複利用元素:0
不規則圖形:100%
佈局不懂得像素級匹配
位圖圖形質量:先縮放，不合適，確認，好，放大……確認……
淚……麼的
大部分時候即使自己標註的很清楚了，前端還是不會來嚴格按照執行。這時候就要發揮設計師強迫症的能力了，面對面溝通，一個一個解決。
1. 不要搞些奇奇怪怪的元素和布局。
2. 及時確認，對方不行我馬上改。
最後，我改得跟他做的一樣，就100%了。
推薦閱讀：