当前位置:  开发笔记 > 后端 > 正文

为什么好的UI设计对某些开发人员来说如此困难?

如何解决《为什么好的UI设计对某些开发人员来说如此困难?》经验,为你挑选了18个好方法。

我们中的一些人在UI设计的柔和方面(特别是我自己)很难过."后端编码器"注定只是设计业务逻辑和数据层吗?我们可以做些什么来重新训练我们的大脑,以便更有效地设计令人愉悦和有用的表现层?

同事们推荐了几本书,包括网站设计,不要让我思考,为什么软件很糟糕,但我想知道其他人为消除这方面的不足做了什么?



1> Thorsten79..:

我直接说吧:

对此的改进并非始于准则.它首先重新构建您对软件的看法.

大多数核心开发人员对其软件用户几乎没有同情心.他们不知道用户如何思考,用户如何构建他们使用的软件模型以及他们如何使用计算机.

当专家与外行人发生碰撞时,这是一个典型的问题:一个正常人怎么会这么愚蠢,不明白专家10年前的理解?

对于几乎所有经验丰富的开发人员而言,难以理解的首要事实之一是:

普通人的软件概念与你的概念截然不同.他们对编程没有任何线索.没有.零.他们甚至都不关心.他们甚至认为他们不必关心.如果你强迫他们,他们将删除你的程序.

现在,这对开发者来说是难以置信的苛刻.他为自己生产的软件感到自豪.他喜欢每一个功能.他可以准确地告诉你它背后的代码是如何工作的.也许他甚至发明了一种令人难以置信的巧妙算法,使其比以前快50%.

并且用户不在乎.

真是个傻瓜.

许多开发人员无法与普通用户合作.他们因不存在的技术知识而感到沮丧.这就是为什么大多数开发人员回避并认为用户必须是白痴的原因.

他们不是.

如果软件开发商购买汽车,他希望它能顺利运行.他通常不关心轮胎压力,机械微调对于使其以这种方式运行非常重要.在这里,他不是专家.如果他买了一辆没有微调的汽车,他就把它还给他买一辆能做他想要的东西.

很多软件开发者喜欢电影.精心制作的电影激发他们的想象力.但他们不是制作电影,制作视觉效果或编写优秀电影剧本的专家.大多数书呆子在表演时非常非常非常糟糕,因为它只是表现出复杂的情感而很少涉及分析.如果一个开发人员观看一部糟糕的电影,他只是注意到它整体上是坏事.书呆子甚至建立了IMDB来收集有关好的和坏的电影的信息,以便他们知道要观看哪些以及要避免哪些.但他们不是创作电影的专家.如果电影不好,他们就不会去看电影(或者不从BitTorrent下载;)

所以它归结为:作为专家回避普通用户是无知.因为在这些领域(并且有很多)他们不是专家,他们希望其他领域的专家已经考虑过使用他们的产品或服务的正常人.

你能做些什么来补救它?作为一名程序员,你的核心越多,你对普通用户的思考就越不开放.对你来说,这将是陌生和无知的.你会想:我不能想象人们会永远使用一台计算机与该知识的缺乏.但他们可以.对于每个UI元素,请考虑:是否有必要?它是否适合用户对我的工具的概念?我怎么能让他理解?请阅读有关这方面的可用性,有很多好书.这也是整个科学领域.

啊,在你说之前,是的,我是苹果粉丝;)


