為什麼部分開發工程師不喜歡調節界面的 UI 細節？
工作中發現部分FE不喜歡調節UI細節，可能覺得這是浪費時間，沒有技術性、挑戰性~~但是對於一個成功的產品來說，優秀的視覺細節是必不可少而且可以加分的。該怎樣才能讓開發同學對此項工作變積極呢？（不考慮UI稿修改的情況，跟本題有偏差）
09年的時候我進SQLServer，跟一個全身都是毛的法國美工兼UX一起合作，開發SQLServer Management Studio裡面的一個高大上的功能。法國人就是浪漫啊，整天異想天開，最後做出來的東西，理念跟windows phone那個滑來滑去的UI十分接近。那個時候windows phone都還不知道在哪。Introducing the Extended Events User Interface 嗯，就是這個了。光看截圖看不出那種動感，還得自己把玩一下才能體驗到。
調整UI的過程花了半年。那個法國人每個星期都會給我們一個新的稿件。稿件裡面寫的很詳細，每一個按鈕有多大，文字字體多大，間距多大，顏色的RGB，還有圖片都自己切出來附贈給我們。人家還是相當的負責人的。但是實現這個東西他媽的就是工作量巨大啊。做他那個東西還要用Windows Forms上寫動畫（不像WPF那麼容易一擼就出來），還得在注釋裡面畫v-t圖來注釋代碼。
整個過程差不多如下：
1、法國人來找我，展示新的稿件
2、我實現
3、法國人跑來檢查這個活的設計
4、法國人意識到了自己的某些設計錯誤，回去改
其實這反映出一個什麼問題呢，就是UX自己設計的東西不會動，沒有交互感，所以非得我們做了出來，他才能真正地感受到他自己的設計有多麼的牛逼或者愚蠢。於是返工了幾十遍，人家才滿意。也就是說，我的工作時間有相當一部分都在陪他設計，卧槽我當然不願意啦。
微軟自己的程序員也感到很痛苦，於是現在WPF啊、Windows Phone啊、Windows 8 Metro什麼的都可以用Blend for Visual Studio來開發。這是一個完美的美工做活UI，程序員寫View Model和data binding然後組成一個程序的良好方法。如果美工會用的話，就不需要總是讓程序員去實現，從而可以審視自己的設計了。
不過也只有WPF配合Blend有這個功能。其他所有的東西，包括Windows Forms、MFC、HTML5什麼的，都沒有類似的適合非程序員用的designer，因此程序員們還得繼續苦逼下去。
==============================================
於是，要如何讓程序員有積極性呢？只有兩種方法：
1、用Blend來開發。其實現在微軟出了winjs/winjs 路 GitHub ，代表Blend的那個javascript Win8 Metro app的功能可以直接搬到瀏覽器上來用了，也就是說Blend也可以用來寫網站了，做完了之後稍微改幾個css和js的path就可以直接運行了。美工也可以自己做界面了，然後程序員做data binding，用MVVM，最後組合成一個具有真實的交互功能的網站。如果你們做的是Windows平台的程序那就更得用Blend了。
2、多請吃飯。
歸根結底還是意識問題，而意識是可以且需要不斷培養的。
我們的工程師都會很注意細節，所以會很樂意像素級的調整界面，因為他們知道自己在創造好的產品，而好產品就是這麼一點點堆積出來的。
前幾天有用戶反饋應用中某個地方的文本沒有居中，我截個圖發給工程師，寫上幾個字「某哥，咱們被羞辱了」，這用不著設計師看，就是工程師該注意的問題。
同樣，某一次設計師做完一個設計，工程師實現後，始終覺得哪裡不對勁，視覺不舒服，接受不了，於是吐槽。設計師並沒有覺得這是對自己專業的挑戰，而是重新思考，給出了更好的設計，最終大家都覺得比以前上了一個台階。當然在開發之前能提出更好，但是這說明，一個有美感的注重細節的工程師，對於創造優秀的產品同樣重要。
無論工程師還是設計師，都應對一個成功的產品、對有品質的細節負責。設計的質量決定我調它的熱情。
很多人的努力程度根本沒到拼天賦的地步，同樣很多產品也根本沒到拼設計的地步。
更新：[Mind Fire] 目的、細節和大局觀作為有審美追求和強迫症的程序員，我願意調
最近就在考慮針對這個問題做一次組內分享，沒想到這先討論起來了，把我整理的一些思路貼上來，僅供參考
偶從事前端開發4.5年、客戶端開發1.5年，都是做設計稿轉化成可交互界面的事情
先簡要回答樓主的問題：（不考慮UI稿修改的情況下）為什麼開發還是不願意去調UI細節？這個問題隱含了一些前提條件：1. 設計稿沒有頻繁修改2. 同時假設設計稿已經做了標註3. 設計稿是一份有質量的輸出我貼個例子圖上來（這是一個客戶端的圖，無所謂區別）
（為了不暴露，我把其中的一些文字給遮住了）
問題來了，設計師會想：尼瑪我花了這麼多心思進行標註，已經非常精確了，為毛研發搞出來的結果仍然是一堆問題！好了，如果你是一名研發，你拿到這樣一張圖（且不論它的設計有沒有美到讓你心動），你有能力把它還原到和設計稿一模一樣么？跑題了，給一下結論：1. 意識/態度問題，研發不按照設計稿來開發2. 能力問題，這裡更多體現在跨平台的兼容性/一致性上，比如IE6下的布局和Chrome下的差異3. 還是能力問題，從代碼的角度來看，要做到一致性的設計稿還原，還是需要關注很多知識的，比如字體、行高，以及一些複雜布局結構帶來的影響4. 設計稿問題，我們看看上面張標註圖，它其實存在一個很嚴重的問題，看下圖
從設計師的角度來進行標註的結果就是這樣的，設計師能夠給出兩個像素之間精確的距離，但是代碼實現層面確實另外一回事，因為在界面中，文字是有行高的，像這樣
下面，做一些簡單的分析
1. 意識和態度問題前面有很多答案都提到了：說前端不是切圖的，說調圖是一件沒有技術含量的事情，說研發應該關注代碼，不應該關注UI細節……針對這樣的回答，我只想說：狗屁！
我一直以為，圖片是代碼的一部分，因為不同的圖片輸出，會導致代碼實現的方式不一樣（其實這樣也是為什麼研發不願意改設計稿的原因，因為要動代碼啊您嘞！）。作為一名前端，難道關注的就是JS/CSS/HTML/網頁性能之類的東東么？你把設計模式、框架、技巧用的那麼牛逼，卻把界面弄的跟屎一樣，用戶會買賬么？難道你真的不在乎設計師在背後說：這個同學不行，每次弄出來的頁面都一堆問題……圖片是代碼的一部分，作為前端，你在考慮性能、載入速度的時候，回去做圖片大小優化么？你是不是應該知道如何做圖片壓縮呢，如果能夠在保證效果的同時把圖片搞到最小呢？關於設計質量對產品的影響，前面回答已經說了很多了，能不能吸收看個人……（也許你覺得我TM就是過來拿點錢的，其它管我鳥事，那就算了）還有，設計是需求一部分，請問需求變化了，你會說滾犢子！我不幹！么？產品經理也有需求做的不全面、錯誤的時候，那設計師也必然會有「後來發現其實這樣的效果更好」的時候；研發不也是有重構的時候咩？最後，我認為自己前面的分析都是扯淡！沒有意識就是沒有意識，就是研發認為這個事情不重要！可是換個角度，如果研發在一個功能實現上錯了，TA會覺得不重要麼？必然不會！為什麼不會？因為大家都會指出來，你這裡有BUG。研發都會意識到有bug，說明功能不完整；而對於設計還原度而言，沒有人（除了UE）會去指出來說實現的有問題，整個團隊（甚至連UE）都不去說這是bug，要修！那我作為一名重度拖延症患者、懶惰、還有一堆功能bug等著修的研發，哪還有心思去管UI細節吶！可是這個時候UE跳出來了，說你這裡做的不夠好！尼瑪，產品都不提，你提個毛線，等著，等我有時間了，有心情了，給你調調……對立、負面情緒就這樣產生了……終究到底，除了設計師，整個團隊對這個事情都不重視，研發必然也就不重視，技術負責人不重視，小弟就更難去重視，沒有人知道這個事情的價值在哪裡，既然不知道有沒有價值，研發為何要花心思和經歷去搞……2. 能力問題
如果你是一名研發，有人說你能力不行，你也許會臉上笑一笑，心裡肯定早就罵娘了吧~~
如果你的項目裡頭一堆的質量問題，很多BUG，也許就會有人議論你說你能力不夠，這些人可能會是產品同學，可能是後端同學，可能是你組內前端同學，也可能是你的經理等等，但是一般不會是設計師；可是如果你每次做的頁面都那麼爛，一堆問題，那同樣的設計師也會在背後說你能力不夠本質是一樣一樣的嘛~~就是沒有把活做好！賴誰……這裡講一位我以前的同事，絕對是牛逼人物，和我在一個組一年多的時間，他厲害的地方是做出來的頁面和設計稿一個像素不差！設計師看到他做出來的頁面都會驚呼：這是直接把設計稿貼上去的么？更牛逼的在於即便是不同的瀏覽器，也都能夠做到這點。我們當時有一些輔助工具來驗證界面效果，就是把做出來的頁面截圖，再把設計稿覆上頭做比對，他真的能夠做到完全重合的捏！後來他被調到另外一個組去，負責一個頁面的效果，那個頁面應該是國內網站裡頭PV最高的頁面了，他的工作就是就是保證那個頁面的一致性，各個平台，各個瀏覽器，各種主題！沒錯，主題！他曾經跟我講過不同的windows主題下，瀏覽器的一些差異，人家都研究到系統主題了啊~~他對瀏覽器的差異表現了如指掌，深知對相同效果各種實現方案帶來的差異，我經常遇到樣式方面的問題都會找他幫忙。我深以為，像他這樣牛逼的人物，別說公司，業界也不會有幾個能出其右了。所以，請問你能夠把設計稿還原到瀏覽器上的時候，做到和設計稿一模一樣么？同時兼容不同瀏覽器！我也不能……即便我一直在朝這個方向努力作為前端，當你在從網上拷貝一份reset.css的時候，你知道裡頭每項的作用和含義么？你在寫font-family的時候知道不同的字體渲染的效果是什麼樣的么？你知道稱線和非稱線的差異么？你知道在多行文字輸出的時候，怎麼做到左對齊的時候，也能夠右對齊么？這些難道不都是技術能力的體現么？
3. 設計師本身的問題
我一直提倡研發來做切圖的工作，而不要讓設計師把圖切好，把標註做好，扔給研發碼代碼。我的出發點還是那個：圖片是代碼的一部分。作為前端，應該能夠知道對於這樣的效果，應該切出什麼樣的圖是最優的（最優包括圖片大小、質量、代碼實現方案等綜合權衡），這些東西是設計師不懂的。前端裝一個photoshop有那麼難么，量一下尺寸會佔你多少開發時間呢？好了，既然研發應該做這些，那設計師呢？不知道有多少設計師同學知道行高的概念呢，設計師同學會考慮當文字折行之後應該怎麼顯示么？我身邊很多設計師同學不知道點9圖是怎麼畫出來的。我以為，既然是一個團隊的配合，就會涉及到配合層面的問題，最典型的就是雞同鴨講，研發說這個東西實現不了，設計師說就是一個簡單的陰影啊！我在和許多設計師溝通的時候，真心覺得屌絲程序員和高大上設計師是活在兩個世界的，溝通障礙非常大！那既然要合作，雙方是不是也應該稍微了解一下對方的世界，設計師抽空看看CSS，自己動手寫一個簡單的在簡單頁面出來，了解一下研發為什麼對圓角和陰影這麼頭痛，思考我做為設計師角度，走扁平化的風格而不是擬物的話，是不是從效果上也能接受，但是研發就會高興很多！設計師同學，你們會關心研發做出來的效果好不好，你們會關心這個頁面、或者這個app的安裝包是不是很大么？產品的質量也不僅僅體現在視覺表現，如果一個普通Android app，安裝包10M+，你覺得會有用戶下載么？設計師同學會主動找研發溝通，說：來，我們坐下來聊聊，你希我給你輸出一些什麼樣的圖呢？我估計很多研發會說：你能把圖層好好整理一下么？………………和很多研發不願意寫文檔/注釋一樣，設計師同學也不樂意規整圖層，每當我打開一份PSD的時候，各種找，一個icon，3個圖層組成，其中兩個在圖層列表的最底部，一個圖層在中間某個組的內部……吐槽的優點多，根本停不下來。
總結一下：1. 團隊對這個問題的重視，包括產品角色、研發角色、研發leader，非常重要2. 研發能力提升，做不好就是做不好，其它言語都是掩飾自己能力不行的理由3. 設計師不能把自己關在象牙塔里的同時去吐槽研發做的和shit一樣，團隊允許的話，讓設計師來寫靜態頁面試試最後，想說一些我覺得可行的一些思路
1. 我會在團隊內部強調設計稿還原度的重要性，並且會在有同學站出來說這個東西沒法搞的時候，挽起袖子上去搞定給TA看。2. 我會鼓勵/強調設計師對設計稿負責，丫的做出來效果不好就是不好，不要覺得不好意思找研發改而默默地就忍受了，長此以往，產品（萬一因此）要是做死了，大家都沒飯吃3. 提升團隊整體研發水平，組織分享、交流，如何提高設計稿還原度，這些東西本身就是知識和經驗的組成，是可以復用和沉澱的。4. 工具化，這點是我認為及其重要的，尤其是當研發的意識仍然沒有跟上的時候。我不願意弄，那能不能不用我弄，自動化就好了。比如我前面提到的一些還原度檢查的工具和平台。最後的最後，給我在這方面的一個成果做一個廣告：
切圖這個事情，研發不願意做，其實設計師也不願意做，尤其想做APP端，有時候要切好幾種圖。於是，我覺得這個東西是可以用工具來改進的，於是誕生了一個「切圖神器」的東東它能夠有效的提升設計師/研發切圖的效率
原因
1，認知不統一常常PM或者UE不會認為這種改改幾個像素換換圖的事情，會耗費多少工作量可是實際上，拿我舉例，每次開發版本的時候，ui的事情佔據了超過一半的開發時間2，經驗值低
同樣是做事情，假設工作量相同。做一次重構或者梳理一部分模塊什麼的，比做ui修改Exp要高不少呢，對技術人員的成長和成就感都有影響3，繁瑣，頻繁的打斷、溝通、甚至反覆
當然優秀的UE/UI會大大減少溝通、打斷、反覆的次數，提供溝通效率，但是很多時候這種情況很多，頻繁的打斷導致程序猿的效率極低(好多人在溝通多的時候都是晚上清靜了才有機會開始編程我會亂說)，而細碎的反覆會讓RD煩躁，會大大降低UE/UI在心中的靠譜程度，就好比我寫的程序總有bug然後你會心裡覺得我編程很次一個樣。那麼怎麼辦呢
1，明確統一目標 咱們兩個是一夥的，共同的目標都是把這個產品做好。這個很重要，在此基礎上會衍生出對事不對人啊、快速溝通啊 之類的良好原則2，坦誠 、互助
這件事做的不好，就是不好，我做傻逼了，就是傻逼了。老老實實承認，彼此互相探討下怎麼可以做的更好。爭取每次犯過的錯不要再犯，互相提高。很多時候問題的發生源自於信息不對等，UI不知道RD要什麼樣的切圖，那麼好辦，互相介紹下自己和自己的工作啊。RD專門花2個小時，給UI做培訓，講一講我們這邊是怎麼用切圖的，我們希望要什麼樣子的切題，什麼樣的東西是有問題的，有哪些案例balabala（做了一次，效果非常好，UI mm和我從此溝通更順暢，效率更高）。3，職責邊界。團隊需要你或者對方越過自己的職責邊界，了解一下相關的知識。比如說 RD會一些交互知識，那麼一些明顯的反人類的東西你就可以指出來，在具體的碰需求的階段可以更有話語權來爭論一些東西。
4，很好的個人關係。個人感覺團隊氣氛還是很重要的，不一定要私交很好，但是要有活躍團隊的氣氛和意識，讓大家更快樂的一起工作。怎麼都是一天，快樂一點更好:)
這個答案缺少什麼對合作確實不舒暢的人，我還真沒有辦法，不過現在還沒有遇到過這樣的人，可能是我幸運吧。確實見過合作的甚至水火不容的團隊==== 2014-04-28 增加
追加四點。
1. 有些人說我答非所問，先申明一點，問題描述有改動，各位可以查看日誌，我回答的時候問題處於#37413821 節點。我沒時間跟著問題的描述天天改答案來切題。
2. 要說離題，上面很多吐槽一時爽的答案那才叫離題。在我回答的那個節點裡題主說明了自己給了FE完整的圖，而FE做得跟設計稿有偏差，都沒有按照完整的圖來做。那麼我的回答當然是先分析為什麼會出現FE不按照完整圖來實現？這背後的心理動機可能是什麼？（感謝很多其它回答者，你們的答案一一印證了這些心理動機。）答案的前面部分分析相信題主理解之後可以自己思考如何去提高FE在實現的時候多關注界面細節的意識，最後一部分基本上已經是從實際操作層面來說如何解決問題了。談何離題？而這些吐槽回答者卻莫名其妙地腦補了「設計師反覆修改圖連稿都定不了」、「肯定會出現FE按照你的設計做完之後你又要別人去改」、「你丫肯定站在FE背後指指點點把別人當人肉PS來用」之類的各種情節，或者一副高貴冷艷的模樣說「設計的質量決定了我實現他的熱情」，請問你從哪個地方看到題主的設計質量有問題了？
3. 別嚷嚷什麼設計師沒有標註出各個顔色的RGBA值、各個間距的px值，作為FE你連xscope或者FScapture都不會用請問你平時是肉眼看出顔色和間距的值的么？過去的七八年里我實現過很多設計師給的設計圖，標出RGBA值和px值的有，不標的也有。說實話，在實現的過程中沒有任何明顯差別，直接看設計圖上標的數值與自己把滑鼠移過去取值，效率上如果有影響，也比不上不用snippet插件直接一個字母一個字母地敲background-color:transparent來得多。明明實現得有偏差卻把責任全推到設計師沒有標明詳細的間距寬度什麼的，在嚷嚷這的時候你能不能先捫心自問一下，你的代碼里該寫的注釋都寫了么？
4. 絕對的分工明確只存在於生產流水線之類的機械勞動里，稍微高級複雜一點的工作都不可能有非常明確的分工界限，看得出很多的人團隊意識跟工廠裡面那些擰螺絲釘壓塑膠殼的初中畢業生沒什麼區別。比如有人說，設計師或者美工（甚至還有產品經理！）應該把圖切好，標明各個值再交給FE。遠的不說，說一個例子。我原來在百度時一個我很佩服的同事在做前端的那段時間裡，寫了一個工具專門將各種小圖片合在一起自動生成css sprite所需的整圖和css代碼，他甚至還研究了一些論文以便論證自己所生成的整圖占的面積是最小的。請問這種事情應該是FE做還是設計師（或者產品經理？）來做？團隊合作的其中一個意義就在於當你的隊友出現能力不足或者失識的時候，自己主動地補位並掩護，而不是指著他說：都是他的錯！
==== 以下是原始回答，一字未改。
反對目前所有答案。
（終於能夠像其它酷炫拽的同學們一樣用上這句屌炸天的開頭了，淚流滿面。）
為什麼反對呢？從上面的答案來看，大部分回答的同學都是做研發的，所以回答的角度也都是以研發的角度來回來，說來說去不過是「調整UI沒有技術含量、浪費時間、不是我的責任範圍、你丫老是改設計稿打亂朕的節奏了寡人日理萬機沒空調整……」
我要說的是，這個角度太LOW了！這個角度基本上就是站在「我就是個搞技術的產品能不能做好跟我沒關係，我就是個搞技術的我的價值就體現在我用的技術深不深奧，我就是個搞技術的做沒有技術含量的東西不是我的理想，我就是個搞技術的我隨時做好了跳槽的準備不行我就換個地方照樣寫代碼」來回答的。
想像一下你要泡妞，對面坐著兩個從來不認識的妹子，其中一個漂亮時尚媚眼含秋波（而且胸大），另一個過時土氣雙目無神采，你選哪一個？對！當然是選胸大的那個！可是我們都知道往往太漂亮的女人容易有傲氣，侍候起來不容易，想法幼稚而且要你跟著她的話題走，不太漂亮的反而性格宜人，交往起來地位平等舒服。但是……還是要選胸大的那個！
對於很多產品來講，漂亮就像是女人的外表，有了林志玲田馥甄鄧紫琪波多野結衣松島楓安城安娜外表的女人會受到更多人的關注。而交互是否流暢、Bug是否很少、性能是否優異等就像一個女人性格是否溫婉、思想是否成熟、愛好是否有品味一樣，在你和她交往之後才會慢慢體會出其中的好處。但是如果她長得太差，你連交往的念頭都沒有，談什麼深入了解呢？
認真點來說。
我發現程序員大致可以分為科學家和工程師兩類，科學家關注技術是否優越，而工程師關注產品是否完美。和科學家類型的程序員合作一起做項目往往是件痛苦的事情，他們太過關注自己手中的鎚子是否先進，卻不在意自己敲進去的釘子是否平整光滑不扎屁股，更不要說這顆釘子是不是跟其它釘子對齊了。特別是那些從更早的時代開始做程序員的更是如此，那個年代很多用戶體驗的技術不成熟，能做出一個能用的東西已經不易，更不要說做出一個性能還算不錯的產品了。抱著這個想法走到今天，大多數沒有進化應該被淘汰的程序員卻反而坐到了更高的位置，開始拿這種過時的想法熏陶小弟。
在百度的時候一個貼吧早期的工程師當時已經是高級技術經理的人跟我聊貼吧的時候說，貼吧之所以能夠火起來是因為它性能好，超女那一波活動時粉絲們在網上到處找論壇叨逼叨，很多罈子技術不行撐不住流量就掛了，後來粉絲們發現百度貼吧居然不怎麼宕機，就聚集在這裡了，於是產品就做起來了。因此結論就是你只要把技術做好，能撐得住大流量，產品就能火起來。
「因此」，他滿臉笑容坐在椅子上跟我說，「我們百度知道做了這麼多年，在線問答這一塊我們很熟悉，我跟你透露一下，我們馬上要上線一個叫新知的產品，就像知乎一樣，基本上我們把產品放出來就是要告訴國內其它產品：你們不用做了！」
今天如果你在百度上搜「百度新知」的話，你會發現第一個鏈接已經點不進去了。我想絕對不是因為頂不住瘋狂的流量掛掉的。
程序員是一個需要自己做很多判斷的工作，而在我的經驗里，能夠做出正確判斷的程序員是非常少的，當然包括我自己也是走了很多彎路，然後在回頭看的時候發現自己做錯了判斷。比如說，後端工程師常常在產品一開始就關注性能指標、上來就搞個分散式存儲在後端、然後分散式緩存把所有能緩存的內容都加上去還有極為複雜的失效策略、生怕突然日PV過千萬了系統就頂不住了，卻不在乎現在日PV連一萬都不到，正是精益開發找產品方向的時候；比如說，前端工程師對頁面上各個元素的排列對不齊、間距不一致、動畫太生硬、字體不佳、特殊的設計元素未能體現等問題視而不見，卻全身心地在做自動化打包、頁面間解耦，用閉包、元編程、非同步來重構原來那些逼格不高的代碼。是的，這些傻事我們都干過。我們年輕的時候總以為把技術做好了，就能夠順利地走上人生的頂峰，卻沒有注意到絕大多數有成就的工程師都是參與了一項非常成功的產品。既使技術能力是一樣的，沒有Foxmail和微信背書的張小龍還是張小龍嗎？
怎麼解決？三個字：看，下，面！
一個能夠熟練使用html/javascript/css/xcode來實現前端效果的設計師固然優秀，但也是鳳毛麟角，工程師不能總指望設計師能夠自己搞定全部的前端效果。而設計師在photoshop繪圖的時候一定會有某些部分的內容是難以考慮到的，你怎麼讓別人在photoshop畫動畫元素的時候就能腦補出各種貝塞爾曲線的效果？你又怎麼能夠指望設計師在做過場動畫的時候對css3的各種transform了如指掌？因此想依靠設計師搞定全部設計工作，給工程師一套完整的設計圖，工程師照著設計圖一一實現，不交流、不調整、不修改、不返工，說實話，這種童話只存在於ThoughtWorks這樣的軟體工程諮詢公司的承諾里。
所以解決辦法無非兩種：
第一種是在前端再做分工，把前端邏輯實現與前端界面實現分兩個不同的角色來做，並且前端界面實現需要找審美能力較好的那個工程師，最好能夠發現其中對界面感興趣的工程師，你會發現他往往不只是被動地接受修改要求，更會主動提出你都想像不到的修改建議；第二種就是與前端約定界面調整的時間與工程量，不要一碰到問題就讓前端馬上改，而是記錄下來集中到單獨的時間段改，比如說「哥們你看你啥時候有空，我這邊整理了一些頁面上的細節問題，想找個時間跟你一起一個一個地改了」。最後一句話，既是給設計師的，也是給工程師的，那就是：首先，你要靠譜！本人整理開發的網頁遊戲研發中的UI開發流程（PSD2SWF）目的就是為了解決開發人員不願意調UI細節（對位置，調顏色等）的問題。簡要流程：1.美術在Photoshop中設計UI。2.開發跑腳本提取圖片位置，字體及顏色等信息。3.開發根據第二步提取的信息在程序中快速，高保真地實現UI。同流程也遷移到了U3D手游研發。
作為一個測試的，最不喜歡的就是UI測試。為什麼？1、大部分開發都不遵守規範，比如規定了彈出窗口的比例大致是寬：高=4:3，但是開發做出來的窗口符合這個規範的沒幾個。如果因為這個問題提了bug給開發，開發就會很不爽。尤其是對於一個完整的系統，那麼多界面，那麼多窗口，UI工程師不可能每個地方都要做出圖來，標好顏色、尺寸等，只能定規範。2、另外，界面上圖標、間距差幾個像素之類的問題，如果你提了bug，開發就會說：那麼多重要的功能你不提，你提這個做什麼？然後就是嘟嘟囔囔的鄙視。但是，大哥，現在是在做界面測試啊，又不是功能測試。3、歸根結底，是好多人不重視界面、只重視功能。好多開發只是快速的開發完功能就ok了。而界面方面的，除非是嚴重不符合基本的人機規範的，就根本不重視。
如果不考慮UI稿修改的情況，那問題 100% 出在工程師身上，審美能力不行 + 技術不行！！！
審美問題：工程師天天和代碼打交道鍛鍊出強大的邏輯思維卻因此壓制了形象思維，一個 UI 設計稿過來立刻被工程師抽象成各種概念，這裡是 Button，那裡是 Label，下面還有一大段 Text。而同樣的設計稿在設計師眼裡是顏色、線條、空間、字體以及他們之間的關係和秩序。也就是工程師看到的是抽象符號，設計師看到的是圖形。誰對呢？當然是設計師對，因為普通用戶看到的也是圖形，並從圖形中尋找自己熟悉的模式，一個圖形結構上雜亂無章的 UI 直接讓用戶跑掉。當然如果你的 App 對用戶是剛需就當我沒說。
技術問題：真以為會寫代碼就是工程師了？作為前端工程師你知道多少設計相關的知識？知道多少字體、色彩的基礎知識？知道設計師工作的時候是如何思考的么？以為他們和你一樣對一切元素都是 (x, y, width, height)？如果 UI 總是差在細節上只能說明工程師對設計語言一竅不通。UI本來就不是開發應該負責的事，而是設計和美工乾的事。
設計和美工（如果沒這倆職位那就是產品經理的事）應該把圖切好，RGB、Position、Width、Height等等全部交代清楚。不要「誒，這個給我左移過去一點點」、「這個頂欄顏色再深一點吧」
細節調整，這是設計和美工本職的事，居然把這個交給開發來調？投石問路是這樣用的嗎？先不說美工和設計在Adobe Illustrator之類的軟體上把一個控制項拉動一下，可要比開發把一個控制項準確定位到某個地方然後做出效果容易得多。開發的本職不是這個。你不能定完稿再提交給開發嘛？還是把開發當成你調試用的人形畫圖工具？畫圖工具都不會用趕緊收鋪蓋走人吧。這都不會搞什麼設計？定稿後少量的需求更改可以接受，但是把開發當成你的PhotoShop用，那你還是趕緊引咎辭職吧。做設計，UI圖連像素級布局都做不到，卻要求開發來一個個像素地調你的爛攤子。這種事我可辦不到，我會把每個地方都在UI圖上交代清楚。
你一直改需求不揍你就該偷笑了。開發需要的是「需求已經確定」，最起碼要「需求基本確定」，你整天改改改改改改改改改，哪個開發受得了？你要是UI設計做得合格，這些東西都交代得一清二楚，我不相信開發還需要再調調調。因為如果UI設計交代得清楚，要實現你這個UI只要把這些數據敲進去就行了。
而把這些數據確定下來，是設計和美工的本職。
我也喜歡精確。但是不喜歡設計師上午說在這邊，下午說在那邊。明天居然去掉了。。
設計師來回答下巴…
工作中遇到很多類似問題，基本是過不去的坎…確實浪費很多時間…
特別是開發有時候根本不看標註的也大有人在，幾十頁的ppt弄了白弄…這部分工作，我覺得應該歸類算是前端工作，其實設計師何嘗不想直接用Xcode幫開發把所有的高保真做成實際中的前端demo？客觀上需要Mac 吧？多少公司提供Mac 給設計師的？主觀上Xcode 需要學習成本，也不是分分鐘能搞定的，要是有個開發小夥伴平時還能夠現場指點下…設計師更多的時間去考慮怎樣改稿符合需求去了…被虐了千百遍，實在沒精力去搞這些工作了…當然還有其他的原因，我上來也不是吐槽，只是陳述下當前市面上設計師的普通情況…設計師還是要多面手才珍貴…這也是我奮鬥的目標…
自學Xcode 中，有大牛願意指導下不勝感激…我只能說沒遇到好的團隊或者說樓主本身做事不靠譜，目前我合作過的技術團隊都十分的盡職和有熱情。
團隊成員最好彼此欣賞、彼此充分信任、然後，最重要的一點，彼此對待工作都是站在對產品負責的角度去協同才不至於相互抱怨。
設計、產品、技術在協作的時候需要掌握一定的溝通技巧和技術，如果你本身只是一個外圍的人，盡量不要對對方的專業領域產生態度上的質疑；除非你具備甩開合作者可以獨自一個人上的能力。
另外一點，我贊成 @張克軍 的觀點——「設計的質量決定我調它的熱情」。事實上，不僅僅是設計師，產品、交互一樣面臨這個問題。如果產品經理、UI設計師、交互設計師做了足夠多的功課，輸出完善的指導性的作業，我相信絕大多數憨厚的工程師們都會儘可能還原你的想法。功課不做足導致的直接後果就是，工程師陪著設計、產品和交互通宵達旦的折騰了幾晚上，結果到頭來又推倒重來，無用功折騰個兩三回你在團隊中就喪失了基本的信譽。下次你的需求繼續過來誰願意鳥你？因為調整UI細節確實浪費工程師的時間。我們需要一些方法（比如 @vczh 答案里提到的Blend）讓真正有專業能力和承擔職責的人去做對應的事情。
建議哈~這件事情上，不要大材小用，調頁面這種事可以專門叫美工來做，他們也會很願意去做這個事情。讓fe去做更加有價值的事情。切忌把前端當成美工，這是很重要的
開發工程師大體上放好布局，細節讓美工/UI設計師自己來調整。工程師的精力更多應該放在開發上，但是必須花力氣來教美工怎麼用各種開發工具，怎麼調整參數。
我不同意，難道是因為目前還沒上手大項目？
我只知道目前手上負責的一個模塊我真的是仔細調整了很多margin，而且都是dip級別的。設計師和工程師是天生的「敵人」，究其本質，這是任何產品展現和實現之間的矛盾，設計師強一點，展現強一點，工程師強一點，實現強一點。
推薦閱讀：
※專業前端和偽前端的區別？
※關於ECMAScript5官方文檔中執行環境的組成中詞法環境和變數環境的區別？
※怎麼梳理大量複雜的知識內容？
※有哪些炫酷的sublime text3 主題？
※成為一個全棧工程師是一種什麼體驗？