開發者和設計師：為何我們不能化干戈為玉帛

　　只要涉及到視覺化程式設計，程式設計師和設計師之間就會出現矛盾。當談及一些程式開發問題時雙方就會產生分歧，儘管我們都知道在建立有效的應用程式時兩個團隊成員都很重要。設計師看到最初的設計版本與最終的版本不同時總會感到失望；而程式設計師則會抱怨說是設計師設計問題（有點雞蛋裡挑骨頭）！

　　許多衝突源於兩者之間缺乏理解，這也是導致設計師/程式設計師產生分歧的原因。為了兩者之間的和平，本文總結了一些經驗教訓，作為設計師/程式設計師不妨學習下，知己知彼，方能百戰百勝。

　　設計師說：我們並不是有意為難

　　我們努力做好工作，我們並不是有意為難。

　　設計師需要維護開發者們的聲譽，在你們看來我們更喜歡形式功能，但事實並非如此。設計師努力嘗試做出最適合的功能，以便這些功能都能被採用。

　　越來越多的設計師開始注重使用者體驗（user-experience）而非平面設計。在進行設計之前瞭解使用者需求這有一點對於設計師來非常重要。有時我們會嘗試新增一些漂亮的圖形，希望使用者有更好的使用者體驗。

　　程式設計師說：我們並不想有意為難

　　當我們編寫程式碼時，完成專案只是其中的一部分，應用程式會隨著時間的改變而改變，我們要做的是確保這些變動能輕易地進行更改。我們需要編寫程式碼來測試自動化測試框架。當程式設計師從設計師那請求修改產品時，無論是HTML格式、檔案命名或者目錄結構，所做的一切都是為了確保該產品在將來測試能夠保持更佳地靈活性。

　　別擔心，我們不會要求過多的靈活性。建立靈活性是非常珍貴的，我們懂得“YAGNI”適可而止的設計（這個原則簡而言之為——只考慮和設計必須的功能，避免過度設計）。我們儘量避免這種情況。

　　設計師說：形式問題影響功能

　　形式不追隨功能，形式可以賦予功能特徵。程式設計師可以設計某些功能讓你輕易獲得所需。如果我們想要使用者點選某個按鈕或者執行某個動作，圖形和佈局就能幫助使用者知道或者進行猜測如何獲取他們想要的結果。

　　經驗告訴我們設計出一款特定的方式尤其適用於線上應用程式。即使是簡單的設計包括按鈕，表單或者照片選項，當作出選擇時我們使用了明智的決策方法。通過位置、顏色以及視覺顯示即可告訴設計師某人正在參與互動，但前提是你需要建立一個互動環境。

　　舉個例子，世界上首屈一指的品牌導航，下圖是保時捷分層導航的螢幕截圖。簡潔、良好的結構設計功能可以使使用者產生愉悅感！

　　程式設計師說：命名事宜

　　當我們構建一個應用時有許多不同元件需要跟進。除了網頁、圖形、原始碼檔案、資料庫列表、列還有許多其他元件需要管理。而一致的命名是我們的第一要務。

　　當一個設計師在檔案系統GUI中拖放檔案時，如果該檔案命名為submitButton.gif或submit-button.gif或許無法區分兩者。我們從資料庫領域到檔名到CSS類幾乎所有都採用了標準命名。這就表示編碼部門有了標準或者他們遵循了不成文的規則，有了一致的命名使工作更加輕鬆。

　　我們旨在讓命名更加具有描述性和可預見性。相似的命名專案明顯是某個命名的重要組成部分。比如名為submit1.gif和submit2.gif無需解釋兩張圖片之間的差異，但submit-green.gif和submit-red.gif就不同了。

　　設計師說：規則有助於我們瞭解

　　我們可以學習規則，但這只是有助於我們瞭解。規則我們可遵循也可不遵循。開發者有時會和我們討論程式語言但我們並不理解，就如同設計師有時在講開發你們也難以理解一樣。一旦設計師和開發者都能理解了，最大的獲益者便是使用者。

　　上面提到使用檔案命名的例子，只是想告訴我們應該遵循什麼樣的標準。我可以向你保證，如果我們知道了這是正確的方式，我們會以某種組圖方式或者以小寫字母方式命名，我們很樂意這麼做。

　　設計師本質上並不會反抗，因為大多數情況下非常喜歡程式設計師。我們喜歡做自己想做的事情，也沒有人告訴我們應該怎麼做，我們屬於樂天派。

　　設計師們在訓練時就知道無需遵循條條框框，要有創新理念，但這並不是說要為難開發者工作。一旦設計師遵循了規則，那麼她可以將創新凌駕於規則之上，而不會讓功能更加困難。他們會因圖片能否運用得當而起爭論。