+1这就是Linux仍然没有为普通用户的桌面做好准备的原因.
+1.我建议阅读"囚犯正在运行庇护",它详细介绍了用户/开发者心态的差异,以及一些补救措施.
+1老实说,任何不关心用户的开发人员都是一个糟糕的开发人员!
优秀评论!你已经确定了软件设计中最基本的障碍之一.对于经验丰富的开发人员(比如我)而言,这是一个难以接受的事实,但实际情况往往是这样.
非常有效的观点,我认为这种心态也是许多开发人员运行的项目(例如开源或者你有什么)难以使用的原因的一部分 - 大多数开发人员为用户自己写,而不是为"真正的"最终用户.
该死的我希望我能不止一次投票.你是对的..FullStop
除了苹果的赞赏之外,我完全赞同所有要点.毕竟,我们不是"愚蠢"的终端用户,不是吗?:)
+1 API Design的相同问题.大多数开发人员设计的API只考虑他们自己,而不是API的客户端.这会导致臃肿,不一致,完全无法使用的API.
我个人认为大多数程序员/硬核技术人员不仅不愿意进入用户的行列,大多数人根本无法做到.很难掌握关于某个主题(编程)的大量知识,然后在不使用所有知识的同时查看某个事物(程序).将它与多年来驾驶汽车的人相比,突然被要求开始表现得好像他没有.

2> Karl Fast..:
UI设计很难

对于这个问题:

为什么UI设计对大多数开发人员来说如此困难

试着问相反的问题:

为什么大多数UI设计师编程如此困难?

编写UI和设计UI需要不同的技能和不同的思维方式.UI设计对于大多数开发人员来说很难,而不是一些开发人员,就像编写代码对大多数设计师而不是某些设计师来说很难

编码很难.设计也很难.很少有人做得很好.优秀的UI设计师很少编写代码.他们甚至可能不知道如何,但他们仍然是优秀的设计师.那么优秀的开发人员为什么要对UI设计负责呢?

了解有关UI设计的更多信息将使您成为更好的开发人员,但这并不意味着您应该负责UI设计.设计师的情况恰恰相反:知道如何编写代码将使他们成为更好的设计师,但这并不意味着他们应该负责编写UI.

如何更好地进行UI设计

对于想要在UI设计方面做得更好的开发人员,我有3条基本建议:

    将设计视为一项独立技能.编码和设计是分开但相关的.UI设计不是编码的子集.它需要不同的思维方式,知识库和技能组.有些人专注于UI设计.

    了解设计.至少一点点.尝试从下面的长列表中学习一些设计概念和技术.如果你更有抱负,可以阅读一些书籍,参加会议,上课,获得学位.有很多方法可以学习设计.Joel Spolky关于UI设计的书对于开发人员来说是一本很好的入门书,但是它还有更多内容,而这正是设计师们所面对的.

    与设计师合作.好的设计师,如果可以的话.做这项工作的人有各种各样的头衔.今天,最常见的标题是用户体验设计师(UXD),信息架构师(IA),交互设计师(ID)和可用性工程师.他们在考虑代码的同时考虑设计.你可以从他们那里学到很多东西,也可以从他们那里学到 尽管你可以和他们一起工作.在贵公司找到具备这些技能的人员.也许你需要雇人.或者参加一些会议,参加网络研讨会,并在UXD/IA/ID世界中花时间.

以下是您可以学习的一些具体事项.不要试图学习一切.如果你知道下面的一切,你可以称自己为交互设计师或信息架构师.从列表顶部附近的东西开始.专注于特定的概念和技能.然后向下移动并分支出去.如果你真的喜欢这些东西,那就把它当作职业道路吧.许多开发人员进入管理层,但UX设计是另一种选择.

学习基本的设计理念.您应该了解可供性,可见性,反馈,映射,Fitt定律,poka-yokes等.我推荐阅读日常用品设计(唐诺曼)和通用设计原则(Lidwell,Holden,&Butler)

了解用户体验.这正成为以人为本的网站,应用程序和任何其他数字工件设计的总称.这里的经典入门是用户体验的元素(Jesse James Garrett).您可以从作者的网站上获得概述和前几章.

学习草图设计.草绘是探索设计选项和找到合适设计的快捷方式,而可用性测试则是设计正确.在早期设计阶段,纸张原型制作快速,便宜且有效.比编码数字原型快得多.这里的关键文字是草绘用户体验:获得正确的设计和正确的设计(Bill Buxton).在与IA/ID/UX设计人员合作时,草绘是一项特别有用的技能.您的协作将更有效.有关设计师素描的方式和原因的详细介绍,请观看演示文稿如何成为 Leah Buley在2008年IA峰会上的用户体验团队.

