通常,在完成了一件網頁設計後,設計師的無知都會顯露無遺而備受指責。他們把創建網頁代碼的繁重工作都留給了程序員們。這種現象不只出現在網絡開發行業,在軟件及游戲開發業也是如此。
殘酷的事實就是:開發進度可能會因設計師而停滯不前。為了追求最佳效率,設計師不僅需要描描畫畫,還需要能把它做出來!本文中,想與讀者分享一些為什麼設計師需要學習編寫代碼的理由。
有了一個最終產品將如何實現的明確印象,設計師將拿出更多實際可行的概念。作為開發進程中不可或缺的一份子,設計師肩負著確保他們的設計能夠順利轉 移到網絡介質上,同時還要考慮其可用性,網頁易讀性和可實現性。一個對用戶友好的網站不僅有簡潔清晰的浏覽順序邏輯,還向用戶提供一切所需的信息而不會顯 得咄咄逼人或是雜亂無章。想要知道一種 Web 布局是否可行的唯一途徑就是親自去了解如何建立一個網頁。
在幾乎所有的設計與實現各自獨立的產品中,設計組和實現組從沒有滿足過對方的期望,尤其是那些無形的產品,比如網站,軟件和游戲。這通常歸結於產品的期望和產品可行性的相互妥協,目前看來,這是難以完美統一的。解決之道是:設計師應該親身嘗試設計作品的實現,以避免溝通中的混淆,誤解和誤傳。
一個實踐中的設計不應是絕對的。我的意思是,設計應該是靈活友好的,能夠在修改以迎合系統技術限制的同時不扭曲其原有內涵。這些重復但必要的改動只 能由原設計師來實現。一個設計師/開發者能夠比開發人員把設計重提到設計師手裡進行改動更加高效。而且設計師和開發者之間——事實上經常如此——會產生摩 擦。
我常常喜歡把軟件,網絡或是游戲開發想成是管弦樂,而設計師是作曲家,開發者是樂團的指揮家。想象一下二者是同一個人將會怎樣?交響曲將會是令人驚歎的,迷人的,純正的!不僅是大師的神作,而且還是其本人親自指揮的!
設計師同時充當程序員的角色意味著設計和編碼的進度即使不是同時的也是連續的。結果就是開發周期的縮短——誰會不關心效率呢?
現代的設計師需要提升自身的能力以保持個人價值,有一套技能是遠遠不夠的,我們往往需要戴著不同的頭銜:設計師,前端開發者,文章作者和項目經理。
通過學習實現你自己的設計,而不是讓設計成為開發者手中的孤兒——你提升了自身價值。畢竟,在簡歷中提到設計和編碼技能不會有壞處。相反,在這個金融危機時代的企業重組(參見:大規模裁員)和縮減開支的環境下,還能夠強調一個人的重要性而免遭解雇。
然而,即使有這麼多的理由支持設計師學習編寫代碼,這裡還是有反對的聲音。
引用 Lukas Mathis 的一篇有爭議性的文章“設計師不是程序員”(注1)
如果設計師實現自己的設計,他會受制於兩個不同的目標:代碼的整潔和良好的用戶體驗。這兩個目標是相互矛盾的。如果你要實現你自己的設計,你必然會為了代碼的質量而妥協,這是不利於交互設計的。
實現自己設計的設計師面臨著兩個問題:他們知道一個很棒的新思路會建立混亂的代碼,他們也知道如果改進用戶體驗,現有的代碼會被打亂。這兩者相互矛盾,因為用戶體驗都在於小的細節,而這些小細節最終毀於他們的不忍心使代碼變得混亂。
這恰如其分的總結了“Web 開發純化者”們所采取的強硬立場。他們是守舊派,倡導在設計和開發之間劃清界限。顯然,設計師為人類創作,開發者為機器創作。因此,用戶體驗設計師們應該設計出最可行的用戶界面並讓開發者做出最可行的編程決策。雖然這有一定的道理,但當我研究一個用戶界面的時候,我從代碼中尋找靈感的努力卻以失敗而告終。總之,在頭腦中有一個技術及可用性限制的正確觀念還是更有好處。
歸根結底,所開發項目的規模可能最終決定著設計師和開發者的角色。一個小型的應用可以由一個項目經理(注2)一手掌控,而一個大型的系統必然需要不同的專業人才!
注1 Mathis-Lukas——“Designers are not Programmers”——ignore the code
注2 Spolsky-Joel——描述了一個叫做“設計師兼程序員”的職位——“How to be a program manager”——Joel on Software