已经有很多好的评论了，所以我不确定还有什么可以补充的。 但仍…

为什么开发者希望能够设计出优秀的UI? 他在那个领域受过多少训练? 他读了多少书? 他在这几年里设计了多少东西? 他有机会看到用户的反应吗?

我们不期望一个随机的“水管工乔”能够写出好的代码。 那么，为什么我们要期望随机的“程序员乔”设计出优秀的UI呢?

移情有帮助。将UI设计和编程分离是有帮助的。可用性测试有帮助。

但是UI设计是一门需要学习和实践的手艺。

可能是因为一些开发人员从Dos开始，并继续部分地在命令行操作系统上工作。 或者因为我们有些人写软件，因为电脑有一些正常的逻辑，不像人。: -)

我为社交圈之外的人设计了一个程序，并观察他们的行为。在这样做的过程中，我不再受制于朋友们的偏见，也不再受制于我自己的骄傲和自我。在改进应用程序的过程中，我变得更加谦虚，对设计问题更加敏感。我学到了以任务为导向的设计和简单的重要性。我明白了拥有太多功能的代价。有了经验，你也会的。

我强烈推荐一些参考资料:

Joelonsoftware杰夫·拉斯金的“人性化界面” 罗宾·威廉的《非设计师设计指南》 大多数UI文章都在alistapart上 Jwz关于编程的博客 苹果人机界面指南

我强烈建议你忽略一些参考文献和哲学:

“主题” 一般的桌面应用程序，除非您需要访问驱动程序/文件系统 “越多越好”的理念

我用的是我所谓的祖母测试。

如果你亲爱的老祖母不会用它，那就有问题了。 假设她知道这个程序是关于什么的，例如，知道如何做税务，并试图使用Quicken。

让我们把你的问题转过来

“ui设计师”注定只设计信息架构和表示层吗?他们是否可以做些什么来重新训练自己的大脑，使其更有效地设计出令人愉悦和高效的系统层?

似乎他们“ui设计师”必须采取完全不同的视角——他们必须从盒子的内部向外看;而不是从盒子外面看。

艾伦·库珀的《囚犯们在管理疯人院》的观点是，我们不可能成功地同时持有两种观点——我们可以学会戴好一顶帽子，但我们不能只是换帽子。

与流行的神话相反，在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课程。这涉及到很多东西，比如启发式，源自格式塔心理学的原则，人类的学习方式等等。