学习纸张原型.在编写代码之前迭代测试接口的最快方法.不同于草图和可用性测试.这里的权威着作是Paper Prototyping(Carolyn Snyder).您可以从尼尔森诺曼集团那里获得一张好DVD .

学习可用性测试.折扣测试简单有效.但是对于许多UI来说,可用性很难做得很好.您可以快速学习基础知识,但良好的可用性是非常宝贵的.如果你想要一本书,那么经典就是可用性测试手册(Jeffrey Rubin).它比较旧,但提供了基于实验室的测试的全面覆盖.着名的入门书是" 不要让我思考"(第二版)(史蒂夫·克鲁格).我提醒人们注意这一点:Krug让它听起来比现在更容易.但这是一个很好的起点.下一点列出的用户研究书籍也涵盖了这一主题.你可以在网上找到关于它的堆.

了解信息架构.这里的主要书籍是万维网的信息架构(第3版)(Louis Rosenfeld和Peter Morville).一本好的入门书是信息架构:网络蓝图(Christina Wodtke).欲了解更多信息,请访问信息架构研究所或参加年度信息架构峰会.

了解交互设计.这里的主要书籍是交互设计要点(第3版)(Alan Cooper ).一本好的入门书是Designing for interaction(Dan Saffer).有关更多信息,请访问交互设计协会(IxDA)或参加年度交互设计会议.

学习平面设计的基础知识.图形设计不是UI设计,但图形设计的概念可以改善界面.图形设计引入了视觉呈现信息的设计原则,例如接近度,对齐和小倍数.我推荐阅读非设计师的设计书(Robin Williams)和Envisioning Information(Edward Tufte)

学习做用户研究.在可用性测试界面的地方,用户研究尝试通过角色,场景,用户旅程和其他文档对用户及其任务进行建模.它是关于理解用户及他们做什么,然后使用它来通知设计而不是猜测.一些技巧是访谈,调查,日记研究和购物车分类.关于这方面的好书是观察用户体验(Mike Kuniavsky)和了解用户(Courage&Baxter)

学习做实地研究.在人工条件下观察实验室中的人有助于(即:可用性),但没有什么比观看人们在上下文中使用您的代码:他们的家,办公室或他们使用它的任何地方.各种名称,包括民族志,实地研究和背景调查.这是一个很好的实地研究入门书.这里有两本比较着名的书籍是快速上下文设计(Karen Holtzblatt )和用户和任务分析界面设计(Hackos&Redish).

阅读UX设计网站.一些大的是Boxes&Arrows,UX Mag,UX Matters和Digital Web杂志.

使用UI模式库.有接口模式.对于网站,我推荐The Design of Sites,2nd ed(Van Duyne,et al)和主页可用性:50个网站解构(Jakob Nielsen和Marie Tahir).对于桌面应用程序,我建议设计界面(Jennifer Tidwell),对于Web应用程序,我建议设计Web界面:丰富交互的原则和模式(Bill Scott和Theresa Neil).在线您应该检查Welie模式库,UI模式和Web UI模式.

参加UX设计会议.一些优秀的年度会议是:信息架构峰会,互动'09(IxDA),用户界面和用户体验周.

参加研讨会或网络研讨会.您可以参加研讨会,网络研讨会和在线课程.这远不是一个全面的列表,但您可以尝试UCE虚拟研讨会,Adaptive Path虚拟研讨会和Rosenfeld Media的UX网络研讨会.

获得学位.HCI的研究生学位是一种方法,但这些课程主要是编写代码.如果您想了解数字工件和设备的设计,那么您需要一个不在CS中的研究生课程.一些选项包括Carnegie Mellon的交互设计,斯坦福大学的d-School ,纽约大学的ITP项目以及信息架构和知识管理在肯特州(披露:我在肯特大学就读;我们看到越来越多的人将CS学位转变为用户体验设计而不是管理,这很有趣,因为管理层是开发人员想要离开的传统途径在他们的领域留下来编写代码).还有更多的节目.每个人都有自己的观点,重点领域和技术期望.一些来自艺术和视觉设计,一些来自图书馆和信息科学,一些来自CS.大多数是杂交种,但每种杂种都在一个或多个领域有更深的根源.如果您对此感兴趣,请环顾四周并尝试了解这些程序之间的差异.除了完整的学位,有些还提供在线课程和证书课程.

