我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?
同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?
我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?
同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?
当前回答
部分原因在于,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期望如何工作。
这通常与他们对任务的看法(和期望)不匹配。
如何解决?我认为一种方法是在向(潜在的)用户展示任何东西之前,实际地询问他们期望程序如何工作。永远不要给他们任何关于我们将如何实现某个功能的提示。与他们一起在纸上创建UI原型,让他们告诉你他们的期望和需求。不要认为任何事情都是理所当然的。
掌机的设计更加自上而下:
在开始开发之前 飞行员,据说是霍金斯带的 一块木头,大小 潜在的飞行员,在他口袋里 的一周。(摘自本文)
他会在木头上模拟要做什么,而不会考虑如何将其实现为代码。每次有了新想法,他就在那块木头上“试试”。
当然,你需要一些指导方针来处理你想到的一些想法,也许不是所有的想法都需要解决,即使我们技术上可以……
请参见要点1(消除选项)和要点3(承诺不足,兑现过多)。
已经有很多好的评论了,所以我不确定还有什么可以补充的。 但仍…
为什么开发者希望能够设计出优秀的UI? 他在那个领域受过多少训练? 他读了多少书? 他在这几年里设计了多少东西? 他有机会看到用户的反应吗?
我们不期望一个随机的“水管工乔”能够写出好的代码。 那么,为什么我们要期望随机的“程序员乔”设计出优秀的UI呢?
移情有帮助。将UI设计和编程分离是有帮助的。可用性测试有帮助。
但是UI设计是一门需要学习和实践的手艺。
真正帮助我改进设计的是找一个开发人员,QA人员、项目经理或任何碰巧路过的人,让他们尝试特定的小部件或屏幕。
当你看到别人第一次使用你的软件时,你会惊奇地发现
我建议你从现在做UI的方式开始,不要关注可用性之类的东西。
可选文字 http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg
现在想想这个:
一个设计师知道他已经达到了完美,不是当没有什么可以添加的时候,而是当没有什么可以删除的时候。 ——圣艾修伯里
并应用到你的设计中。
我知道,当我制作出一个糟糕的UI时,几乎总是因为我过于专注于它的特定部分。
在开发和测试一个特定功能的过程中,我几乎总是会多次使用它。
在我检查了十几次之后,我就处于这样一种心态:我确切地知道我要做什么,也确切地知道我需要做什么才能让程序按我想要的做。我也和观看这个特定的作品功能本身,一遍又一遍,直到它“完成”。当我在测试时,我会快速浏览应用程序/菜单/工作流/其他内容。
用户的情况完全不同。他们没有把软件的这一部分看作一个独立的“块”。他们并不总是经常这样做,当他们经常这样做的时候,他们肯定不会经常独自做。他们不会像开发人员那样“跳过”过程的其余部分,只专注于这一部分。
重要的是试着看UI,然后思考“我应该用它做什么?”如果不清楚,说明你做错了。我们所处的情况是,我们知道软件需要什么输入,我们只是想办法获得这些输入。用户所处的情况是他们想要某种结果,他们想知道他们必须做什么才能得到这个结果。