登陆Slashdot，阅读任何与苹果有关的文章的评论。你会发现很多人都在谈论苹果的产品没有什么特别之处，把iPod和iPhone的成功归因于人们想要赶时髦。他们通常会浏览功能列表，并指出他们所做的一切都是早期MP3播放器或智能手机所没有的。

还有一些人喜欢iPod和iPhone，因为它们可以简单、轻松地满足用户的需求，而不需要参考使用手册。它的界面非常直观、容易记忆和发现。我对MacOSX的用户界面不像以前的版本那么喜欢，我认为它们已经放弃了一些有用的东西，而倾向于浮夸，但iPod和iPhone是卓越设计的例子。

If you are in the first camp, you don't think the way the average person does, and therefore you are likely to make bad user interfaces because you can't tell them from good ones. This doesn't mean you're hopeless, but rather that you have to explicitly learn good interface design principles, and how to recognize a good UI (much as somebody with Asperger's might need to learn social skills explicitly). Obviously, just having a sense of a good UI doesn't mean you can make one; my appreciation for literature, for example, doesn't seem to extend to the ability (currently) to write publishable stories.

所以，试着培养一种好的UI设计的感觉。这不仅仅延伸到软件领域。唐·诺曼的《日常事物的设计》是一本经典，还有其他的书。获取一些成功的UI设计的例子，并充分利用它们来感受其中的不同之处。认识到你可能不得不学习一种新的思考问题的方式，并享受它。

十年前，我的UI设计真的很糟糕……我想这些年来帮助我变得更好的是谦逊和追求完美的健康结合。

底线:永远不要对你过去或现在的成就过于满足。从自己和他人的错误中学习。

我尽量与设计相关的网站和文本保持联系。我发现Robin Williams的著作《the Non-Designer’s Design book》在这些研究中也很有趣。

我相信设计和可用性是软件工程中非常重要的一部分，我们应该更多地学习这方面的知识，不要再为我们不应该做设计找借口了。

每个人都可以偶尔成为设计师，每个人也都可以成为程序员。

归根结底，这真的是关于同理心——你能站在用户的角度考虑问题吗?

当然，有一件事是有帮助的，那就是“吃你自己的狗粮”——以真正的用户身份使用你的应用程序，看看什么是令人讨厌的。

另一个好主意是找到一种方法来观察使用应用程序的真实用户，这可能是一个复杂的可用性实验室，有单向反射镜、屏幕视频捕捉、用户身上的摄像机等，也可能是简单的纸上原型，使用下一个碰巧走过大厅的人。

如果所有这些都失败了，请记住，UI过于简单总是比过于复杂要好。我们很容易说“哦，我知道如何解决这个问题，我只要添加一个复选框，这样用户就可以决定他们喜欢哪种模式”。很快你的UI就太复杂了。选择一个默认模式，并使首选项设置为高级配置选项。或者干脆不提。

如果你读了很多关于设计的书，你很容易就会被阴影和圆角等问题所困扰。那不是重要的东西。简单性和可发现性非常重要。

duffymo提醒了我为什么:许多程序员认为“*设计”=“美术”。

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