我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?

同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?


当前回答

就像音乐一样: 有时人们在技术上可能是伟大的音乐家,但不是艺术家。我的经验法则是始终只向用户提供他们当时需要的UI。我注意到许多后端开发人员在制作UI时充斥着各种可以想象到的选项。尽管这些类型的人喜欢先考虑所有的细节,然后慢慢忽略他们不需要的东西,但这对大多数最终用户来说并不适用。

其他回答

Neal Stephenson所著的《In the Beginning was the Commandline》是一本关于用户界面及其重要性的好书。不是每个人都需要GUI,只是很多人不编程。这就像迪士尼世界的动物王国和实际的亚马逊之间的区别。

让我直接说:

改善这一点并不是从指导方针开始的。首先要重新定义对软件的看法。

大多数硬核开发人员对他们软件的用户几乎没有同情心。他们不知道用户如何思考,用户如何建立他们使用的软件模型,以及他们通常如何使用计算机。

当专家和外行发生冲突时,这是一个典型的问题:一个正常人怎么会如此愚蠢,不明白专家10年前的理解?

首先要承认的一个事实是,几乎所有有经验的开发者都难以掌握:

正常人对软件的概念和你有很大的不同。他们完全不懂编程。一个也没有。零。他们根本不在乎。他们甚至不认为他们需要关心。如果你强迫他们,他们会删除你的程序。

这对开发者来说是难以置信的残酷。他为自己生产的软件感到自豪。他喜欢每一个特征。他可以告诉你它背后的代码是如何工作的。也许他甚至发明了一种令人难以置信的聪明算法,使它比以前快了50%。

用户并不关心。

真是个白痴。

许多开发人员无法忍受与普通用户一起工作。他们因为缺乏技术知识而感到沮丧。这就是为什么大多数开发人员回避,认为用户一定是白痴。

事实并非如此。

如果一个软件开发人员买了一辆车,他希望它能平稳运行。他通常不关心轮胎压力,机械微调是重要的,使它运行那样。在这方面他不是专家。如果他买了一辆没有微调功能的车,他就会把它退回去,再买一辆他想要的。

Many software developers like movies. Well-done movies that spark their imagination. But they are not experts in producing movies, in producing visual effects or in writing good movie scripts. Most nerds are very, very, very bad at acting because it is all about displaying complex emotions and little about analytics. If a developer watches a bad film, he just notices that it is bad as a whole. Nerds have even built up IMDB to collect information about good and bad movies so they know which ones to watch and which to avoid. But they are not experts in creating movies. If a movie is bad, they'll not go to the movies (or not download it from BitTorrent ;)

所以归结起来就是:把普通用户当成专家来回避是一种无知。因为在那些他们不是专家的领域(有这么多),他们希望其他领域的专家已经考虑过使用他们产品或服务的普通人。

What can you do to remedy it? The more hardcore you are as a programmer, the less open you will be to normal user thinking. It will be alien and clueless to you. You will think: I can't imagine how people could ever use a computer with this lack of knowledge. But they can. For every UI element, think about: Is it necessary? Does it fit to the concept a user has of my tool? How can I make him understand? Please read up on usability for this, there are many good books. It's a whole area of science, too.

啊,在你说出来之前,是的,我是苹果粉;)

我知道微软和他们自己的指导方针不太一致,但我发现阅读他们的Windows设计指导方针真的对我有帮助。我的网站上有一份,向下滚动一下Vista用户体验指南。它在颜色、间距、布局等方面帮助了我。

你提到了《别让我思考》这本书。我强烈推荐你阅读这篇文章。

与流行的神话相反,在UI设计中实际上没有软方面,至少不需要设计一个好的后端。

考虑以下几点;优秀的后端设计是基于任何优秀开发者都熟悉的原则和元素:

低耦合 高内聚 架构模式 行业最佳实践 等

好的后端设计通常是通过一系列交互产生的,基于测试或实际使用期间获得的可测量反馈,初始蓝图会逐渐改进。有时候,你需要对后端较小的方面进行原型设计,然后单独进行测试等等。

优秀的UI设计是基于以下合理的原则:

可见性 功能可见性 反馈 宽容 简单 一致性 结构

UI也是通过测试和试验,通过迭代诞生的,但不是用编译器+自动化测试套装,而是人。与后端类似,有行业最佳实践、测量和评估技术、考虑UI的方法,并根据用户模型、系统图像、设计师模型、结构模型、功能模型等设定目标。

设计UI所需的技能与设计后端是完全不同的,因此不要指望不先学习就能做出好的UI。然而,这两种活动的共同之处是设计过程。我相信只要花点时间学习,任何能设计好软件的人都有能力设计好UI。

我建议你选一门人机交互的课程,比如在MIT和耶鲁的网站上找一些在线资料:

麻省理工学院用户界面设计与实现课程

结构模型和功能模型的理解和使用

Thorsten79之前的一篇出色的文章提出了软件开发专家和用户之间的话题,以及他们对软件的理解是如何不同的。人类学习专家区分了功能思维模式和结构思维模式。找到去朋友家的路是两者区别的一个很好的例子:

First approach includes a set of detailed instructions: take the first exit of the motorway, then after 100 yards turn left etc. This is an example of functional model: list of concrete steps necessary to achieve a certain goal. Functional models are easy to use, they do not require much thinking just a straight forward execution. Obviously there is a penalty for the simplicity: it might not be the most efficient route and any any exceptional situation (i.e. a traffic diversion) can easilly lead to a complete failure. A different way to cope with the task is to build a structural mental model. In our example that would be a map that conveyes a lot of information about the internal structure of the "task object". From understanding the map and relative locations of our and friend's house we can deduct the functional model (the route). Obviously it's requires more effort, but much more reliable way of completing the task in spite of the possible deviations.

通过UI传递功能模型或结构模型(例如,向导模式还是高级模式)之间的选择并不像Thorsten79的帖子中看起来那样简单。高级和频繁的用户可能更喜欢结构模型,而偶尔或缺乏经验的用户-功能。

谷歌地图就是一个很好的例子:它们包括功能和结构模型,许多卫星导航也是如此。

问题的另一个方面是,通过UI呈现的结构模型不能映射到软件的结构,而应该自然地映射到手头的用户任务或涉及的任务对象的结构。

这里的困难在于,许多开发人员对他们的软件内部有一个良好的结构模型,但只有软件旨在协助的用户任务的功能模型。要构建好的UI,你需要理解任务/任务对象结构,并将UI映射到该结构。

无论如何,我仍然强烈建议参加一个正式的HCI课程。这涉及到很多东西,比如启发式,源自格式塔心理学的原则,人类的学习方式等等。