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

一个有用的框架是积极地考虑你在设计一个沟通过程时所做的事情。在非常真实的意义上，你的界面是一种语言，用户必须使用它来告诉计算机该做什么。这导致我们考虑以下几点:

Does the user already speak this language? Using a highly idiosyncratic interface is like communicating in a language you've never spoken before. So if your interface must be idiosyncratic at all, it had best introduce itself with the simplest of terms and few distractions. On the other hand, if your interface uses idioms that the user is accustomed to, they'll gain confidence from the start. The enemy of communication is noise. Auditory noise interferes with spoken communication; visual noise interferes with visual communication. The more noise you can cut out of your interface, the easier communicating with it will be. As in human conversation, it's often not what you say, it's how you say it. The way most software communicates is rude to a degree that would get it punched in the face if it were a person. How would you feel if you asked someone a question and they sat there and stared at you for several minutes, refusing to respond in any other way, before answering? Many interface elements, like progress bars and automatic focus selection, have the fundamental function of politeness. Ask yourself how you can make the user's day a little more pleasant.

实际上，很难确定程序员认为界面交互是什么，除了交流过程之外，但问题可能是它根本没有被认为是任何东西。

部分原因在于，UI设计比看起来要难得多，就像编程比设计师看起来要难得多一样。这两个人对完全不同的事情的担忧程度大不相同，而这一点，除了所需的方法和技能明显不同之外，导致他们关注彼此看不见的问题。

I've found that it helps to describe my app and how to use it to someone without any visual tools whatsoever. It helps focus on what is actually necessary and important and feeds back what can be comprehended quickly by another person. I can do this even before I have a line of code, so it's very cheap to do and doesn't require any artistic skills. The other advantage is that verbalizing the app gets parts of my brain working that otherwise would remain dormant while coding and I can start to "see" the app work (or not work) as I talk.

因为他们通常不是UI设计师。这是一种不同的技能。这是它。

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

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

当开发人员考虑UI时，他们通常会想到他们可以用于这个或这个任务的完美小部件(这里的小部件指的是文本区域、组合框、交互式Ajax搜索字段……)UI，尤其是HCI，应该在较低的层次上考虑。将关于UI的反思分为4个步骤是很有趣的:

任务和概念模型:从开发人员的角度来看，这是最难以理解的。你必须从反思中抽象出你对未来平台的所有想法，以及你可以使用的语言。[Paterno, 97]是该领域的参考文献。将任务定义为树，其中任务有子任务。 下面是一个导出任务的示例。

然后定义抽象UI:这是关于将任务和子任务分组到工作空间。 具体的UI:你现在可以决定使用哪个交互器。现在您应该考虑平台(大屏幕、PDA、移动电话……)。这是钥匙。您的任务模型和抽象UI可以在多个平台中分解。 最后的UI，用选定的编程语言实现。