我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?
同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?
我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?
同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?
当前回答
我坚持的主要经验法则是,永远不要同时做两件事。如果我正在处理后端代码,我将完成这一工作,休息一下,然后带着我的UI帽子返回。如果你在编写代码时尝试使用它,你将以错误的心态处理它,结果会得到一些糟糕的界面。
我认为同时成为一名优秀的后端开发人员和一名优秀的UI设计师是完全可能的,你只需要努力工作,阅读和研究相关主题(从Miller的#7到Nielsen的档案),并确保你理解UI设计的重要性。
我不认为这是一个需要创造性的案例,而是像后端开发一样,这是一个非常有方法,非常结构化的事情,需要学习。正是人们对ui的“创造性”创造了一些最大的可用性怪物……我的意思是,首先看看100%使用Flash的网站……
编辑:克鲁格的书真的很好……一定要读一读,特别是如果你要为网络设计的话。
其他回答
“好的UI设计”其实是两个问题:
获得正确的设计 正确的设计
两者都是难题。以我的经验来看,这两件事应该并行进行,这样才能避免在项目后期出现糟糕的惊喜(“为什么我们在IE8中拖放的速度非常慢??”你说它无法修复是什么意思??”)
为了得到正确的设计,你必须探索各种可能性。书籍可以引导你尝试对你的情况最有意义的事情-经验当然更好。此外,你绝对需要来自真实用户的反馈——否则你怎么才能发现设计已经是正确的呢?)你当然看不出来。继续阅读!)
“使设计正确”是下一个问题,因为这意味着必须执行你认为合适的设计。
那些“用户体验/图形用户界面”的事情是如此困难,因为找到正确的答案包括理解人类想要什么——他们不能客观地告诉你,而你也不能从“外部”找到。这意味着(经验)引导的试错方法是唯一可行的方法。
为了更清楚地回答你的问题:
为什么优秀的UI设计对某些人来说如此困难 重击
对于硬核开发人员来说,一个大问题是,他们对软件如何工作的理解与用户认为它如何工作的理解是非常不同的(例如,URL“www.stackoverflow.com”应该写成“com.stackoverflow.com”,如果你知道DNS如何工作的话。但试着销售一个浏览器,它期望url:))。
作为旁注:我建议你着眼于“体验设计”而不是“用户界面设计”,但这是另一个故事。
UI设计是一种完全不同的技能。它与视觉艺术密切相关——能够欣赏和创造视觉对称和美。不管出于什么原因,通常程序员都不擅长视觉艺术。我知道有例外,但作为一般规则,这是成立的。
所以真的(除非你是这条奇怪规则的例外)——这应该像处理其他你没有天赋的领域一样。你应该评估一下自己是否能和现有的技能很好地相处——或者甚至可以在有机会的时候花点精力来改进。然而,你最好在自己擅长的领域发展,也许可以寻求在你所不擅长的领域与高手合作。
Marcus Buckingham写的《现在,发现你的优势》是一本很好的书。这本书很容易读。
我坚持的主要经验法则是,永远不要同时做两件事。如果我正在处理后端代码,我将完成这一工作,休息一下,然后带着我的UI帽子返回。如果你在编写代码时尝试使用它,你将以错误的心态处理它,结果会得到一些糟糕的界面。
我认为同时成为一名优秀的后端开发人员和一名优秀的UI设计师是完全可能的,你只需要努力工作,阅读和研究相关主题(从Miller的#7到Nielsen的档案),并确保你理解UI设计的重要性。
我不认为这是一个需要创造性的案例,而是像后端开发一样,这是一个非常有方法,非常结构化的事情,需要学习。正是人们对ui的“创造性”创造了一些最大的可用性怪物……我的意思是,首先看看100%使用Flash的网站……
编辑:克鲁格的书真的很好……一定要读一读,特别是如果你要为网络设计的话。
一个有用的框架是积极地考虑你在设计一个沟通过程时所做的事情。在非常真实的意义上,你的界面是一种语言,用户必须使用它来告诉计算机该做什么。这导致我们考虑以下几点:
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.
实际上,很难确定程序员认为界面交互是什么,除了交流过程之外,但问题可能是它根本没有被认为是任何东西。
我为社交圈之外的人设计了一个程序,并观察他们的行为。在这样做的过程中,我不再受制于朋友们的偏见,也不再受制于我自己的骄傲和自我。在改进应用程序的过程中,我变得更加谦虚,对设计问题更加敏感。我学到了以任务为导向的设计和简单的重要性。我明白了拥有太多功能的代价。有了经验,你也会的。
我强烈推荐一些参考资料:
Joelonsoftware杰夫·拉斯金的“人性化界面” 罗宾·威廉的《非设计师设计指南》 大多数UI文章都在alistapart上 Jwz关于编程的博客 苹果人机界面指南
我强烈建议你忽略一些参考文献和哲学:
“主题” 一般的桌面应用程序,除非您需要访问驱动程序/文件系统 “越多越好”的理念