開發人員拒絕按照 UI 標註還原設計，如何讓他理解精確還原的重要性，從而去修改代碼？
當一個開發工程師屢次發問「這裡讓我移1px有什麼意義，我為什麼要浪費時間這麼做」且拒絕修改時，如何讓這位開發理解、認識到修改的重要性？
為什麼國內很多視覺設計師得為了那些雖然看起來很細碎、甚至可謂之雞毛蒜皮——但對於設計師還是很重要——的細節追著工程師去修改，一項項列出問題，卻得不到工程師正面的回應？舉個例子，聽同事介紹過 Frog 的工程師會為了不影響視覺設計師工作，自己開發出檢查設計還原的軟體進行還原檢查修改。
是什麼背後的原因另產品的設計實現這麼困難？是因為設計師不懂代碼？部分技術人員的審美意識？還是大廠心態或者其他什麼原因？這種狀況怎麼解決？到什麼時代或是契機才能夠被解決？
作為見慣了遊戲公司策劃、程序、美術上演三國演義的人，題主所說的問題都太稀鬆平常了，我來終結這個問題吧。
首先回答問題，程序員不配合，90%以上的情況是需求人員工作不到位。
=================================目錄
- 像素這樣的細節是否重要？
- 為什麼程序員不願意修改？
- 產品人員該如何解決？
- 程序主管應該做什麼？
=================================
一、像素這樣的細節是否重要？
產品人員，一定要了解1個像素在不同情況下，重要程度是不同的，這是你是否要去找程序員修改的大前提。比如
1，產品戰略層面是否重視體驗？
公司是技術驅動，設計驅動還是市場驅動？這款產品是面向什麼用戶的？這直接決定了細節在產品中的重要程度。不知道題主所在公司情況，就直接告訴題主「體驗為王」或「設計師工作是可選的」，這樣真的好嗎？
於UIUE的重要程度，絕大多數情況下，企業軟體&<專業工具&<大眾產品。
舉個例子，我老東家金山的後台管理系統，爛的簡直讓人髮指，別說易用了，連能用都達不到，不讓你撤銷重填就算謝天謝地了，可用了多年也沒換過。你說1像素重要嗎？對於很多企業用戶來說，企業軟體最重要的是安全、易於部署、維護和擴展，而不是UI是否好看/UE是否完美。所以如果你是做這種產品的UI設計師，長時間糾結1像素被鄙視也是稀鬆平常的。
而對於像Zaker這樣的大眾產品，在底層技術能夠到位的情況下，用戶體驗就成了極其重要的一環。任何UI無法對齊、圖標大了4個像素、出現「iphone」這樣的文字、配色有些爛俗的情況，都會讓用戶認為「這個產品比較山寨」，「用著有點彆扭」的感覺，直接會造成流失/評價下跌。我想，用過知乎iPhone和安卓客戶端的人一定深有體會。
2，細節在應用層面的重要程度如何？
同樣是1個像素，在不同地方是有不同效果的，不能直接就說重要還是不重要。舉個例子
【我的收藏】前面的圖標，如果往左挪1個像素，你覺得怎麼樣？
我的頭像這張圖和名字，如果整體往左挪1個像素，你覺得怎麼樣？
我想，大多數人都會同意，第一條更不能忍。也就是說同樣的細節，是否重要一定要看它所處的環境，必須具體問題具體分析。對於任何提需求的人，都要自己先搞清楚，再灌輸給製作的人，不能一股腦全都丟過去。
3，項目進度和優先順序是否允許？
一根筋，是絕大多數新的策劃產品設計人員最常犯的毛病。他們分不清楚輕重緩急，總是抱著「我是為產品好」的想法去做不合適的事。
舉個例子，一個遊戲出現刷錢的嚴重bug，運營要求1小時必須解決。在你的眼裡，順便調整1像素，也就是調一下坐標的事，沒什麼難的。但在程序員眼裡，這代表著要重新編譯、打包上傳，會極大增加出問題的風險。哪怕前端程序員沒有工作，你也不能去找他改這1像素。這個時候，1像素絕對是無足輕重的。
而當你記下這個需求，等發版以後，程序們有時間開發時再提交，這1像素就有可能重要了。
二、為什麼程序員不願意修改？
這一點上，我要為程序員們喊冤。絕大多數情況下，都是需求提供人員自己本身沒有做到位（大部分情況是極不到位）。包括但不限於以下情況
1、需求提的不明確有明顯問題
2、需求人員平時沒有展示出足夠的產品能力，造成無法讓人信服
3、需求人員極少給程序人員灌輸細節的重要性
4、加班時沒給程序買可樂
5、……
程序員們，大多數都是非常單純的人，沒有那麼多花花腸子，很少有故意給你臉色、撂挑子的情況。只是有些時候他們會一根筋，只要你足夠專業，勤於溝通，一般都沒有問題。所以
是因為設計師不懂代碼？部分技術人員的審美意識？還是大廠心態或者其他什麼原因？這種狀況怎麼解決？到什麼時代或是契機才能夠被解決？
這種抱怨的話少提，與人方便自己方便，自己既然是提需求的人，就要多為對方考慮。
三、產品人員該如何解決？
假設真的出了問題，我們該如何面對？首先要尋找原因，是自己沒做到位，還是對方沒理解你的想法，還是單純瞅你不順眼？假設是1和2，那我們要做到
1，先搞清產品戰略。
自己弄明白這1像素細節是否對產品有足夠的重要性。如果不重要，那請把工作中心轉移到重要的事情上。
2，絕對自己把該做的事情先做好。
這裡邊包括自己先弄明白修改的意義，畫好標註色值、像素的示意圖和文檔，做好產品原型等任何能讓對方不需糾結，直接可以上手的工作。自己的專業、努力是贏得程序員尊重的前提，贏得他們的尊重你才能順利開展工作。
我以前給策劃審文檔，一個3頁的doc我打回去過7遍，改了幾天，最後才到程序員那裡開始執行。雖然還是有些問題，但至少程序看到了這個策劃的努力。你想想一下，如果不審核就發給程序，程序會不會拿刀砍人？
3，弄清進度和優先順序，弄清對方手頭工作
在搞清楚產品進度、優先順序的情況下，尤其要注意一點：「絕對不要想到一個需求就跑過去要求程序改！」
程序也是人，很可能正在苦思一個重要問題時，你跑過來打斷他的思路，還是用在他看來毫無價值的需求，更糟糕的是你直接要求他放下自己的工作，立即修改，是個程序員都會爆掉的。別說是程序員，要你你也受不了。
好的方法是記錄所有需求，自己標記優先順序，定期（每天定時）跟程序員溝通，跟他一起制定解決方案和時間。記住不要替他做主！他不是你的下級！他是幫助你的夥伴！
4，私下給老闆和程序員不斷灌輸用戶體驗的重要性
這是很多人經常疏漏的地方。每個人的思維模式都不同，你不能要求別人也按照你的思維模式來看待問題。想要讓大家認同你的看法，就要在平常不斷的潛移默化影響別人。比如沒事多跟公司其他人聊產品，聊體驗，聊感受，慢慢給他們灌輸體驗的重要性。只要你的話題有趣，人有趣，沒有人會拒絕跟你聊，時間長了，整個團隊的思路就會有所轉變。
說個小技巧。程序員大多比較孤高，如果你想讓他改什麼，你可以有意無意的跟他說，你覺得某個跟你們很像的產品某個體驗做的很好，你不知道怎麼實現的，一定要擺出一臉羨慕的樣子，說他們太牛逼了。你們程序員一定會一臉鄙夷的看著你，說這破玩意有啥難的？老子半天搞定，絕對比他強百倍。多吹捧吹捧，你的目的就達到了，你倆都挺爽，是不是不錯？
5，搞好同事關係
程序員加班多，偶爾在他們加班時買瓶可樂，裝作一臉坦然的放到他桌子上，他就算嘴上不說，心裡也會感激你的。這不是歪門邪道，而是人之常情。社會上你上哪去找一瓶可樂就可以買通的朋友去？
如果還不管用，請用這張圖詛咒他
如果你都做好上面5點，對方還無理由拒絕，那問題就不在你這邊，也不是你一個人能解決的了。請找你們共同的主管（比如項目經理），三人一起當面溝通，為什麼會出現類似的情況，要有不解決我就拉你們住在會議室的決心。絕大多數情況下，你是能聽到程序員告訴你為什麼他會不配合的。
切忌私下找對方上級。職場上任何時候，都要做到我對你說的話，對別人都敢說，千萬不要做背後議論，抱怨，捅刀子的人。
如果你已經做到位，還是無法解決，那不是這個程序員的問題，就是你們主管的問題，請考慮換工作吧。
四、程序主管應該做什麼？
這一條是我看了排名第一CTO的同學，有感而發。同樣作為管理人員，我堅信沒有任何一個工種是「可選」的。絕大多數產品，無法單靠某一類人就能做到100%的極致，再好的產品也有改進空間。而這個改進空間，無法靠設計者自己解決，需要藉助外力。所以我不認為產品人員不給力，就可以把他們邊緣化。
我自己是策划出身，如果我是這個公司的CTO的話，我想我會從下面幾個角度讓程序和產品人員更好合作。
1， 不斷給團隊灌輸產品為先。
我們每一個人，都是為了這款產品的成功而努力。在這裡面，每個人的工作都是為了產品成功負責，而不是誰是做什麼的，誰專業不專業。只要能夠讓產品質量提高，任何提出的方案、修改都是可以討論的，即使進度不允許，也可以記錄下來。
讓團隊每一個人不再關注自己的角色（策劃、程序、美術）、職位，改為關注產品本身，是我的職責所在。
2，抓好培訓。提供工具。
抓好培訓：為程序人員培訓產品的意識。為產品人員培訓開發的流程與經驗。不求互相替代，只要能兩撥人能互相理解，能從對方角度考慮問題就夠了。
提供工具：為產品人員提供更好的開發、設計工具，能夠讓需求從設計者到開發者之間，盡量少出現因溝通產生的歧義。
3， 制定規範和流程
包括需求製作規範、文檔規範、開發流程、需求變更規範等等，減少項目中因人的因素帶來的不可控。
4，搞好團隊建設和人際關係，儘早解決問題。
打破工種的圈子，一起出去吃個飯，打個球，其樂融融多好。
總結一下吧，程序員不配合，不用找那麼多理由，大多數情況是需求人員沒做到位，請繼續修鍊自己的專業能力和人際關係。
我愛程序員！
要改東西可以，但是你必須寫下來
改需求文檔也好，寫到bug記錄里也好，最差也得寫個郵件來
如果只是口頭上說要改這改那的話，不管你說得多有道理，那都是能不動就不動的
就算老闆問起來，就說「這地方文檔上就是這樣寫的」
先交代：我是開發。
________________________________________________
題主你好，你很有追求，這讓我看重你，1px我也認為很重要，一般情況下我也會努力去調，但我接下來是要來吐槽的。
________________________________________________
1. 不懂平台特性
比如2x圖切成45px寬度，這樣的圖到了我手裡，我還得用打開Fireworks用九宮格給你縮放一遍，後來第二天設計師調了下顏色，再次發了一個45px的圖給我......尼瑪！對這樣的設計師，我挺鄙視的。
然後搞笑的來了，視覺驗收的時候，設計師跑過來說：你這裡少了（多了）一像素哎，要不你改改！
改你妹！
2. 畫圖沒追求
這裡的畫圖沒追求不是說設計師畫得不好看，設計師們的設計能力當然是不容質疑的。我說的是虛邊的問題，求求你們最後切圖之前，把所有的虛邊都幹掉好么，這個我真是完全不能忍，每次拿到一堆圖的時候，我都要挨個看看有沒有虛邊，有一點點都要自己P掉，很累的！
明明一個很漂亮的設計，因為虛邊的存在，最終效果看上去要變得有點臟髒的感覺，你怎麼能忍？
3. 切圖沒追求
比如切個圖標，明明是純色，他非得用jpg格式導出，結果就是一片臟顏色（jpg壓縮演算法導致），而且圖片還很大，非得逼我自己再找到PSD導出一個gif或者png格式，做圖的追求要有，切圖的追求也要有啊親！
還有些設計師，切圖的時候從來不考慮大小，統統清一色PNG32位色，明明用jpg能減少到十分之一大小的你不調整一下，逼我給你調……調一次就算了，第二天你改了個色調再發個PNG32位的給我，你奶奶的！
4. 對動態效果沒有任何想像力
國內設計師們目前對AE、QC之類的軟體應用得很少，結果就是部分想像力弱的設計師對動畫效果完全沒有把握，事先說了一個效果，然後你啪啪啪寫了一天的代碼做出來了，他看了下：不太好看，要不你這裡調一下那裡調一下。
後來乾脆搬個凳子做你旁邊看你挨個調參數，把你當成語音輸入智能機器人幫他調動畫……這樣的設計師我不能忍啊！要不你老實學AE去，要麼你自己腦洞大開在腦海中補全動畫。別把我當你的免費勞動力啊哥哥，我還有好多活要干啊！！！
5. 不尊重公共控制項的已有特性
比如某個按鈕，UI指導規範里高度就定死了是50像素，然後設計師來了，擺弄半天：我們這裡調成60像素吧這樣好看一點。
對這樣的設計，我想對設計師說：軟體或網站不是單個平面設計，它是一個有機整體，用戶感覺我們產品的時候，從來不會把它割裂成幾個部分來看，它是統一而且和諧的，它應該有統一而和諧的美感。
是么，親？當一個開發工程師屢次發問「這裡讓我移1px有什麼意義，我為什麼要浪費時間這麼做」
要我說的話，這種事情根本就不是開發人員該做的事情啊，設計師出東西後直接給美工就好啦，我說的是那種會出頁面的美工，而不是那種只給開發人員一堆圖讓開發自己拼的美工，後一種我覺得根本不是美工。
美工根據設計師的設計出一個版面給開發人員，然後開發直接綁好數據就完事了。頁面怎麼改跟人家有一毛錢關係嗎？
設計和實現UI從來都不是開發人員的工作，他們只管實現功能就好了！現在開發真的很難做，很多美工的活都給開發做，根本不是干這個的，調頁面調樣式簡直能調得人想殺人！是團隊的運作方式和工藝標準出現了問題，不是設計師的問題也不是程序員的問題。
首先，團隊的負責人有責任制定並貫徹執行產品的工藝標準，比如是否做到像素級還原度。
其次，當產品實現過程中出現工藝和實現成本的矛盾時，團隊的負責人有必要收集各方面參與者的建議，做出綜合評判，決定向工藝妥協還是向成本妥協。比如實現Web頁面的UI時，程序員可能會遇到實現像素級還原度的時候有瀏覽器兼容難題，需要花大量時間研究問題原因，但是項目進度不允許花太多時間做研究的矛盾情況。
做一個好產品，每一個參與者都很重要，誰也代替不了誰，以誰工作重要來評判一個事情做或不做而不是以事實說話以道理服人，很容易會培育出勾心鬥角的團隊氛圍，人心散了團隊也就不好帶了，事情也就做不好了。
想想巴別塔的教訓吧。UI工程師應該完成整個UI的設計、維護工作，不應涉及代碼邏輯。
正常情況下，應該是：
1、由交互設計師設計交互流程及每個頁面的元素
2、由美術設計師決定最終呈現給用戶的東西
3、由UI設計師和美術設計師共同實現UI
4、由開發人員就著完成的UI填寫邏輯
其中，1、2、3可以兼職且最好能由一個人或一個團隊兼顧全部；其中的2和3聯繫更為緊密，不是特大項目，最好由一人完成，否則需要的交流太多，效率過低。
按樓主描述，他們似乎是美術設計師兼職1、2，開發兼職3、4，這種分工顯然是最容易出問題的：因為它割裂了聯繫緊密的2和3，又把本該分開的3和4交於一人。這就導致做任務2的，隨便有點雞毛蒜皮的小事都必須去推動任務3的執行者，而任務3的執行又會耽誤顯然更偏技術、因而被技術人員看成本職工作的任務4，從而鬧出矛盾。
尤其是當美術設計師只會PS、且雙方缺乏溝通時，極其容易動輒出現「小小的調整」，實則導致UI實現者耗費極大的精力才能跟上的問題；當3和4是一人執行時，這些小而麻煩、毫無成就感的調整，顯然極易惹人反感，因為4才是開發人員的核心價值；但，這些瑣碎的調整呢，偏偏又是任務2的核心成果。
——甲的價值要靠推動乙做很多事才能體現、而做這些事卻會耽誤乙去做體現自己價值的其他事：這倆人要不打起來，才真叫怪了。
此外，一個有職業素質的程序員，可以忍受「一次開發中換了幾十個界面版本」，但絕對無法忍受「一次開發中三天兩頭出現口頭調整」，哪怕這種調整加起來也只有十多次：因為前者是有計劃的，心理上有準備，工作上有安排；而前者呢——你這三天幹了什麼？答：聽美工的，把x個元素右移了一個像素，然後又移回去了……
——————————————————————————————————
現在有很多框架支持用XML描述UI，使得UI布局和程序代碼完全脫鉤（除了諸如文本框、輸入框的命名：程序代碼需要根據這個命名決定顯示內容）；有些工具，如微軟的wpf，甚至可以支持用XML直接描述動畫（包括交互動畫）。
建議選用這類框架，讓UI設計師直接用這類界面設計工具設計界面，這樣就可以保證界面最終效果一絲不變。
————————————————————————————————
如果由於平台、語言之類限制，無法使用這類UI工具，那麼仍然建議UI設計師用程序員使用的界面設計工具設計界面，或者至少要對程序員使用的工具有較為充分的了解，能夠在用PS做設計的同時，想到這個效果用程序員的UI工具如何實現。
這是因為，除了早期的IOS平台（在那個幸福時期，只需考慮一到兩個解析度以及這個解析度下的橫豎兩種布局即可），除非固定窗口大小（在屏幕周圍留一圈空白），否則在不同設備上，最終解析度總是千變萬化的。
為了應付這種情況，很多UI工具優先推薦使用相對數值而不是絕對像素數（比如，一個標籤寬度應設置為全屏的1/9，而不是130個像素）、並可設置縮放時，哪些元素尺寸不變（如輸入框之類）、哪些元素應按比例縮放（如兩個輸入框之間的留白）……
此外，哪怕是按絕對像素數做UI設計，你也要知道，UI工具大都是以「矩形容器中套表格（grid）、表格中套矩形容器」的方式布局（html用的div元素+css是另一個思路）——換句話說，某個元素右移一個像素，很可能並不是簡單的設置某個數字，而是要先刪除它，然後在它原本所在的表格中套一個一行兩列的表格，並把新表格第一列的寬度固定為1個像素、並在第一列中放一個和背景色一樣的平板元素、再把原先的元素放到新表格第二列、並至少還原它原來的命名：這就是「右移一個像素」這個簡單操作背後的東西。
而且，這還是最簡單的情況。因為有些時候，由於「表格套表格」式的布局所致，界面上的元素樹會非常複雜，調整一個元素的位置，可能引起一大堆元素的變動。
比如，我早期曾遇到過UI設計師想在自畫標題欄下面加一條線；而這就需要在界面的根表格中插入一行；而我用的界面設計工具並不支持在表格的指定位置插入一行，所以只能在最下插一行，然後把標題欄下面的所有元素全部往下移動一格。當時沒經驗，下面幾十個元素和自畫標題欄一起放在同一個頂級表格里，於是只好一個個剪切/粘帖；而且那個工具只能撤銷有限步，一旦有一下弄錯了沒注意到，已經弄好的一堆元素就只能重做——最終，插這一條線插了3、4個小時(更簡便但會給以後帶來麻煩的方法是：先移除標題，放一個兩行一列的容器；然後在容器第一行放標題，第二行放那條線——但這會改變元素樹的結構，給將來維護帶來困擾；更合理的辦法是一開始就做好規劃，先用兩行一列的表格劃分標題區和內容區，然後再分門別類安排各元素在樹上的位置)。
當然，某些UI工具可能的確能做到「簡單設置一個數字」就完成元素右移（換句話說，它要支持單獨設置左填充/對齊屬性）：但你需要事先確認這一點——這也是要求UI設計師用程序員的工具而不是PS的原因之一。
————————————————————————————
從你的描述來看，如果只是改一個數字就能改變一個像素的對齊狀態，程序員不會選擇磨嘴皮子。反之，你動一個像素，在他那裡就需要這麼一個繁瑣的流程，並且這種改動較為頻繁，這才會激起反感。
對這種情景，就必須嚴格控制流程，每次UI修改都必須有版本號，不能很隨意的今天這裡加一點明天那裡減一點（就好像軟體版本一樣，不能隨意修改），不然界面元素會越搞越複雜，越來越不可維護——要做到這點，UI設計師就必須會用程序員的UI設計工具，對PS出來的東西用grid表現出來後的狀態有所預料（包括更換桌面主題後，標準元素風格、配色等方面的改變），不能等看到實現後才去糾正。
題主提到「Frog 的工程師會為了不影響視覺設計師工作，自己開發出檢查設計還原的軟體進行還原檢查修改」，這其實已經說明他們是有界面版本管理的、且最終的UI和視覺工程師不一致將作為bug處理。
另外，請注意他們是做遊戲的。
遊戲UI設計和通用軟體UI設計是兩碼事，後者可利用的工具/特性比前者差得多得多：遊戲UI可以做到你畫什麼他就做出什麼、且沒有其它界面描述工具，只能PS；而通用軟體UI想要突破grid的限制，就必須付出額外代價，但可以使用PS外的手段直接描述UI——換句話說，遊戲UI存在一個從PS翻譯的過程，所以需要檢查這個過程的bug；而合理的通用軟體UI開發並不需要這個翻譯過程，硬往裡面插這個過程實屬畫蛇添足。
——————————————————————————
無論如何，只有UI設計師熟悉了程序員的工具，他才可能做出真正切合實際、並且經得住後續修改的設計；也只有他熟悉了程序員的工具，才會知道自己需要在什麼地方、如何標註，才能得到自己想要的效果。
從很樸素的角度看：如果連你自己都說不出這 1px 的「重要性」，需要來知乎求答案，那麼大概確實就是不重要吧。
舉個栗子，以下說法是沒有用的：- 你現在這樣不好看。（不好看只是你的主觀意見，每個人的審美不同。當然你也可以搬出「你是設計師還是我是設計師？」這句話，程序員也沒辦法，但是不服氣。）
- 往下移 1px 很難嗎？工作量很大嗎？（這不構成移動的理由：我有能力自殺，不代表我現在就要自殺給你看。）
能讓程序員心服口服的解釋應該基於客觀事實（至少聽上去應該是），類似於：
- 要是往下移 1px 的話，整體就符合黃金分割比例了。這是我設計的精華所在！
- 你看其它高度都是偶數，就你這是奇數，往下移 1px 唄～
- 不往下移 1px，第二屏的圖片就會冒到第一屏來，看上去像 1px 的邊框。
不過話說回來，理論上 1px 應該不會有太大阻力，大概是改得太頻繁了吧。
暈，怎麼都是噴設計師的。
作為一個飽受折磨的苦逼程序員表示，遇到一個要求到1px級設計還原（並且更重要的是給了標註）有輕度強迫症的設計師是一件多麼幸福的事，這意味著不用為邊距寬高之類的尺寸糾結，不用開了畫圖工具量像素抓顏色值，不用在邊距39而不是40的時候戰戰兢兢的（頂著專業的壓力）去問設計師可不可以多加一個像素，不用在兩個控制項不對齊時同樣戰戰兢兢的找設計師確認是不是「設計如此」，不用一邊罵娘一邊給設計師擦屁股，也不用擔心把成品丟給設計師做還原審核時設計師根本就不看最後出了問題老大卻跑來敲打程序員的狗血劇情，……
回到問題，題主先跟我默念三遍：
「這是個特例，不要一棒子打翻所有程序員」
「這是個特例，不要一棒子打翻所有程序員」
「這是個特例，不要一棒子打翻所有程序員」
好了，心態調整好了，下面開始分析問題：
1. 我合作過的所有程序員都這麼固執嗎？
2. 這個程序員對別的設計師也這樣嗎？
3. 這個程序員一貫如此？
如果問題1的答案是只有這一個，恭喜你遇到一個特例，請繼續後面的問題；如果答案是每個程序員都如此，那麼更要恭喜你，你自己是個特例，後面的問題不用看了，趕快反省自己，性格呀言談啊什麼的，否則，親娘咧，可能會影響仕途噢。
繼續問題，如果這個程序員是特例並且對所有的設計師都這樣並且一貫如此，那麼很可能他性格如此，那麼繼續溝，軟的不行就來硬的，找產品經理或者上級領導；如果這個程序員只是對你如此，那麼很可能是他瞅你不爽，僅此而已，如果你是個女孩子，那麼再次恭喜你，有人愛上你了。
再次回到問題，這裡才是真正的答案：
產品經理去哪兒了？這種事情本應該產品經理管的。
正確的工作流程是這樣：設計師發現問題，告訴開發修改 --&> 開發拒絕，發生爭議 --&> 找產品經理仲裁
補充兩點：1. 如果開發給出了拒絕的理由，請慎重對待；
2. 這種修改實現起來非常簡單，和你在PS中做同樣的修改差不多，不要被開發忽悠了；
前提：
暫且不談設計師設計水平、程序員的研發能力，假定這兩者的都質量可控、工作輸出穩定，我們來聊聊這個問題。
觀點：
一個完整的產品，UI 和 代碼同樣重要，不存在所謂可選與必選。
態度：
研發同學講「代碼如詩」、看《黑客與畫家》、注重代碼風格、編輯器Vim or Emacs爭半天、Coding 時編輯器要選酷炫叼咋天Dark界面、代碼要對齊、甚至連個變數命名都要想半天... 這股鑽研勁兒、追求更好甚至完美的自我要求的追求勁兒，怎麼到 UI 這塊兒就消失掉了？
你們是愛美的，嗯。不然怎麼會看著Alienware、RMBP、騷尼、Thinkpad眼饞？他們配置固然高，但如果沒有那騷氣外露的工業設計、透著濃濃 Geek 范兒的樣子，你還會對他趨之若鶩么？
如果說代碼體現了產品的內在美，那外在美肯定要考 UI（含UE）體現了。地鐵上遇見個美女，你會跑過去問「你內在美么? "（千萬別去問啊），如果答案否定，難道你就因此屏氣凝神作清高狀、誓死也不再多看她一眼？
面對你喜愛的產品，你拚命追求內在美（性能、配置...）、但也絕不放過外觀，不然就不會狂吐槽iPhone 6白帶異長了。但到了自己寫代碼、做產品，怎麼就覺得UI 是「可選」的呢？
所謂可選、必選，甚至高優先順序、低優先順序的 濫用，讓我們分清主次的同時也喪失了追求和完美。
場景：
「... ...」
「你這個東西效果一般，做出來又太耗性能，我看沒啥必要」
「差不多就可以了，默認的控制項不支持你這個東西，自己開發太費時間」
「... ...」
拋開具體工作時的研發性價比，單說對待這些事兒的態度：
我們要的不就是又好看、性能又棒么？
這些問題不就是我們需要解決的么？
如果所有問題都很好解決，那「追求」還有啥價值？
對了，我是產品汪——程序員和設計師的好基友
hi 你好 設計師
剛開始時候我在一家小有名氣的私企公司 ，在那裡UI設計師得不到尊重 ，我被稱為「美工」，當然不僅是因為這個稱呼。除了做交互原型設計、視覺設計，我還要把視覺設計做成HTML+CSS頁面,有時候還要用JS寫多級菜單，滑鼠點擊的交互效果，這些開發和項目經理們稱為"切圖「，並且只是隨口說一聲」你把圖切一下「。而我的薪水只有開發人員的一半。
與其他」美工「非常厭惡切圖工作不同的是，我還是挺喜歡用HTML+CSS寫頁面的工作，因為相比交互設計和視覺設計，這真的幾乎不用去思考創作，對我是一種休息。用Jquery寫交互效果也是挺有意思的，我在css3,html5還未流行時就開始嘗試一些效果，我還記得發現加入perspective屬性後呈現的3d動畫效果讓我欣喜。
反過來，我開始用這些效果包裝我的交互和視覺設計，我不會發送一包jpeg文件給項目經理或者開發，而是做一個完整的交互效果，也許是PPT，也許是視頻，也許是有動畫效果的頁面，邀請他們來會議室看我demo，告訴他們我為什麼要這麼設計。我發現這樣真的很棒，除了讓我的溝通能力越來越好，我的設計也不會被要求改來改去。
但這裡依舊是一家以項目和開發為主導的公司，開發決定著項目周期，其他只是附庸，我的薪水沒有顯著提高。後來一家50強外企找到了我。這在里所有人都叫我設計師啦藝術家啦，再也聽不到美工。在這裡UI設計和程序員之間，還有前端開發工程師.他們是一群很可愛的人，比我還沉溺在那些前端技術中。並且由於我很熟悉前端技術，與他們溝通總是那麼愉快，這也許是因為我在做UI和視覺設計時，就會考慮這個效果能不能實現，用什麼代碼實現。我與前端溝通這個效果怎麼做時，他們會說，啊你這樣寫可以，但是效率不高，這樣寫更好。更大的不同是，我發現在這邊，我更多時間會花在溝通上，和那些老外BOSS聊聊他們想要什麼並且為什麼我會設計成那樣，真的很廢時間，也許是我的英語還很爛吧。但是這些老外BOSS都拍板了，程序員就不會說這個不好做改來改去啦。相比之前工作大部分時間都一直低頭用axure,PS,還是挺不適應的，但是我想一個high level的UI,本身就應該是一個interface,不是嗎？對了，這邊薪水也不錯，攢兩年的錢，就可以買一輛寶馬了。
本故事純屬虛構.........我是一名程序員，沒有女朋友！
說實話我覺得第一點原因可能是，題主是個很不好溝通的人。
這是看題主的問題描述之後我的第一感覺，當然如果題主是人見人愛花見花開就當我沒說，不過如果真的這樣這1px可能早就改了吧XD
問題描述不算短，但是卻基本沒有什麼有用信息可以讓人回答。
比如說，你「無數次」提出改1px，你也沒說清楚是同一個地方你反覆要求但是沒改，還是很多不同的地方你要求了沒改，還是同一個地方你今天要求多1px明天要求少1px，還是很多不同的地方你今天要求多1px明天要求少1px，要知道這幾種情況程序員的怒氣槽長度會差很多。
再比如說，你絲毫沒有提供這個程序員修改一下需要多少時間，他有多少事情需要做，他的進度安排，你們的東西有沒有定死的上市日期，其實半年後上架他只負責UI然後改1px只要五秒鐘和一周後上架他除了UI還要負責寫出整個程序而改1px需要半小時程序員的怒氣槽長度也會差很多。
再比如說，你自己也沒說清楚你具體提的是什麼修改建議，為啥要這麼改，你給他的是ps的還是什麼，他用的是什麼工具的，只說個1px，讓大家猜么？
最後，你自己的描述里都沒有給自己改1px提出理由，提出重要性，第二三段就開始抒情和泛泛而談了，還扯出啥審美意識，大廠心態。
第二點原因是，活忙不過來。
就好比我上面說的，「一周後上架他除了UI還要負責寫出整個程序而改1px需要半小時」，這種情況下我只能說，你需要讓步，沒啥好溝通的。
第三點原因，大概可以開始扯情懷和審美了，這個我就不扯了。
真的是舉手之勞，大家都是同事，那也不會故意為難你。但是我有個deadline壓著，一堆事情要做，你還龜毛的一會兒1px一會兒2px的，也說不出啥理由，那就別中斷我的正事。
否則你自己去和產品經理說去，為了1px晚上架你試試。
其實多數情況下和大廠，審美沒啥關係，人家就是忙。
我也是個程序猿，而且是做前端的，我完全明白有時候調1px是沒有必要的。
但是，有時候差1px就是非常的噁心！
比如騰訊QQ，首先在右邊隱藏時頂部居然剩下1px，太難看了！
再就是雙屏下，全屏聊天窗口時，居然會在另一個屏幕多出1px！！
有時即使是1px，也不能忍！
（剛發布新版時我就給騰訊發反饋了，但是卻一直沒有改進）
不願意改的原因有幾條
1、你的設計稿可能出的太晚了，哥們代碼都寫完了，你告訴我要返工！！！要返工！！！要返工！！！重要的事情說三遍。
2、你的設計稿，可能不符合APP UI規範或者系統控制項規範，哥們要自定義！！！自定義！！！自定義！！！重要的事情說三遍。
3、你的設計稿，可能沒個標準，同樣的東西這個10像素，那個12像素，沒法復用，到處是補丁。不優雅！！！不優雅！！！不優雅！！！重要的事情說三遍。
4、你的設計稿，標註基於一塊屏幕且單位全是像素，哥們得考慮換算各種屏幕，各種字體。哥們沒空算！！！沒空算！！！沒空算！！！重要的事情說三遍。
5、你的設計稿，可能自個都沒想好，哥們要陪試錯！！！陪試錯！！！陪試錯！！！重要的事情說三遍。
曾經就這個問題 問了公司的開發 最後開發告訴我答案。如果整天摳像素是一件很low的事情 開發們眼裡 覺得高大上的事情 是如何寫出碉堡了的代碼 用了什麼最新的技術 頁面因為自己的努力載入速度減少了多少毫秒 這才是王道
Google的logo前段時間還改了1px呢，噴題主的啥心態。
我的世界裡，沒有設計師這個物種。
開發人員要具備基本的審美能力。
這種「審美」不是天馬行空的抽象的，
而是在符合平台UI規範的前提下、具備一點設計常識、從業務邏輯和使用者角度去考慮你的軟體該是什麼樣子。
這樣的話，你就可以很明確地給個spec要求美工，不要讓他人為你的懶惰買單。
好多修改問題涉及的都不是開發人員的做事態度和價值觀與設計師不一致的問題，而是真金白銀的需要加班熬夜爆肝的問題。
複雜嵌套動態拼接頁面的最後的一個像素的調整成本，到底是第一個像素調整的100倍還是1000倍，怎樣讓用到這個界面元件的剩下一堆頁面都不會因為這次調整出問題，涉及的工作量程序員自己心裡可能都沒底，只能硬著頭皮往坑裡跳。「完美的動畫效果」和「離完美只差了一點點的動畫效果」之間的距離可能是相關代碼推翻了重寫一遍，還會得到「這麼點事情怎麼會需要弄這麼久」的風評，非直接執行人肯定都是按線性估算成本的，這是人性。
所以程序員主導的產品都喜歡極簡風格，按鈕上過渡色都不想放，真心不是因為他們品位差，而是只有這種模式里，他們的效率和執行力才能跟外界的心理模型相一致，他們才不會看起來笨拙遲鈍自大蠻橫又牢騷滿腹。大多數程序員無法看出下面這兩個按鈕上的文字有什麼不同的。
對UI有點感覺的程序員會說下面的文字整體上短了點。（猜猜短了幾個像素？4個。）這是其中一點。
還有一點是字體渲染效果上的差異（不是字體不是字型大小，而僅僅是渲染的差異），我相信絕大多數設計人員應該一眼就可以看出這個區別。更不用說在設計人員眼中，一個像素的差別簡直是扎眼，簡直是不能忍。
設計人員與程序員對UI上的敏感度就不在一個數量級上。設計人員可以看到次像素級的差別，而程序員多數是超像素級的。這是數量級的技能差，不是靠說服教育能拉平的。
多數情況下，程序員不是不想做，而是他真的感覺不到差別。你讓他改一個像素的偏移，在他眼中與做無用功沒有太大的區別，一不小心就觸發了程序員的嘲諷技能，搞得兩邊兒都不高興。
回到問題上，如果想把UI做好，需要三個角色：
Designer: 設計者，一切界面與交互的原型設計，包括每個狀態的變化與動畫。
Integrator: 將設計者設計的原畫級的原稿轉化成程序員可以直接使用的資源。這個人要有與設計者一致的UI敏感度，並熟悉程序要使用的軟體技術。
Developer: 直接使用Integrator提供的資源完成開發。從此不用和設計者扯皮。
設計師為什麼會追著技術人員改1px？
因為最後的結果拿出來差了1px，設計師他事先不知道啊，事先大家沒定好，結果又不能接受，當然要追著改。
表面看似是有沒有必要的問題或者程序員和設計師的觀念衝突，其實是做事的方法和態度問題。
開發人員正式接收設計稿以後，如果沒有提出異議，那麼就相當於作出一個承諾，會交付一個符合設計稿的東西。
如果你覺得有問題，當場提出來；或者說回去琢磨一下提出來；實在經驗不足，判斷不出來，提前聲明一下哪裡可能有問題，做的過程中提出來也可以。就算是開發人員覺得有更漂亮更合適的方案，也是先拿出來大家看一下：沒問題我們就這麼做了。
注意一定是技術人員主動提，不是做完了交付以後被揪出來。
如果UI給你的時候，沒有提出異議，最後交付出來的程序不符合UI，又沒有更美觀。
這就好比一個功能開工的時候跟別人吹牛逼拍胸脯說沒問題，到要交付的時候拿個半成品。
說不定還有各種理由，神馬環境有問題，神馬誰誰不配合。
到了最後交付的時候，被別人揪出來這裡不對那裡不對。這說明什麼？
這說明
1、開發之前心裡沒譜，最後做成什麼樣子不知道，最後儘力只能做成這樣，這是水平問題；
2、知道有問題，提前不講，隨便做做，差不多就好，這是態度問題，所謂做事不靠譜，就是這麼個情況。
評價一個優秀的技術人員，最基礎的其實就兩條，第一是技術水平高，第二是做事靠得住。
技術水平再高，需要他的時候全不行，關鍵時刻凈軟蛋，那也是沒用的。
優秀的工程師怎麼做事？
工程師拿到設計稿，看完了叫來設計師和產品經理說，這個設計實現總共需要5人日，其中A地方設計複雜，光實現這個需要1人日，如果改成XX則可以減少1人日；B地方會增加GPU20%的消耗，極端不建議這麼做，如果要做開銷要從別的地方擠出來，需要重新設計；C和D的某幾個尺寸沒有標註，麻煩設計師就現在當場給我標註一下，如果現在不能，那給個明確的時間，你今天幾點可以給我。
設計師和產品經理聽完心裡就有數了，啥叫訓練有素，啥叫做事靠譜。這就是一流的技術人員的表現（技術水平是不是一流另說）。
另外
凡是有幾個方面分工合作的工作都有一條很重要的原則，就是眼下大家要做的部分，所有人都沒有異議和疑慮。
從推卸責任的角度來說，萬一出了問題，哪個問題該誰負責，大家摘清楚，到時候出了事找不到你頭上，該誰返工，該誰補，一清二楚。
負責任的角度來說 ，每個開發人員都希望從自己手裡誕生個偉大的軟體，別人交接給你一堆爛玩意，你能忍嗎？不能忍為什麼不去追著別人給你改？
放在設計和程序合作這件事上，那就是在代碼交付之前，這部分代碼的設計稿大家都已經明確而且沒有異議了。
至於設計變更的情況，那就是另外一回事了。
評論裡面@丁科 說得好
1."未按標註還原設計"
這屬於UI bug,歸QA/Test管,沒UX什麼事.
2.修改設計 移動1px
這種屬於需求變更,要走流程,歸PM管,扔到需求變更Task里,改不改是PM決定的,沒程序員什麼事.
我非常非常反對第一名的答案
什麼叫碼農的工作是必須的設計師的工作是可選的？
你要是定製軟體，客戶不接受這麼丑的東西，指著你的鼻子臭罵你公司的水平，讓你重做，你可以選不做嗎？也就是開發給公眾的軟體沒這麼直接，用戶不會衝到你面前來罵你做得丑，但是他們會用腳投票，除非你沒有競爭對手。
神馬照顧不到方方面面，照顧不到的地方你開工之前說出來。我就不信設計師和產品經理會逼著你方方面面都照顧到。
神馬不能實現，不能實現你拿到設計稿的時候說啊，我就不信你說明白了設計師還一定要你做不能實現的東西。
神馬實現很複雜，很複雜你早說啊。做到最後給個半成品這算神馬？我就不信你拿到設計稿就講明白哪裡複雜，要花多少資源做，設計師最後會追著你改這些點。
神馬素材不標準，誰給的素材不標準你直接上去噴他一臉他敢有話說嗎？
洋洋洒洒寫這麼大一篇，說起來都是客觀原因，這種程度的客觀原因可以成為理由嗎？
傳聞知乎上很多開發人員，難道大家都喜歡找借口找客觀原因？
我是看到第一名的答案，才寫這麼長個東西的，最近很忙，這麼幾百字還是幾天抽空慢慢寫的。
只是希望每一個開發人員都很明確：事到底是怎麼做的。
不要強調客觀問題，客觀問題總是存在的，解決客觀問題的干擾也是我們日常工作的一部分。如果因為客觀原因而不做，那基本上什麼都做不了，因為只要想找一定能找出客觀問題阻礙你。
確實會有一些客觀條件是不可逾越的，但是事實上大多數「做不了」只是因為我們懶而已。
不止是與設計師合作，其他的方面也是一樣，負責和主動是基礎素質。
這種程序猿過於追求對自我設計的堅持，我們一般用不起。我們用的都是：
「哦，往左移，好！」
「哦，往右移，好！」
「哦，再移回來，好！」
「哦，還要移？不好意思，項目結束了。」
「哦？加錢？沒問題，往哪兒移？」
推薦閱讀：