原因有很多。

(1)开发者不能站在用户的角度看问题。这是通常的怀疑:缺乏同理心。但这通常不是真的，因为开发人员并不像人们想象的那样陌生。

(2)另一个更常见的原因是，开发人员太接近自己的东西，在他的东西上呆了这么长时间，没有意识到其他人可能并不那么熟悉他的东西(这是一个比直觉更好的术语)。

(3)还有一个原因是开发人员缺乏技术。

我的最大主张:阅读任何UI，人类交互设计，原型书。例如:设计显而易见的:一种Web应用程序设计的常识方法，不要让我思考:一种Web可用性的常识方法，设计时刻，等等。

他们如何讨论任务流程?他们如何描述决策点?也就是说，在任何用例中，至少有3条路径:成功、失败/异常、替代。

因此，从点A，你可以去A.1, A.2, A.3。 从点A.1，你可以得到A.1.1, A.1.2, A.1.3，等等。

他们如何显示这种向下钻取的任务流程? 他们没有。他们只是掩饰它。

因为即使是UI专家也不具备技术，所以开发者也没有机会。 他认为这在他的头脑中是清楚的。但它甚至在纸上都不清楚，更不用说在软件实现中了。

我必须用我自己的手工制作技术。

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

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

无论你怎么做(上面有一些很棒的观点)，它真的帮助了我，一旦我接受了没有这样的事情作为直觉....

我能听到地平线上争论的隆隆声……我来解释一下。

直觉的:基于一种无意识的方法或感觉，使用自己感觉正确或真实的东西。

如果(正如卡尔·萨根(Carl Sagan)所假设的那样)你接受你无法理解与你所遇到过的任何事物完全不同的事物，那么如果你从未使用过类似的东西，你怎么可能“知道”如何使用它呢?

想想看:孩子们试图打开门，不是因为他们“知道”门把手是如何工作的，而是因为他们看过别人这样做……他们经常把旋钮转错方向，或者拉得太快。他们必须学会如何使用门把手。然后，这一知识被应用到不同但相似的例子中:打开窗户，打开抽屉，打开几乎任何有大把手的大东西。

即使是对我们来说很直观的简单事情，对来自其他文化的人来说也完全不是直观的。如果有人把他们的手臂伸出在他们面前，并放弃他们的手在手腕上，同时保持手臂静止....他们放弃你了吗?可能吧，除非你在日本。在那里，这个手势可以表示“过来”。那么谁是对的呢?当然，两者都有各自的背景。但如果你两个都去过，你就需要了解它们……UI设计。

我试着找到我项目的潜在用户已经“熟悉”的东西，然后围绕他们构建UI:以用户为中心的设计。

看看苹果的iPhone吧。即使你讨厌它，你也必须尊重它所付出的心血。它完美吗?当然不是。随着时间的推移，物体感知的“直觉性”可能会增长，甚至完全消失。

为例。大多数人都知道，一条顶部和底部有两排孔的黑色带子看起来像一条薄膜带……真的是这样吗?

问问普通9岁或10岁的孩子，他们是怎么想的。你可能会感到惊讶，现在有多少孩子很难把它认出来是电影连环画，即使它仍然被用来代表好莱坞，或任何与电影有关的东西。过去20年里，大多数电影都是用数字技术拍摄的。我们最后一次拿着照片或胶片是什么时候?

所以，对我来说，这一切都归结为:了解你的受众，不断研究，以跟上“直观”事物的趋势和变化，瞄准你的主要用户，尽量不要为了支持高级用户而惩罚没有经验的用户，或者为了帮助新手而减慢高级用户的速度。

最终，每个程序都需要用户经过一定程度的培训才能使用。培训多少以及针对哪个级别的用户是需要做出决策的一部分。

根据您的目标用户过去作为人类、计算机用户或学生的经验水平，有些东西或多或少是熟悉的。

我只是瞄准钟形曲线中最胖的部分，并试图获得尽可能多的人，但意识到我永远不会取悦所有人....

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

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

用户体验设计和软件开发绝不是相互排斥的技能。相反，它们都需要常识和逻辑，注重细节，能够看到大局。所以，如果你是一名优秀的开发人员，你就有机会成为一名优秀的UX设计师!

它们看起来可能是相互排斥的，因为许多开发人员没有UX设计经验，反之亦然。此外，如果你在考虑用户体验设计之前就开始考虑架构、框架或语言，这可能会把你引向错误的方向。

原因有很多。

(1)开发者不能站在用户的角度看问题。这是通常的怀疑:缺乏同理心。但这通常不是真的，因为开发人员并不像人们想象的那样陌生。

(2)另一个更常见的原因是，开发人员太接近自己的东西，在他的东西上呆了这么长时间，没有意识到其他人可能并不那么熟悉他的东西(这是一个比直觉更好的术语)。

(3)还有一个原因是开发人员缺乏技术。

我的最大主张:阅读任何UI，人类交互设计，原型书。例如:设计显而易见的:一种Web应用程序设计的常识方法，不要让我思考:一种Web可用性的常识方法，设计时刻，等等。

他们如何讨论任务流程?他们如何描述决策点?也就是说，在任何用例中，至少有3条路径:成功、失败/异常、替代。

因此，从点A，你可以去A.1, A.2, A.3。 从点A.1，你可以得到A.1.1, A.1.2, A.1.3，等等。

他们如何显示这种向下钻取的任务流程? 他们没有。他们只是掩饰它。

因为即使是UI专家也不具备技术，所以开发者也没有机会。 他认为这在他的头脑中是清楚的。但它甚至在纸上都不清楚，更不用说在软件实现中了。

我必须用我自己的手工制作技术。