無意挑起所謂的職位之間的矛盾，直到今天看到這樣一篇文章的時候，是的，這是一篇關於程式猿和設計獅之間的文章，起源是這樣的，一位網友在某社群上提了一個問題：
- 開發人員拒絕按照 UI 標註還原設計，如何讓他理解精確還原的重要性，從而去修改程式碼？
- 當一個開發工程師屢次發問「這裡讓我移1px有什麼意義，我為什麼要浪費時間這麼做」且拒絕修改時，如何讓這位開發理解、認識到修改的重要性？
- 為什麼國內很多視覺設計師得為了那些雖然看起來很細碎、甚至可謂之雞毛蒜皮，但對於設計師還是很重要的細節追著工程師去修改，一項項列出問題，卻得不 到工程師正面的迴應？舉個例子，聽同事介紹過 Frog 的工程師會為了不影響視覺設計師工作，自己開發出檢查設計還原的軟體進行還原檢查修改。
- 是什麼背後的原因另產品的設計實現這麼困難？是因為設計師不懂程式碼？部分技術人員的審美意識？還是大廠心態或者其他什麼原因？這種狀況怎麼解決？到什麼時代或是契機才能夠被解決？
嗯，不出所料，頂到最高的回答是這樣的。
限於篇幅，全文可右戳檢視：http://zhi.hu.com
通篇文章中，作者不遺餘力的對設計師進行汙衊和調侃，甚至將話題轉移， 文中寫到：
- 對於軟體開發而言，碼農的工作是必需的。設計師的工作是可選的。
- 沒人做設計，軟體也可以用。實際上在扁平化的今天，許多開發比如iOS，系統預設的模版雖然不好看，但也不會是個毛胚房。但沒人寫程式碼，那就是屁也沒得。
- 工作的重要性決定誰聽誰的。就是這麼簡單。
嗯，靜電看完後，唯一感覺是 這是黑社會還是自我感覺太良好了呢？如果說使用者群決定了回答的質量的話，我一點都不懷疑，除了對這個社群表達一點點微弱的反感情緒外，靜電還想對現實中設計師和開發的關係寫一點自己的心得和體會。
首先表明立場，靜電是位設計師，懂一點程式碼以及產品。
緣起 1 畫素，改與不改？
作為一個負責任的設計師來說，一畫素對他們來說，重不重要，如果說不重要，那靜電認為這不是一個合格的設計師，因為這是設計師的本職工作；
如果說重要，有的人會說，這個世界上沒有完美的事物，安啦安啦，不改也沒什麼大不了，別折騰啦！
當他們去求助開發想改掉這個問題的時候，開發可能會說，改這個工作量很大，需要很多時間，況且只是一個畫素的問題，沒什麼大影響，不要改了。
產品經理說：我們最終的目標是保證產品快速迭代，保證核心功能沒問題即可。1畫素不用調了，浪費時間。
別折騰啦，別折騰啦，別折騰啦！
這個時候想的開的設計師估計會放棄這樣的執著，雖然心有不甘，但也無可奈何，心想:不改就不改吧，所有事物都是不完美的。
隨著時間的推移，一畫素問題就這麼越來越多。最終，當有成百上千的一畫素問題積累到一起的時候，突然有一天，使用者說：“這個軟體（網頁）怎麼這麼醜？你們的設計怎麼做的？能力不行吧？”
設計師周圍的所有人：“這個是你設計的問題，你就不能好好設計嗎？你的水平有問題！態度有問題！”
設計師：“。。。”
我想這是發生在我們所有人身邊的事情，最終一款亂糟糟的軟體（網頁）就這麼上線了。至於市場反響，你懂的。。。
我想這個時候設計師心裡肯定有一萬頭草泥馬在奔騰。
一個爛產品就是在無數的妥協和一畫素的錯位中產生的。在當今產品同質化嚴重的情況下，使用者自然會選擇介面美觀易用的產品。
沒人做設計，軟體也可以用？
是的，可以用，沒人做設計，軟體絕對可以用，就是用著很糾結就是了。舉個例子，當人類還在遠古時代的時候，大傢伙都是吃生肉的，沒人覺得不妥。後來呢，有個愛折騰的人對大家說：“那啥，其實用火烤的肉更好吃喲~” ，我估計當時有很多對他說：“你瞎搞毛線啊，生肉就是好吃，吃生肉就夠了，吃烤的多麻煩！”。但最終熟肉還是戰勝了生肉，結果就是後來大家沒人吃生肉了。靜電想說的就是，湊合不是不可以，但湊合已經無法滿足當今人們日益提高的審美需求了。人們不僅要吃飯，而且要吃飽飯，然後還要吃的美味。
設計存在的價值亦然。至於知X上某人的言論，程式是必選的，設計是可選的。靜電除了呵呵，還想附帶釋放嘲諷技能：“其實程式也不是可選的，因為吃飯才是可選的，活著才是可選的，其他神馬的，都特麼見鬼去吧！這位仁兄，你說對嗎？”
當設計師開始寫程式碼，程式設計師開始嘗試設計的時候，你在做什麼？
其實一畫素的問題壓根不是問題，在設計師完成設計稿，設計縝密，標註明確的情況下，開發人員在遵從設計稿的情況下，還原的程度是非常高的，基本可以到達80%到90%，這個時候的一些小細節，靜電建議作為設計師的大家積極與開發溝通協調來解決問題，相信大部分的開發者都是非常願意幫助我們解決問題的。 另一方面，在溝通過程中，設計師也需要從與開發者的合作過程中理解開發者是如何進行設計稿的復現的，程式碼如何寫，佈局如何合理，哪些地方是可以避免發生問題的，哪些是可以與開發者一起思考想辦法解決的。
靜電從事APP開發過程中，電腦上是安裝於開發者一樣的執行環境的（xcode），並使用git保持程式碼與開發人員的程式碼同步. 這樣有助於我們瞭解軟體的產生過程，必要的時候，我們可以順帶學習一些樣式調整的小技巧，對於設計師來說，這學到了更多東西有助設計稿的實現，對於開發者，他們一定是非常歡迎你這麼做的，因為身邊有一個同樣會寫一些程式碼，幫他們解決問題而不是提出問題扔給他們不管的人。 於是好基友就這麼誕生了。
在這個過程中，一個非常好的現象正在發生，由於你們關係的進展，作為設計師的你，在程式設計師遇到取色或者某些簡單的圖片問題的時候，你可以非常方便的來幫他，甚至可以幫他裝個photoshop慢慢教他做一些簡單的圖形處理。
這樣，相互協作和融洽的溝通就產生了。這個時候，你在做什麼呢？是在寫一篇酸溜溜的檄文，還是無休止的抱怨對方？
優秀的設計師和開發者：溝通與相互理解
其實我們一直在強調溝通，什麼是溝通呢，雙方的交流才叫溝通，單方面的講解，另一方面卻無動於衷，不叫溝通。我們之前假設，設計師和開發者都是通情達理，氣場不那麼相悖的。 但萬一遇到氣場不合的呢？或者對方就是不願意去改著1px呢？原因可能是：
1，設計稿不夠謹慎，頻繁的改動，設計師請想象一下給客戶做東西改到吐血時的情景。
2，如果設計稿謹慎，標註完整，但始終還原度較低，低到你無法忍受。 那麼除了溝通，還有一個能力和態度的問題擺在你面前。 如果說初次磨合，我們可以嘗試來進行溝通，在雙方態度都不錯的情況下，對方一般都願意幫忙;還有一種情況，這個是大家最關注的問題，就是對方極度不配合，這個時候我們需要求助PM或者你的領導作為中間人來協調，成功將矛盾化解，記住，在這種情形下，設計師就不要過於較真兒了，否則針尖對麥芒，結果是兩敗俱傷。
3，當設計師做到第二節描述的做到了體諒和理解的情況下，但對方依舊極度不配合，最終導致產品出問題，這個時候就不是設計師能解決的了，相信你的上級或者領導會對整個情況有更深入的瞭解和判斷。 你所要做的，就是做好本職工作完美到沒有紕漏即可。因為最終產品的質量已經不是你能把控的了的了，順其自然。通過其他形式尋找自身成就感。
4，沒有完善的bug反饋和質量控制機制，將問題歸於個體認知所帶來的差異而不是流程的標準化。
5，溝通不善.我知道設計師您在說要改改改.但開發可能是”….（都不愛理你）”
致我們親愛的開發者
- 我們知道您很忙，每天面對無數的程式碼看花了雙眼，無數bug需要修改，但我很想學一點程式碼來分擔你的痛苦。
- 我們知道您並不是low爆的沒品位的程式碼狂人，您的內心一定有對完美的追求。
- 請你理解溝通是雙向的，很多時候，我們需要你來告訴對程式碼一竅不通的設計師，怎麼做更好。
- 我們知道簡潔優雅執行效率超高的程式碼是您畢生追求，但與設計師一起合作修改一個畫素的問題，說不定也很好玩呢？
- 我們的最終目的是一樣的，作出一款讓人滿意的產品。 請相信設計師的專業程度，儘管你可能比他更有才。
- 設計師很樂意幫你在電腦上安裝一些更方便你進行介面開發的小工具。
- 請不要再說：”程式要會ps，要美術幹嘛？”這樣傷人心的話。
致自己——為1畫素努力的設計師
- 嚴格要求自己，一定沒錯。請認真對待自己的每一個設計稿和每一個1px。
- 如果你被甲方的變態客戶蹂躪過，請考慮一下，你現在作為甲方是如何對待”乙方”的。
- 如果一個畫素可以調一次，那就不要調兩次，如果反覆調節多次，最好跟開發道個歉，然後學習如何自己調。
- 學習簡單的程式碼，其實他們沒那麼難，甚至還挺好玩，試著求助工程師，讓他們在你電腦上裝一個開發環境，相信他們很樂意幫你。
- 我們的最終目的是一樣的，作出一款讓人滿意的產品。 請相信開發者的專業程度，儘管你可能比他更有才。
- 請相信，未來職業之間的區分會越來越模糊。 你就是這樣一個會寫程式碼的牛逼設計師，也許是一個懂設計的產品經理,讓他們羨慕去吧。
- 試著相信，每個開發者都是可愛且善良的。 如果你無法相信上一句，請不要放棄尋找。
最後，我愛每一個工作認真敬業，懂的上進，有追求的設計師和開發工程師。