　　一旦我們有了某個平臺或者框架比如WordPress，我們可以在已知地方設計，在哪設計更加有意義（背景圖片，圖案，顏色），在哪設計無意義（導航，嵌入罕見的字型，圖形導航）。尋找一個獨特的或者明智的方法來解決設計問題可以給設計師來帶更加出色的工作表現。

　　程式設計師說：桌面上什麼工作無法在Web上執行

　　建立一個漂亮的Web頁面僅僅是這項工作的開始。當推送到Wen伺服器時這就要求它呈現出來的效果很完美。

　　Windows桌面上的檔案命名大小寫之間的區別並不是很重要，但當釋出到Linux Web伺服器時，greenbutton.gif 和GreenButton.gif是不一樣的，使用者或者程式設計師或者測試人員會看到404。我更喜歡使用小寫檔名，如果情況允許我會使用連字元來進行區分。

　　首先確保訪問所有連結和文件以確保桌面上的任務能夠很好執行。無論是頁面上圖片損壞或是CSS檔案無法載入或是錯誤連結導致設計的頁面很難執行，會出現這種情況：

<.img src="file:///c/Users/designer/assets/green-button.gif">

　　你可能不會注意到桌面上瀏覽器圖片載入時間，如果你使用漂亮的，全色的圖片作為banner圖，甚至是佔據整個大半頁面，那麼載入的時間是非常緩慢。很多瀏覽器外掛導致頁面變寬，因此，請慎用。

　　設計師說：圖形只是一個支援機制

　　設計師瞭解圖形的支援機制，在應用程式中並非是最重要的元素。根據需求確定是否使用圖片，如果你的資訊需要裝飾而又不是放在首要位置，那又為何不可？

　　對於“藝術”而言，有些設計師感覺他們做這些工作才是最重要的，其他才是次要的。相比較“設計師”他們更願意被稱為：“藝術家”。當一名設計師與程式設計師一起工作時，她想成為團隊中的一員，因為最終都是為了使用者。不同的是，設計師可以自己安排工作集中精力開發出優質的體驗。這也是程式設計師們所期望的，但程式設計師卻無法自我安排。

　　程式設計師說：DRY原則，不要重複自己。

　　系統維護最大的因素就是有多少重複。我們不需要用寫程式碼來計算5個地方的銷售稅。在同一個地方編寫程式碼，一個叫calculate_sales_tax()的函式可以使用5次。如果需要修改程式碼，那麼只需要改變某個函式就行，這也可以節省時間。

　　在設計師的國度裡CSS就是DRY原則最大的事例。在CSS之前，在HTML中顯示的標記是這樣：

<p><font face="Arial" size="+1″><b>This is a headline</b></font></p>

　　CSS樣式：

<p class="headline">This is a headline</p>

　　如果你使用CSS就要遵循DRY原則。

　　設計師可利用DRY可以幫程式設計師減少複雜性。如果你有一種圖片需要在兩個不同地方使用，只需把它放在同一個目錄裡，每個頁面都可以使用。

　　設計師說：對齊和間距真的很重要

　　對齊和間距非常重要。這對於嚴格的開發者在設計時建立對齊和間距是最為常見的問題，當然也允許預設佈局。

　　使用對齊和間距主要是因為確保終端使用者能輕易的執行功能，使這一過程更加直觀。如果使用者能輕易找到他們想要的東西，輕鬆完成這項任務，那說明你已經成功了；倘若相反，那麼在互動應用上，你還有許多工作要做。

　　Yahoo！主頁

　　MailChimp主頁

　　你可以對比下Yahoo和MailChimp.com或Fab.com的主頁。

　　一個頁面上全是內容，而另外兩個則是空白和對齊，因此使用者可以輕易地獲取想要的資訊。當然這兩個網站受眾型別不同，但是你可以告訴Fab.com和MailChimp.com網站設計使用者感興趣的資訊。

　　程式設計師說：學習如何使用版本控制系統

　　在現代軟體開發中，版本控制系統（VCS）如Git或者Subversion是必備工具。如果這兩個你都沒使用，那麼你就不是一名合格的程式設計師。一款VCS對設計師來說主要有兩個好處：變更管理和歷史追蹤。

　　結論：

　　當然，設計師和程式設計師之間相互學習的還有很多。無論你是哪一方，我們希望能從專案方面思考。正如我們所說的，任何一方都不希望另一方痛苦。在專案合作上我們都注重質量問題希望專案能做的更好。兩者經常在一起討論專案，你會發現從對方那學到很多知識，你的團隊也會因此而變得更加強大。

　　英文出自：Smartbear