通常，在完成了一件网页设计后，设计师的无知都会显露无遗而备受指责。他们把创建网页代码的繁重工作都留给了程序员们。这种现象不只出现在网络开发行业，在软件及游戏开发业也是如此。
残酷的事实就是：开发进度可能会因设计师而停滞不前。为了追求最佳效率，设计师不仅需要描描画画，还需要能把它做出来！本文中，脚本之家想与读者分享一些为什么设计师需要学习编写代码的理由。
有了一个最终产品将如何实现的明确印象，设计师将拿出更多实际可行的概念。作为开发进程中不可或缺的一份子，设计师肩负着确保他们的设计能够顺利转 移到网络介质上，同时还要考虑其可用性，网页易读性和可实现性。一个对用户友好的网站不仅有简洁清晰的浏览顺序逻辑，还向用户提供一切所需的信息而不会显 得咄咄逼人或是杂乱无章。想要知道一种 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