为什么UI设计很难

良好的UI设计很难,因为它涉及两种截然不同的技能:

对机器的深刻理解.这个群体中的人首先担心代码,然后是人.他们拥有深厚的技术知识和技能.我们称他们为开发人员,程序员,工程师等.

对人和设计的深刻理解:这个群体中的人首先担心人,代码是第二.他们深入了解人们如何与信息,计算机以及周围世界互动.我们称之为用户体验设计师,信息架构师,交互设计师,可用性工程师等.

这是开发人员和设计人员之间这两组之间的本质区别:

开发人员使其工作.他们在你的TiVo,你的iPhone,你最喜欢的网站等上实现了这些功能.他们确保它实际上做了它应该做的事情.他们的首要任务是让它发挥作用.

设计师让人们喜欢.他们弄清楚如何与它互动,它应该如何看,以及它应该如何感觉.他们设计了使用应用程序,网站和设备的体验.他们的首要任务是让你爱上开发人员.这就是用户体验的含义,与品牌体验不同.

此外,编程和设计需要不同的思维模式,而不仅仅是不同的知识和不同的技能.良好的UI设计需要思维模式,知识库和技能组.掌握任何一个都需要数年时间.

开发人员应该期望难以找到UI设计,就像UI设计者应该期望找到编写代码一样困难.


这是最好的答案.很棒的链接BTW!
为什么这不是最佳答案?它似乎远比Thorsten79的答案要好.

3> Kevin..:

真正帮助我改进设计的是抓住一位开发人员,一位QA人员,一位PM,或任何偶然走过的人,让他们尝试一个特定的小部件或屏幕.

当您第一次看到其他人使用您的软件时,您会发现它的惊人之处


我相信它被称为"走廊可用性测试"

4> Jacob Mattis..:

最终,它真的是关于同理心 - 你能让自己置身于用户之中吗?

当然,有一件事有助于"吃你自己的狗食" - 自己使用你的应用程序作为真正的用户,并看到什么是令人讨厌的.

另一个好主意是找到一种方法来使用您的应用程序观看真实用户,这可能像使用单向镜,屏幕视频捕获,用户上的摄像机等的可用性实验室一样复杂,或者可以如此简单作为纸质原型使用下一个碰巧走在大厅里的人.

如果所有其他方法都失败了,请记住,UI过于简单而不是太复杂,几乎总是更好.很容易说"哦,我知道如何解决这个问题,我只需添加一个复选框,以便用户可以决定他们喜欢哪种模式".很快你的UI太复杂了.选择默认模式并使首选项设置为高级配置选项.或者只是把它留下来.

如果您阅读了很多关于设计的内容,您可以轻松地将它们挂在阴影和圆角上等等.那不是重要的东西.简单性和可发现性是重要的东西.



5> Vlad Gudim..:

与流行的神话相反,UI设计中几乎没有软性方面,至少不需要设计一个好的后端.

考虑以下; 良好的后端设计基于相当坚实的原则和元素,任何优秀的开发人员都熟悉:

低耦合

高凝聚力

建筑模式

行业最佳实践

等等

良好的后端设计通常通过多种交互产生,其中基于在测试或实际使用期间获得的可测量的反馈,初始蓝图逐渐改进.有时您需要对后端的较小方面进行原型设计并在隔离中对其进行试验等.

良好的UI设计基于以下原则:

能见度

启示

反馈

公差

简单

一致性

结构体

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

设计UI所需的技能与设计后端完全不同,因此不希望在没有先学习的情况下能够做好UI.然而,这两种活动的共同点是设计过程.我相信任何可以设计好软件的人都能够设计好的UI,只要他们花一些时间学习如何.

