Why Designers Should Learn How to Code/为什么设计师应该学习编写代码

原文：John urban 翻译：Rarefy

通常，在完成了一件网页设计后，设计师的无知都会显露无遗而备受指责。他们把创建网页代码的繁重工作都留给了程序员们。这种现象不只出现在网络开发行业，在软件及游戏开发业也是如此。
残酷的事实就是：开发进度可能会因设计师而停滞不前。为了追求最佳效率，设计师不仅需要描描画画，还需要能把它做出来！本文中，我想与读者分享一些为什么设计师需要学习编写代码的理由。

做现实可行的设计

有了一个最终产品将如何实现的明确印象，设计师将拿出更多实际可行的概念。作为开发进程中不可或缺的一份子，设计师肩负着确保他们的设计能够顺利转移到网络介质上，同时还要考虑其可用性，网页易读性和可实现性。一个对用户友好的网站不仅有简洁清晰的浏览顺序逻辑，还向用户提供一切所需的信息而不会显得咄咄逼人或是杂乱无章。想要知道一种 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

作者 John Urban 是加州大学的大二学生，主修计算机科学。

<全文完>

下面是我的一点读后感：
本篇文章确实带有一定的不满。显然我们不能过多的期望一名大二的学生通过这篇短文能够圆满的解决感性与理性在项目开发中的矛盾。甚至最后作者提出的以项目大小决定需要何种人才，也缺乏具体的分工和细节指引。
“设计师为人类创作，开发者为机器创作。”，如果在以相互配合为群体的主要工作方式环境下，我们可以做一个简单的理性的逻辑推理证明这个观点是有偏颇的，首先人类一切的创意和创造都是为了满足自我需求或者是欲望，还用继续证明么？一个群体在极力满足原始的欲望而创作，而另一个群体在为了为人类服务的机器而创作，从复杂性来看，后者的工作需要满足的条件必定远远超过前者，后者所要解决的问题其实是三个对象：机器，人，自我控制欲；前者-设计师在多数情况下仅仅只考虑一个对象，即满足自我的创作欲带来的成就感。
简单概括，单一型设计师人群在工作中的状态是：感性抑制了理性；产品开发者人群在工作中的状态则相反。所以原文作者提出的几条纲领式建议指导是合理且可行的，只有用相对理性的态度平衡两类人群截然相反的主观意愿，方能快速、稳健的走到目的地，出色的完成项目。毕竟设计不等同于纯粹的艺术创作，而是有限度和约束的艺术创作。项目的开发周期，产品使用者的体验度，市场的收效，等等这些因素都是放在两群人面前，需要共同解决的问题。至于哪一类应该在工作中扮演指挥者角色，显然应该是倾向于理想多一些的人们。原文中交响乐的比喻并不准确，一首乐曲的原始作用远没有一件具像产品所要达到的社会效应来的客观和复杂。但我们因此也能看出作者本人是愿意平衡两者工作关系的，至少他的目的性是非常明确的。而且我也在一定程度上赞同作者写这篇文章的初衷，设计师应该懂得、甚至是掌握代码的基本知识以及开发技能。
希望有人再写一篇名为，“为什么产品开发者应该学习艺术”的文章。或许这样我们可以从另一角度省视自己到底应该在协同工作中用何种个人心态完成共同的项目。
最后，借用Wordpress开发者们的一句名言来表达我对整个项目开发工作过程的一种精神向往：CODE IS POETRY / 代码如诗。