我们中的一些人只是在UI设计的软方面遇到了困难(尤其是我自己)。“后端编码器”注定只设计业务逻辑和数据层吗?我们是否可以做些什么来重新训练我们的大脑,使其更有效地设计出令人愉悦和有用的演示层?

同事们给我推荐了《网站设计》、《不要让我思考》、《为什么软件很糟糕》等几本书,但我想知道其他人在这方面做了什么来弥补他们的不足?


当前回答

首先,我要说的是,我也有和问题中提到的相似的缺陷。然而,我认为人们做任何事情都很糟糕的唯一原因是:

他们不理解,也从来没有研究过如何和为什么这样做的理论 他们从来没有足够的练习成为专家

所以我的建议是,首先要找到你需要的描述这门学科的书籍和网页,然后学习它们。这里有很多很好的答案,我会把Tog on Interface添加到列表中。同时也要看看那些被认为很棒的ui,如Mac、IPhone和谷歌。

第二步是开始创建ui。这听起来很简单,但如果这不是你的工作描述的一部分,你可能需要在自己的时间做这件事。作为UI开发人员参与web开发项目。也许这是你自己的项目或别人的项目,但擅长创建网页可以给你你所需要的经验,不应该很难做到。好运!

其他回答

一件容易的事。

开发人员不是设计师。他们没有接受过设计方面的培训或尝试学习,所以他们为什么要擅长UI设计之类的东西呢?这几乎等同于在说“为什么会计对某些开发者来说如此困难?”

UI设计本质上是设计,而设计是规则的视觉表现。擅长设计意味着你理解为什么某些东西应该以某种方式显示、运行和表现(例如,为什么链接应该突出显示,或者为什么标题应该在页面顶部)。

设计和开发是两种完全不同的东西,但都需要背景知识和实际工作。如果你不愿意花时间在其中一个科目上,那么你就不会很擅长它,不管你的一个程序/网站看起来有多好。

我建议你从现在做UI的方式开始,不要关注可用性之类的东西。

可选文字 http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

现在想想这个:

一个设计师知道他已经达到了完美,不是当没有什么可以添加的时候,而是当没有什么可以删除的时候。 ——圣艾修伯里

并应用到你的设计中。

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

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

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

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

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

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

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

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

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

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

左脑对右脑。有些人没有艺术感。

我敢打赌,通过学习和勤奋,任何人都可以在界面设计方面做得更好。这并不意味着你会成为一流的美工或设计师。

我认为改进总是有可能的。

与流行的神话相反,在UI设计中实际上没有软方面,至少不需要设计一个好的后端。

考虑以下几点;优秀的后端设计是基于任何优秀开发者都熟悉的原则和元素:

低耦合 高内聚 架构模式 行业最佳实践 等

好的后端设计通常是通过一系列交互产生的,基于测试或实际使用期间获得的可测量反馈,初始蓝图会逐渐改进。有时候,你需要对后端较小的方面进行原型设计,然后单独进行测试等等。

优秀的UI设计是基于以下合理的原则:

可见性 功能可见性 反馈 宽容 简单 一致性 结构

UI也是通过测试和试验,通过迭代诞生的,但不是用编译器+自动化测试套装,而是人。与后端类似,有行业最佳实践、测量和评估技术、考虑UI的方法,并根据用户模型、系统图像、设计师模型、结构模型、功能模型等设定目标。

设计UI所需的技能与设计后端是完全不同的,因此不要指望不先学习就能做出好的UI。然而,这两种活动的共同之处是设计过程。我相信只要花点时间学习,任何能设计好软件的人都有能力设计好UI。

我建议你选一门人机交互的课程,比如在MIT和耶鲁的网站上找一些在线资料:

麻省理工学院用户界面设计与实现课程

结构模型和功能模型的理解和使用

Thorsten79之前的一篇出色的文章提出了软件开发专家和用户之间的话题,以及他们对软件的理解是如何不同的。人类学习专家区分了功能思维模式和结构思维模式。找到去朋友家的路是两者区别的一个很好的例子:

First approach includes a set of detailed instructions: take the first exit of the motorway, then after 100 yards turn left etc. This is an example of functional model: list of concrete steps necessary to achieve a certain goal. Functional models are easy to use, they do not require much thinking just a straight forward execution. Obviously there is a penalty for the simplicity: it might not be the most efficient route and any any exceptional situation (i.e. a traffic diversion) can easilly lead to a complete failure. A different way to cope with the task is to build a structural mental model. In our example that would be a map that conveyes a lot of information about the internal structure of the "task object". From understanding the map and relative locations of our and friend's house we can deduct the functional model (the route). Obviously it's requires more effort, but much more reliable way of completing the task in spite of the possible deviations.

通过UI传递功能模型或结构模型(例如,向导模式还是高级模式)之间的选择并不像Thorsten79的帖子中看起来那样简单。高级和频繁的用户可能更喜欢结构模型,而偶尔或缺乏经验的用户-功能。

谷歌地图就是一个很好的例子:它们包括功能和结构模型,许多卫星导航也是如此。

问题的另一个方面是,通过UI呈现的结构模型不能映射到软件的结构,而应该自然地映射到手头的用户任务或涉及的任务对象的结构。

这里的困难在于,许多开发人员对他们的软件内部有一个良好的结构模型,但只有软件旨在协助的用户任务的功能模型。要构建好的UI,你需要理解任务/任务对象结构,并将UI映射到该结构。

无论如何,我仍然强烈建议参加一个正式的HCI课程。这涉及到很多东西,比如启发式,源自格式塔心理学的原则,人类的学习方式等等。