我建议参加人机交互课程,查看麻省理工学院和耶鲁大学网站的在线资料:

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

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

Thorsten79早期的优秀帖子提出了软件开发专家与用户的主题以及他们对软件的理解有何不同.人类学习专家区分功能和结构心理模型.找到你朋友家的方式可以很好地说明两者之间的区别:

第一种方法包括一系列详细说明:走高速公路的第一个出口,然后在100码左转后等.这是功能模型的一个例子:实现某个目标所需的具体步骤清单.功能模型易于使用,它们不需要太多考虑直接执行.显然,简单性会受到惩罚:它可能不是最有效的路线,任何特殊情况(即交通分流)都可能导致完全失败.

处理任务的另一种方法是建立结构心理模型.在我们的示例中,这将是一个传达有关"任务对象"内部结构的大量信息的地图.通过了解我们和朋友家的地图和相对位置,我们可以推断出功能模型(路线).显然,这需要更多的努力,但是尽管存在可能的偏差,但更可靠的方式来完成任务.

通过UI传递功能或结构模型(例如,向导与高级模式)之间的选择并不像Thorsten79的帖子那样直截了当.高级和频繁的用户可能更喜欢结构模型,而偶尔或不太经验的用户 - 功能性.

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

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

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

无论如何,我仍然不能建议强烈要求正式的HCI课程.有许多涉及的东西,如启发式,源自格式塔心理学的原理,人类学习的方式等.



6> Hoffmann..:

我建议你从现在开始做所有的UI,而不是关注可用性和东西.

alt text http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

现在想想这个:

设计师知道他已经达到了完美状态,而不是在没有任何东西可以添加的时候,但是什么时候没有什么东西可以带走. - Saint-Exupéry

并将其应用于您的设计中.


您应该选择打印视图...现在无法看到标尺.

7> thursdaysgee..:

许多开发人员认为,因为他们可以编写代码,所以他们可以做到这一切.设计界面是一种完全不同的技能,当我上大学时根本没有教过它.这不仅仅是自然而然的事情.

另一本好书是唐纳德·诺曼的"日常生活设计".



8> Uri..:

设计和美学之间存在巨大差异,而且它们经常被混淆.

美丽的用户界面需要艺术或至少是美学技能,许多人,包括我自己,都无法生产.不幸的是,它还不够,并且不能使UI可用,正如我们在许多重量级基于闪存的API中看到的那样.

制作可用的UI需要了解人类如何与计算机交互,心理学中的一些问题(例如,菲特定律,希克定律)以及其他主题.很少有CS课程为此训练.我知道很少有开发人员会通过JUnit书等选择用户测试书.

我们中的许多人也是"核心程序员",倾向于将UI视为外观,而不是可以决定我们项目成功与否的因素.

此外,大多数UI开发经验都非常令人沮丧.我们可以使用像旧VB这样的玩具GUI构建器,并且必须处理丑陋的胶水代码,或者我们使用的API会让我们感到沮丧,比如试图在Swing中整理布局.



9> David Thornl..:

转到Slashdot,阅读有关Apple的任何文章的评论.你会发现很多人都在谈论苹果产品如何与众不同,并将iPod和iPhone的成功归功于那些想要时尚或时尚的人.他们通常会浏览功能列表,并指出他们没有做任何早​​期MP3播放器或智能手机没有做的事情.

然后有些人喜欢iPod和iPhone,因为他们可以简单轻松地完成用户想要的操作,而无需参考手册.接口与接口一样直观,令人难忘且易于发现.我不喜欢MacOSX上的用户界面,就像我在早期版本中那样,我认为他们已经放弃了一些有利于浮华的用处,但iPod和iPhone是精湛设计的例子.

如果你在第一个阵营,你不会想到一般人的方式,因此你可能会制造糟糕的用户界面,因为你无法从好的用户界面告诉他们.这并不意味着你没有希望,而是你必须明确地学习良好的界面设计原则,以及如何识别一个好的UI(就像Asperger的某些人可能需要明确地学习社交技能).显然,只是有一个良好的用户界面并不意味着你可以做一个; 例如,我对文学的欣赏似乎并没有扩展到(目前)编写可发表的故事的能力.

