15 设计与研究
设计与研究的区别看来就在于,前者追求“好”(good),后者追求“新”(new)。
最大的不同在于你会更多地考虑用户。设计的时候,一开始总是问:我为谁设计?他们需要什么?比如,优秀的建筑师不会先设计,然后强迫用户接受,而是先研究最终用户的需求,然后做出用户需要的设计。
注意,我说的是“用户需要的设计”,而不是“用户要求的设计”。我不想让读者产生一种印象,认为设计师就像厨师一样,顾客点什么菜就一模一样做出来。艺术的各个领域有着巨大的差别,但是我觉得任何一个领域的最佳作品都不可能由对用户言听计从的人做出来。
有一句话说“顾客永远是对的”,这是指评价优秀设计的标准是看它能够多大程度上满足用户的需求。如果你的小说没人爱看,或者你做的椅子极不舒服,那么就说明你的作品失败了,被一票否决了。就算你的小说(或者椅子)有着最先进的理论指导也无济于事。
可是,让用户满意并不等于迎合用户的一切要求。用户不了解所有可能的选择,也经常弄错自己真正想要的东西。做一个好的设计师就像做一个好医生一样。你不能头痛医头,脚痛医脚。病人告诉你症状,你必须找出他生病的真正原因,然后针对病因进行治疗。
大多数优秀设计都是这样产生的,它们关注用户,并且以用户为中心。
我说设计必须考虑用户的需求,这里的“用户”并不是指所有普罗大众。事实上,你可以选择任何想要的目标用户。
如果目标用户群体涵盖了设计师本人,那么最有可能诞生优秀设计。如果目标用户与你本人差别很大,你往往会假定目标用户的需求比你本人的需求更简单,而不是更复杂。低估用户(即使出于善意)一般来说总是会让设计师出错。
如果你觉得自己在为傻瓜设计产品,那么很可能不仅无法设计出优秀产品,而且就连傻瓜也不喜欢你的设计。
科学观点不需要服从人类工程学(ergonomic)
。到了艺术领域,情况就完全变了。设计必须以人为本。
另外,还要记住一点。怎么理解编程语言?你不要把它看成那些已完成的程序的表达方式,而应该把它理解成促进程序从无到有的一种媒介。这里的意思是说,成品的材料和开发时用的材料其实是不一样的。搞艺术的人都知道,这两个阶段往往需要不同的媒介。
最后写出来的程序就像已经完成的数学证明一样,是一棵经过精心修剪的树木,上面杂乱滋生的树杈都已经被剪去了。所以,评价一种语言的优劣不能简单地看最后的程序是否表达得很漂亮,而要看程序从无到有的那条完成路径是否很漂亮。某种设计使得最后的程序非常漂亮,但是不一定同时具备漂亮的编程过程。
在软件领域,贴近用户的设计思想被归纳为“弱即是强”(Worse is Better)模式
。 这个模式实际上包含了好几种不同的思想,所以至今人们还在争论它是否真的成立。但是, 其中有一点是正确的,那就是如果你正在设计某种新东西,就应该尽快拿出原型,听取用户的意见。
与之对照,还有另一种软件设计思想,也许可以被称为“万福玛丽亚”模式
。它不要求尽快拿出原型,然后再逐步优化,它的观点是你应该等到完整的成品出来以后再一下子隆重地推向市场,就像圣母玛丽亚降临一样,哪怕整个过程漫长得像橄榄球运动员长途奔袭、达阵得分也没有关系。在互联网泡沫时期,无数创业公司因为相信了这种模式而自毁前程。我还没听说过有人采用这种模式而获得成功。
软件开发也可以这样做。原型(prototype)
并不只是模型(model)
,不等于将来一定要另起炉灶,你完全能够在原型的基础上直接做出最后的成品。我认为,只要有可能,你就应该这样做。这样的方式使得你可以利用在开发过程中一路产生的新想法。不过更重要的是,这样做有助于鼓舞士气。士气是设计的关键因素。
士气也可以解释为什么很难为低端用户设计出优秀产品。因为优秀设计的前提是你自己必须喜欢这种产品,否则你不可能对设计有兴趣,更不要说士气高昂了。为了把产品设计好,你必须对自己说:“哇,这个产品太棒了,我一定要设计好!”而不是心想:“这种垃圾玩意,只有傻瓜才会喜欢,随便设计一下就行了。”
开发软件的时候,我有一条规则:任何时候,代码都必须能够运行。如果你正在写的代码一个小时之后就可以看到运行结果,这好比让你看到不远处就是唾手可得的奖励,你因此会受到激励和鼓舞。其他艺术领域也是如此,尤其是油画。
设计意味着做出符合人类特点和需要的产品。但是,“人类”不仅包括用户,还包括设计师,所以设计工作本身也必须符合设计师的特点和需要。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。