我认为这是因为一个好的UI是不符合逻辑的。好的UI是直观的。

软件开发人员通常在“直观”方面表现不佳

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

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

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

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

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

用户自上而下地思考，而程序员在开始创建UI时通常是自下而上地思考。

我们(程序员)正在努力地思考如何创建一个数据模型来完成这项工作，并保存所需的数据等等。我们创建UI来整齐地映射到底层模型。以至于我们经常忘记观察我们的用户如何处理相同的任务，而没有进入他们的流程和思维方式。

我们很自然地期望系统的用户以与我们相同的方式思考问题，我们如何存储和处理他们的数据，因此也理解UI期望如何工作。

这通常与他们对任务的看法(和期望)不匹配。

如何解决?我认为一种方法是在向(潜在的)用户展示任何东西之前，实际地询问他们期望程序如何工作。永远不要给他们任何关于我们将如何实现某个功能的提示。与他们一起在纸上创建UI原型，让他们告诉你他们的期望和需求。不要认为任何事情都是理所当然的。

掌机的设计更加自上而下:

在开始开发之前 飞行员，据说是霍金斯带的 一块木头，大小 潜在的飞行员，在他口袋里 的一周。(摘自本文)

他会在木头上模拟要做什么，而不会考虑如何将其实现为代码。每次有了新想法，他就在那块木头上“试试”。

当然，你需要一些指导方针来处理你想到的一些想法，也许不是所有的想法都需要解决，即使我们技术上可以……

请参见要点1(消除选项)和要点3(承诺不足，兑现过多)。

我们是否可以做些什么来重新训练我们的大脑，使其更有效地设计出令人愉悦和有用的演示层?

是的。观察那些试图使用你的软件的用户，不要帮助他们。也被称为可用性测试。

The basic idea of usability testing is that you take someone with a similar background to your target audience, who hasn’t seen your software before and ask them to perform a typical series of tasks. Ideally they should try to speak out loud what they are thinking to give you more insight into their thought processes. You then watch what they do. Critically, you do not assist them, no matter how irresistible the urge. The results can be quite surprising and highly revealing. Usability testing can be very fancy with one way mirrors, video cameras etc, but that really isn’t necessary to get most of the benefits. There is a good description of how to carry out usability tests in Krug’s excellent book Don’t make me think: a common sense guide to web usability. Most of his advice is equally applicable to testing desktop applications.

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