因此,尝试培养良好的UI设计感.这不仅仅是软件.Don Norman的"日常事物的设计"是一部经典,还有其他书籍.获取成功的UI设计示例,并充分利用它们来感受差异.认识到你可能不得不学习一种新的思维方式,并享受它.


我个人觉得Apple产品使用起来非常不直观.我想我不是唯一一个在每次开始慢跑时他们的第一个iPod开始洗牌的人,或者为什么iPhone屏幕不断反转时感到沮丧的人.我认为只应通过直接,明确的用户操作来实现.

10> James B..:

我坚持的主要经验法则是不要试图同时做两件事.如果我正在处理后端代码,我将完成这项工作,休息一下,并返回我的UI帽子.如果您在编写代码时尝试使用它,那么您将以错误的思维方式处理它,并最终导致一些可怕的界面.

我认为绝对有可能成为一名优秀的后端开发人员和优秀的UI设计师,你只需要工作,对这个主题进行一些阅读和研究(从米勒的#7到尼尔森的档案),并制作确定你理解为什么 UI设计是最重要的.

我不认为这是一个需要创造性的案例,而是像后端开发一样,它是一个非常有条理,非常有条理的东西,需要学习.人们通过用户界面获得"创造性"创造了一些最大的可用性怪物......我的意思是,看看100%的Flash网站,一开始......

编辑:Krug的书非常好......请仔细阅读,特别是如果您要为Web设计.



11> 小智..:

这件事情是由很多原因导致的.

(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 experst也没有技术,开发人员也没有机会.他认为他脑子里很清楚.但它在纸面上甚至不清楚,更不用说在软件实现中明确了.

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



12> Edwin Jarvis..:

我尝试与特定于设计的网站和文本保持联系.我还发现了优秀的罗宾威廉姆斯书籍非设计师的设计书在这些研究中非常有趣.

我相信设计和可用性是软件工程中非常重要的一部分,我们应该更多地学习并停止给我们不应该做设计的借口.

每个人偶尔都可以成为一名设计师,每个人都可以成为程序员.


我的意思是,偶尔,这并不意味着这个人将是一个*优秀的*程序员或永远是它.

13> Rex M..:

在接近UI设计时,以下是我始终牢记的一些事项(到目前为止还没有完整列表):

沟通模型.UI是一种叙述,向用户解释心智模型.这个模型可能是一个业务对象,一组关系,你有什么.视觉突出,空间放置和工作流程排序都在将此模型传达给用户方面发挥作用.例如,某种列表与另一种列表意味着不同的事物,以及列表中的内容与模型的其余部分之间的关​​系.总的来说,我发现最好确保一次只传达一个模型.程序员经常尝试在同一UI空间中传递多个模型或多个模型的一部分.

一致性.重用流行的UI隐喻有很大帮助.内部一致性也很重要.

分组任务.用户不必在屏幕上一直移动鼠标来验证或完成相关的命令序列.模态对话框和弹出菜单在这方面尤其糟糕.

了解您的受众.如果您的用户将一遍又一遍地执行相同的活动,他们将很快成为这些任务的高级用户,并且会因为尝试降低初始进入障碍而感到沮丧.如果您的用户不经常进行许多不同类型的活动,最好确保用户界面始终掌握他们的手牌.



14> Marco Luglio..:

阅读Apple人机界面指南.



15> 小智..:

我发现UI设计中最好的工具是观看首次尝试使用该软件的用户.拿出大量笔记并问他们一些问题.切勿指导或尝试解释软件的工作原理.这是UI的工作(以及编写良好的文档).

我们在所有项目中始终采用这种方法.以一种您从未考虑过的方式观看用户与软件的交易总是令人着迷.

为什么UI设计如此之难?一般来说,因为开发人员和用户永远不会见面



16> nailitdown..:

duffymo只是提醒我原因:许多程序员认为"*Design"=="Art".

良好的UI设计绝对不是艺术.它遵循可靠的原则,如果您有时间进行研究,可以使用数据进行备份.

我认为所有程序员需要做的就是花时间学习原理.我认为,无论何时我们能够应用最佳实践,无论是代码还是布局,都是我们的本性.我们所要做的就是让自己了解我们工作这方面的最佳实践.



17> Dhaust..:

我做了什么才能在UI设计方面做得更好?
注意它!

就像你在新闻或电子巴士标志上看到图表一样,你想知道'他们是如何获得这些数据的?他们是用原始sql做的还是使用LINQ?(或在这里插入你自己的共同极客好奇心).

您需要开始这样做,但需要各种视觉元素.

但就像学习一门新语言一样,如果你没有真正投入其中,你就不会学习它.

取自我写的另一个答案:

学习看看,真实的样子,看看周围的世界.为什么我喜欢这个用户界面而又讨厌这个用户界面?为什么在这家餐厅菜单中找到面条很难?哇,在我读完这些文字之前,我知道那个标志的含义.那是为什么?为什么书封面看起来如此错误?学会花时间思考为什么你对各种视觉元素做出反应,然后将其应用到你的工作中.



18> exoboy..:

无论你做到了(上面都有一些重点),一旦我接受了它就没有那么直接......

我可以听到在地平线上轰轰烈烈的争论......所以让我解释一下.

直觉:根据无意识的方法或感觉使用一个人认为正确或真实的东西.

如果(正如卡尔·萨根所假设的那样)你接受你无法理解的东西绝对不同于你曾经遇到的任何东西那么如果你从来没有像我这样远程使用任何东西,你怎么可能"知道"如何使用某些东西呢?

想一想:孩子们试图打开门不是因为他们"知道"门把手是如何工作的,而是因为他们已经看到别人这样做了......他们经常把旋钮转向错误的方向,或者拉得太快.他们必须了解门把手是如何工作的.然后,这些知识应用于不同但相似的情况:打开窗户,打开抽屉,打开几乎任何大的东西,带有一个大的旋钮式手柄.

即使对我们来说看起来很直观的简单事物对于来自其他文化的人来说也不会是直观的.如果有人在他们面前伸出手臂,并且在保持手臂静止的同时将手放在手腕上放下......他们会把你放弃吗?可能,除非你在日本.在那里,这个手势可能意味着"来到这里".那么谁是对的?当然,两者都在他们自己的背景下.但如果你去两地旅行,你需要知道两个...... UI设计.

我试图找到对我的项目的潜在用户已经"熟悉"的东西,然后围绕它们构建UI:以用户为中心的设计.

看看Apple的iPhone吧.即使你讨厌它,你也必须尊重它的思想.它完美吗?当然不是.随着时间的推移,对象的感知"直觉性"可以增长甚至完全消失.

例如.大多数人都知道,沿着顶部和底部有两排孔的黑色条纹看起来就像是一个电影胶片......或者它们呢?

问你的平均9或10岁他们认为是什么.您可能会感到惊讶的是,现在有多少孩子很难将其识别为电影胶片,即使它仍然用于代表好莱坞,或任何电影(电影)相关的东西.过去20年的大多数电影都是数码拍摄的.我们最后一次拍摄任何类型的电影,照片或电影是什么时候?

所以,对我而言,最重要的是:了解您的受众并不断进行研究,以跟上"直观"事物的趋势和变化,针对您的主要用户,并尽量不做那些惩罚缺乏经验的人高级用户或减慢高级用户以便手持新手.

最终,每个程序都需要对用户进行一定程度的培训才能使用它.需要进行多少培训以及哪个级别的用户是决策的一部分.

根据您的目标用户过去作为人类,计算机用户,学生或其他任何人的经验水平,某些事情或多或少都是熟悉的.

我只是为钟形曲线中最胖的部分拍摄,尽量让尽可能多的人,但我意识到我永远不会让每个人都满意....

推荐阅读
mobiledu2402852357
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有