那些年苹果做错的设计案例,苹果现在谁在设计

那些年苹果做错的设计案例,苹果现在谁在设计

  • Post author:
  • Reading time:2 mins read
  • Post category:品牌设计
  • Post last modified:2022年9月13日

  iOS从07年第一代iPhone发布时的iPhone OS,已发展到今天的iOS10,这些年来,iOS从最初的一个简单、粗糙的ROM,发展成现在手机ROM中体验标杆的操作系统。设计风格走过了拟物化,扁平化,今年已发布的iOS10,设计风格也开始偏向卡片式风格,随着新的交互方式3D Touch的加入,开始脱离单调的扁平化设计,卡片式风格让设计语言更加符合用户的操作认知(卡片式的内容,对人有更强的按压操作暗示)。 iOS10锁屏Widget界面

  手机友商的跟进

  苹果的设计,给大家的印象,总能精准的发现用户的痛点,在合适的场景下,创造眼前一亮的设计。如手机屏幕下滑出现快速搜索(Spotlight Search),屏幕下边缘上滑出现控制中心,这些设计创新,都能引起行业内的友商迅速跟进。 Vivo的控制中心的设计思路与iOS几乎一致,操作方式都是从屏幕下边缘上滑出现控制中心。 上图从左至右,依次为iOS10、MIUI、华为EMUI系统设置界面。很多手机ROM的系统设置,都沿用了苹果的一套设计模式,将系统设置项,用列表分组展示,同时将不常用设置项,收纳在二级界面中,如左图,iOS将更多设置收纳在【通用】中,小米则为【其他高级设置】,EMUI则为【高级设置】。

  交互细节亮点

  苹果在交互细节上,也能深刻洞察用户使用场景中的操作习惯,抓住用户的需求和痛点,针对用户该使用场景下,可能的行为,去做针对性的设计。夸张一点说,将体验做到了极致。接下来介绍几个,我个人认为iOS上,做的比较出色的交互细节。 1.空信息时,点击信息图标,直接进入【新建信息】页面。 用户在信息中的主要操作任务是查看历史信息、回复信息和新建信息。而如果信息中,没有历史信息时,那用户此时进入,只有一个操作任务新建信息,直接进入新建信息页面,符合用户当前使用场景的下一步操作意图。基于用户的使用场景,预判用户的下一步操作。 2.信息等页面搜索框默认隐藏,下滑屏幕出现,而联系人列表界面的搜索框置顶,固定在列表顶部。 搜索框在iOS的自带应用中,一般是默认隐藏,当用户在页面顶部下滑时,出现搜索框,基于用户的这种操作场景,预判可能想进行搜索,适时的出现搜索控件。 而在通讯录联系人列表上,搜索框则默认出现且置顶。按照交互的一致性原则来看,其实是不应该这么设计的,但考虑到联系人列表,查找联系人这一行为的使用频率非常高,且很多人进入通讯录,第一任务就是通过搜索框查找联系人,有必要将搜索框置顶显示在联系人列表上方。 3.iOS7以后的多任务界面,会自动将用户使用的上一个应用默认为当前界面主要窗口,方便用户快速的返回上一个应用。 iOS7以后的多任务界面,自动将上一个应用默认为多任务界面的主要窗口,一般用户使用多任务的场景,主要是在当前应用和上一个应用之间切换,将上一个应用突出,作为视觉焦点,符合绝大部分用户使用多任务的场景。iOS的设计中,会着重深挖用户的下一步操作,而不是死板的呈现交互默认值。 反观iOS7之前的多任务界面,用同样的视觉重心,呈现最近四个打开的程序,缺少对用户下一步操作的引导。

  那些年苹果做错的设计

  进入正题,到了本文要讲的重点。 苹果也不是神,它也有做错过很多设计,下面介绍一些iOS在版本更新迭代中,个人认为做错的一些设计方案。以下内容,是基于现在的角度来看(设计不是孤立存在的,或许在过去的使用场景下,是合适的,但不适合现在),可能存在争议,仅代表个人观点,大家如果有不同意见,欢迎讨论。 1.iOS8多任务界面顶部出现让人费解的最近拨打联系人。 iOS8在多任务界面上方,增加了最近联系人。希望用户无需进入拨号应用,通过双击Home键,调出多任务界面,即可快速的跟最近联系人进行拨打电话或发送信息。 这个设计方案,在iOS9更新时,已经去掉了。失败的原因,主要是没有考虑用户拨打电话的场景,而是生硬的将拨打电话与多任务,两个毫不相关的场景结合在一起,与用户长久以来,养成拨打电话的习惯用法相违背。用户无论什么时候拨打电话,都很难想到先双击Home键,打开多任务,再在此查找最近拨打的联系人。而且此种做法,也可能暴漏用户的隐私。如果你的设计,需要解决的是已存在的用户需求的话,不要挑战用户的习惯用法。 2.iOS7和8的通知中心,按照接收时间先后倒序排列的前提下,再按照应用归类通知,大大降低了用户处理通知的效率。 iOS10及9的通知中心,将以前复杂的通知分类方式(按照接收时间先后倒序排列的前提下,再按照应用归类通知),改为了按照时间整体排列整合,处理通知的效率提高了很多。我想大家在使用iOS9之前,应该都体会到这种痛苦,清除通知中心的通知,点击屏幕右侧的叉叉,点的手都酸了的经历,大大降低了用户清除通知的效率。 现在大家都处于一个信息爆炸的时代,手机里面装了众多的APP,每天会收到无数的骚扰通知,无效通知的数量远远大于有用的通知,大部分通知,用户其实扫一眼,然后删掉即可。通知中心最急切的痛点,就是如何快速处理垃圾通知,目前,苹果将其改为了按照时间整体排列整合,已有效改善处理的效率。 但其实还不够,用户没法方便的屏蔽通知,这也是用户的一个痛点。应该允许用户在通知中心中,可以屏蔽,不再接收某一应用发来的通知(设置项中有通知设置入口,但操作并不方便)。不要告诉我,第一次打开该APP时,有弹出是否允许接收通知的弹窗,我想说,我还没使用该APP,我怎么确定我喜不喜欢它。 (以上截图源自 知乎) 网上搜了下,对iOS清除通知的方式吐槽的人蛮多的。 3. iOS10将锁屏界面调出相机方式改为向左滑动屏幕调出,此操作麻烦,效率低,尤其在有消息通知的场景下,更加难以在锁屏界面调出相机。 iOS10将iOS9在锁屏界面调出相机的交互方式,由触摸相机图标向上滑动改为左滑屏幕调出,有几点明显的体验问题: 1.操作前没有暗示,用户无法直观预知锁屏界面相机调出方式,需要有很高的学习成本,去学习这个操作,才能了解如何使用; 2.左滑操作太难触发,触发区域也不明确,而且在有消息通知的场景下,触发区域又不一致,用户在此场景下,非常容易触发滑动通知误操作,大大降低了锁屏界面调出相机的效率。 大家在使用装有iOS10的iPhone在外旅游时,碰到想抓拍的场景,着急之下,估计会很容易出现滑不出相机的情况。 4.iOS9相机界面将界面下方易操作区域留给滤镜功能,却不是使用频率更高的的前后置摄像头切换。 iOS10相机界面,将之前相机界面的滤镜和前后置摄像头的位置做了对调。设计的改动原因,显而易见,将使用频率高的功能放置在更显眼,且用户更容易操作的区域。 将更常用的前后置摄像头切换功能放置在用户拍照界面下方,因为在手持相机拍照时,无论是竖持,还是横持手机,屏幕下方的区域都是用户更方便点击到的位置。而根据我们拍照的习惯,尤其爱美的MM,前后置摄像头切换图标点击的频率,是远远高于滤镜图标的点击。况且现在第三方滤镜APP,如Instagram,做的滤镜种类远远丰富过iOS自带相机。不过,也不能就此断定,iOS的相机设计师,以前没有考虑到这个细节,有可能之前有商业角度的考虑,想推广自带相机的滤镜功能。 5.iOS7测试版的锁屏界面,出现同样的两个操作指引箭头,以及模糊不清的解锁文案说明。 很多人可能没见过上左图的解屏界面,它只在iOS7的前几个测试版出现过,不久后,就改正了。记得那会刷iOS7测试版时,刷好后,点亮屏幕的瞬间,被这个解锁界面吓到了,让我顿时变成了一个智能手机小白,不知该如何操作,根据我有限的认知,结合解锁界面的说明文案和指引箭头,从屏幕下方往上滑了那么一下,结果操作错误,后来发现是向右滑动解锁。根据解锁界面的提示文案,和紧挨着文案的向上箭头,用户很容易将两者结合起来理解,记得那会很多人,跟我一样以为向上滑动解锁。估计iOS7的设计变化太大,苹果的设计师那会忙不过来,草率的出了这么一个存在令人误解的解锁界面扁平化设计方案。还好,没过多久,在正式版之前,就及时调整了。 上左图解锁界面,除了上面提到的解锁方式指引问题以外,还存在主要操作任务不清晰的问题。该界面同时存在两个箭头,一个向上,一个向下,从视觉重心来看,它俩给用户的暗示程度是一样的,按照一个界面一个主要任务的设计原则,让用户如何理解,在解锁界面,应该上滑呢,还是下滑,最要命的是,无论上滑出现控制中心,下滑出现通知中心,都不是该界面的主要任务,该界面的主要任务应该是解锁手机。而按照这个解锁设计方案来看,用户会被误导上滑解锁,或下滑解锁,完全想不到右滑解锁。 新的解锁方案,在解锁提示文字上左侧增加了一个向右的箭头,同时文字上,增加了向右扫光的动画,暗示用户向右滑动解锁。界面上下箭头也改为了短平线,减弱用户的注意力,让用户聚焦到该界面主要任务,向右滑动解锁。 6.iOS7之前的锁屏界面,快速查看通知操作隐晦,引导性差。 关于交互,有几点基本的原则: 操作前可以预知 操作中有反馈 操作后可撤销 左图,从界面操作前可预知角度来看,只有右滑解锁的操作指引暗示,并没有右滑通知,快速解锁并进入该通知应用的操作暗示,界面的可用性有些差,用户并不能知道如何快速查看通知,而用户手机收到通知后,快速查看通知恰恰是用户要做的主要操作。我记得那会,还是同事告诉我:“你在通知上右滑看看,可以解锁并查看通知”。相信很多人那会应该跟我一样,不知道锁屏界面还可以这么操作。 右图的解锁界面,在最近一条通知附近,有【滑动来查看】的文字提示,暗示在通知上滑动进行查看。不存在iOS6之前锁屏界面无法获知【右滑通知快速解锁并查看】的可用性问题。 7.iOS7之前的多任务切换,视觉焦点不够突出,用户的主要操作是切换最近程序,而将屏幕大部分空间浪费在显示对当前操作无用的桌面。 多任务界面有且都只有一个任务:切换最近使用的程序。但iOS6的多任务界面,只利用了屏幕下方不到1/4的区域,用于切换最近程序,既然用户的主要操作就只有左右滑动切换最近程序,为什么不能全屏操作,要委屈用户的手指在下方那一点区域操作,且点击想打开的程序,还得非常精准的小心翼翼的点,才能点中。而iOS7的多任务界面,就直观清晰很多了,直接将用户最近使用的程序界面图和程序iCON平铺在桌面上,操作焦点明确。 iOS7的多任务界面,程序缩略图显示最近的三个程序,而程序ICON显示五个,设计意图是为了方便用户更快速地切换最近的其他程序,但会给用户造成使用上的困惑,根据iOS9和10的多任务界面改动来看,苹果应该是参考了用户使用数据,很少人会去切换最近的第三或四个程序。 iOS6的多任务界面信息呈现还存在一个问题:没有主次之分。所有信息都用同样的视觉强度呈现,但并不是所有信息对于用户来说都是同等重要的,比如说,用户最常使用的场景是:在最近两个程序间来回切换。 8.iOS9及之前的通话记录中,如果联系人有多个号码,该通话记录的拨打号码不清晰。 iOS9之前的通话记录中,用蓝色标注该通话记录的拨打号码,如果通话记录对应的联系人,存在多个号码的话,该通话记录对应的拨打号码,并不能直观的看出是哪个号码。 iOS10在通话记录对应的拨打号码上增加了一个【最近】的识别标签,则清晰很多,用户可以直观的看出哪个号码是我该回拨的号码。 9.iOS7的控制中心界面更像没经过设计的交互稿,不同功能区域划分并不清晰,明确。 信息的分组方式,根据格式塔理论,常规处理为间距、分割线、背景色来区分不同的信息,对比iOS7的控制中心,有没有觉得iOS7的控制中心界面,很像没经过设计的交互稿,在功能多区域小的场景下,iOS7控制中心仅仅通过分割线来区分不同的功能区域,显得界面过于凌乱,且用户可操作的区域也不明确。而iOS9和iOS10通过不同的背景色区分不同功能区,信息的呈现更加清晰。 10.iOS的分享菜单中,下面一栏功能,给人的感觉是不可点击状态。 分享界面下面一排功能图标与上面一排应用图标的视觉差异,传递给人的感受,下面一排功能图标状态更像是不可点击状态,让人感觉功能不可用。 11.邮件详情界面,iOS10用左右箭头映射上一封下一封,不如iOS9用上下箭头映射上一封下一封邮件自然直观,更容易让用户理解。 iOS邮件列表,新的邮件在列表上方,较旧的邮件在新的邮件下方。 iOS10的邮件详情中,用左右箭头表示下上封邮件。向左的箭头给用户的暗示是返回,可以理解为返回时间较早的一封邮件,即列表下一封邮件。向右的箭头表示前进,理解为去查看较新的一封邮件,即列表上一封邮件。左侧箭头—>上一封旧邮件,右侧箭头—>下一封新邮件,但此种对应,与邮件列表中,新邮件在上,旧邮件在下,是一个很糟糕的映射关系,增加了用户的认知负担,用户很难理解,为何点击左侧箭头,会跑到了列表下一封邮件。 举一个【设计心理学】中,关于映射的例子。 燃气灶控件的糟糕映射 最左边的旋转控制的是左前燃气头还是左后燃气头?用户每次使用燃气灶时,都得弄清楚映射关系。 燃气灶控件的清晰映射 上图旋钮和燃气头的映射关系非常清晰,因为旋钮的空间布局已将旋钮与燃气头清晰地联系起来。 iOS9的邮件详情,用上下箭头控制上一封,下一封邮件就好理解多了。点击向上箭头,去到该邮件列表上一封邮件,点击向下箭头,去到该邮件列表下一封邮件。上下箭头点击后的去处,更符合“自然映射”,与邮件列表中的邮件顺序映射关系比左右箭头容易理解多了。 有一个正面的案例 Google在通知详情中,通过上下箭头指示去到上一封通知,或下一封通知。 12.iOS9删除应用确认对话框,将【删除】Button放在并不合理的位置,初衷是好,但设计过度。 iOS10将删除应用的确认对话框中,【删除】Button的位置从左侧移至了右侧,同时从蓝色加粗,变更为了红色加粗,增强了删除操作的视觉提示。 iOS对话框操作按钮的一般原则是:主要操作在右,取消操作在左。而删除应用的确认对话框,一直以来都是逆向设计,将【删除】置于左边,【取消】在右边。现在这个改动,证明他们之前的逆向设计是有问题的。本身用户进行删除操作,已经有非常高的门槛,长按图标,图标抖动后,需要精准的点击删除叉号(而且删除还放置在不那么好点的左上角),才能出现确认删除对话框,这一系列操作足以保证用户不是误操作了,没有必要再为了防止用户误操作,而设计删除障碍。

  总结

  设计不是艺术,它不是孤立存在的,更不是设计师的自娱自乐。设计永远和人、使用场景、用户需求相关联。iOS会不断的去更新迭代它的设计,除了有商业目的上的考虑外,更多的是根据时代(人、环境、需求)的变化而变化,去做符合当下的设计。

那些年苹果做错的设计案例,苹果现在谁在设计

你对ui的理解,你对ui的理解

  想象3个用户界面(UI)一起去了酒吧。第1个点了一杯酒,然后又再点了几杯。几小时后,它买了单,醉醺醺的走了。第2个界面点了一杯酒,直接把钱付了,然后又点了一杯酒,又马上买了单,几小时后也醉醺醺的离开了酒吧。第3个界面刚走进酒吧,马上就已经醉醺醺的离开了——它知道酒吧是干什么的,它非常讲求效率,一点时间也不浪费。你听说过这第3种界面吗?它就叫做“乐观派UI”。 乐观派UI设计并非乐观地看待页面——至少不仅限于此。(查看大图) 我最近参加了许多关于前端开发和用户体验的会议,讨论了心理表现最佳化,我很惊讶,乐观派UI设计是业界一个如此微不足道的话题。坦白说,这个术语本身都没有清晰的定义。本文中,我们来探讨它的基本概念,寻找一些案例,并回顾它的心理学背景。然后,我们讨论掌握这项用户体验技巧的关键。 开始之前,我得说,没有任何一个单独的界面能被称作“乐观派UI”。其实它是界面实现背后的心智模型。乐观派UI设计有它自己的历史和逻辑。

  很久以前

  很久以前——那时候“tweet”一词还只有鸟鸣的意思、苹果公司濒临破产、人们还会把传真号码印在名片上——网页界面相当单调。其中绝大多数没有一丝一毫的乐观意味。比如一个按钮的交互,可以遵循下面类似剧本来进行:

  用户点击一个按钮。

  按触发进入禁用状态。

  一条请求发送到服务器。

  服务器返回信息到页面。

  页面刷新,反映出返回的状态。

  那个年代,界面与乐观派扯不上什么关系。(查看大图) 站在2016年回顾这些,我们会觉得效率低下;但是相当惊人的是,同样的剧本仍然在许多网页和应用中上演,它仍然是许多产品的交互流程。原因在于它可以预测,而且或多或少总会出点错误:用户知道这项操作已经请求了服务器(禁用状态的按钮表明了这一点),当服务器有响应,更新后的页面清晰表明这种客户端——服务器——客户端的交互结果。这种交互方式的问题很明显:

  用户必须等待。如今我们都知道,即使是最短的服务器响应延迟,也会对整个品牌,而非这个单独页面产生负面的用户感知。

  每一次用户的操作得到响应,都会以一种相当破坏性方式呈现(整页刷新,而不是更新现有部分),会打断用户的任务流程,可能影响他们的思维轨迹。 我们甚至还没说到多任务,心理环境的任何变化都令人不愉快。那么,如果某个操作本意不是改变环境(在线支付就是个需要改变环境的好例子),那么这种改变会在用户与系统的交流中创造不友善的氛围。

  不久以前

  然后,所谓Web 2.0出现了,提供了新的页面交互模式。它的核心是XMLHttpRequest和AJAX。一种最简单的进度条形式:“菊花”,补足了这些新交互模式,它的基本目的就是告诉用户,系统正忙着处理事情。现在,服务器返回信息后,我们不必刷新页面了;我们只需要对已经渲染的页面进行局部更新。这使得网站更加动态化,为用户创造了更加顺畅和亲切的体验。一个按钮的典型交互如今是这样的:

  用户点击按钮。

  按钮触发变为禁用状态,按钮上显示出某种菊花图形,表明系统正在运转。

  请求发送到服务器。

  服务器返回信息到页面。

  根据返回的状态更新按钮和页面的视觉状态。

  这种新的交互模型解决了旧交互方式存在的一个问题:页面的刷新不会导致破坏性操作,保持用户所处环境不变。相比之前,这种交互亲切多了。 XMLHttpRequest和菊花解决了旧交互方式的一个问题:服务器响应会导致破坏性的刷新,改变整个环境。(查看大图) 这种交互模式已经广泛应用于数字媒介。但还有一个问题:用户仍然需要等待服务器反馈。当然,我们有办法加快服务器响应速度,但无论我们如何努力优化基础设备,用户仍然要等待。比如,研究表明78%的用户对于缓慢或不稳定的网站产生负面情绪。更有甚者,Harris Interactive为Tealeaf做的一份调查显示,23%的用户承认咒骂过自己的手机,11%冲自己手机大喊过,而且4%的用户在网络出问题时扔过手机。延迟就属于这类问题之一。 大约78%的用户面对缓慢或不稳定的网站时,会产生负面情绪。(查看大图) 即使在用户等待时展示某种进度条,如今也于事无补,除非进度条非常有创意。多数情况下,人们已经习惯性把菊花进度条当作系统缓慢的表现。菊花如今已经是一种纯粹的被动等待,用户毫无选择,要么等待服务器响应,要么关闭标签页或整个应用。那么,我们再进一步,改善这种交互;我们来看看乐观派UI的概念。

  乐观派UI

  正如前文所说,乐观派UI仅仅是处理人机交互的一种方式。要理解它背后的核心观念,我们还是要回到“用户点击按钮”这个场景。不过它的原则用在任何乐观派交互上都一样。牛津英文词典的解释如下:

  乐观主义,形容词,对于未来充满希望和信心。

  我们从“对未来充满信心”这部分说起。 想一想:用户操作引发服务器错误的频率高么?比如说,用户点击按钮时,你的API经常出错吗?或者用户点击某个链接时经常会出错?说实话我觉得不会。当然,API、服务器载荷、错误处理等级不同,表现也不一样。还有一些其他因素,作为前端开发或者用户体验专家,你可能不会考虑。但只要API稳定可靠,前端以适当方式反馈正确的UI操作,那么由用户触发导致的问题会特别少。以目前状况来看,我敢说不会超过1%到3%。这就意味着97%到99%的状况下,用户点击网站的某个按钮,服务器的响应应该是成功的,没有错误。应该从一个更好的角度来看待这个问题。 乐观派UI基于一个假设,用户点击按钮,服务器在97%到99%以上的状况下返回成功。(查看大图) 仔细想一想:如果97%到99%以上肯定是成功的响应,我们对于反馈就有充足信心——嗯,至少比薛定谔的猫有信心多了。我们就可以写出一个全新的按钮交互剧本:

  用户点击按钮。

  按钮的视觉状态立刻变为成功。

  就是这样!至少从用户的角度来看,仅此而已——不用等待,不用盯着禁用状态的按钮,也没有烦人的菊花转。交互流畅无缝,系统不会粗暴地现身,提醒用户注意它的存在。 乐观派UI交互里根本没有禁用状态按钮和菊花。(查看大图) 从开发者的角度来看,完整的流程是这样的:

  用户点击按钮。

  按钮的视觉状态立刻变为成功。

  请求发送到服务器。

  服务器响应发回页面。

  在97%到99%的状况下,我们知道响应会成功,所以不用再给用户添麻烦。

  系统只会在请求错误的情况下现身。暂时不用担心这块——我们会在后文中讲到。

  我们来看一些乐观派交互的案例。你可能很熟悉“点赞”按钮,Facebook和Twitter上就有。我们来看看Twitter的。 很明显,从点击按钮开始。但是请注意用户松开并移开鼠标时按钮的状态。它立刻变成了成功状态! 点了赞之后,Twitter立刻把它更新为成功状态。 此时,我们用浏览器开发人员工具,看看里面的“网络”标签栏发生了什么。 按钮的视觉状态改变,独立于服务器请求存在,此时服务器请求正在进行中。(查看大图) “网络”标签表明,服务器请求已经发送,但正在处理中。“赞”计数器还没有增加,但由于颜色变了,界面上已经清晰表明了点赞成功,甚至服务器都还没有给出反馈。 服务器返回成功的响应后,计数器增加,但这个变化比色彩改变微弱得多。这就给用户提供了一种流畅连贯的体验,感觉不到任何等待。 尽管赞按钮在视觉上已经变为成功状态,计数器只在服务器响应确认成功后才变化。 在Facebook可以看到另一个乐观派交互的例子,也是点赞按钮。场景非常相似,不过Facebook是连着计数器一起直接变为了成功状态,完全没有等待服务器响应。 Facebook用了和Twitter一样乐观派交互,但它连着计数器一起更新了视觉状态。 但有一点要注意。如果我们观察服务器响应时间,会发现它大约在1秒多。考虑到RAIL模型建议采用100毫秒作为简单交互的最佳响应时间,相比之下1秒显得太长了。但是,用户感知不到任何等待,因为这种交互天然的乐观属性。非常棒!这是心理表现最佳化的又一个例子。 但我们要面对现实:仍然有1%3%的可能服务器会返回错误。或者有可能用户断线了。又或者一种更有可能的情况,服务器在技术上返回了成功状态响应,但是这个响应仍然需要客户端进一步处理。因此,用户看到的不是失败提示,但我们也不能认为响应是成功状态。要了解如何处理这种状况,我们首先要了解乐观派UI在心理学上为何能起作用。

  乐观派UI背后的心理学

  目前为止,我还没有听谁抱怨过主流社交媒体上的乐观派交互,就是我们之前提到的那种。那么,我们可以说这些例子已经证明,乐观派UI是有用的。但为什么它们有用?这仅仅是因为人们讨厌等待。仅此而已啊,亲!你可以直接跳到下个章节了。 不过如果你继续往下读,说明你对深层原因感兴趣。那么,我们稍微深入一点,了解这种方式的心理学基础。 大脑研究帮助我们理解乐观派UI起作用的心理学成因。(查看大图) 乐观派UI有两个值得心理学分析的要素:

  用户行为的快速响应;

  服务器对于潜在错误的处理,无论是网络还是其他方面。

  用户行为的快速响应

  我们谈论乐观派UI设计时,我们谈的其实是人机交互中的最佳响应时间。早在1968年,这类交互就有了相关建议。当时,Robert B. Miller发表了他的开创性研究“人机对话的响应时间”(PDF),他在其中定义了不同类型的响应,用户可能从计算机得到的反馈多达17种。Miller将其中一种称为“控件操作响应”——按下按钮到得到视觉反馈的时间。甚至早在1968年,就规定了它不应该超过0.10.2秒。是的,这并不是RAIL模式首创——这个建议大约已经存在了50年。但是,Miller注明了,对于熟练的用户而言,这么短的延迟都可能太慢了。这就意味着,理想情况下,用户应当在100毫秒内获得操作的反馈。这就接近人体最快的潜意识动作——眨眼。因此,100毫秒的间隔给人感觉通常就是瞬间。“多数人每分钟眨眼大约15次,一次眨眼平均持续100到150毫秒”,伦敦城市学院神经学创立者Davina Bristow说,他还补充说:“这意味着我们每年有9天花在眨眼睛上。” 正由于瞬间的视觉响应(甚至在实际请求完成之前),乐观派UI在心理表现最佳化中,是一种已经完善的技巧。但事实上,那些人们喜爱的能在眨眼间响应的界面,对我们而言应该不算惊喜,真不算。而且这也不难做到。即使在很早以前,我们在用户点击按钮后,会将它变为禁用状态,这通常就足以表明用户的输入了。只不过,界面中的禁用状态意味着被动等待:用户什么也做不了,无法掌控整个过程。这对用户而言很令人扫兴。这就是为什么我们在乐观派UI中直接跳过了禁用状态——我们不让用户等待,直接给他积极的反馈。

  处理潜在错误

  现在我们进入乐观派UI设计中的第二个有趣的心理学问题——处理潜在错误。一般来说,有大量信息和文章讲述如何以最恰当的方式处理UI错误。但是,本文中讨论的错误处理,在乐观派UI中,最重要的不是如何处理错误,而是什么时候处理。 人们天生会把行为聚类处理,以主观定义的目标或者小目标达成为结束。有时候我们把这些聚类称作“思维轨迹”、“思维涌动” (PDF),或者就简单称作“心流”。心流状态的特征包括乐趣达到巅峰、精力集中、创造力爆发。在心流状态中,用户完全被这项活动吸引。Tammy Everts的一条推特准确描绘了这点: 【图注:我喜欢心流状态的一切,除了一点,我会连续几个小时忘记眨眼。我的眼睛现在是这样的。】 有时候,辨认出一个人是否处于心流状态非常简单。(查看大图) 在网络中,这些活动聚类的持续时间短得多。我们回顾一下Robert B. Miller的作品。他指出,响应类型包括:

  粗略浏览列表信息的响应;

  仔细浏览图表信息的响应;

  “系统,你明白我要什么吗?”的响应。

  他把这几类都归为2秒延迟的类型,用户会获得相应类型的响应。如果不继续深究,我们应该注意,这些延迟也取决于一个人的记忆运转(这是指一个人记住一定量信息所需的时间,更重要的是,不仅记住,还要能运用)。我们作为开发者和用户体验专家,这意味着在操作了某个元素的2秒内,用户会短暂进入心流状态,专注于他们期待的响应。如果服务器在这个时间内返回错误状态,用户仍然处于与界面的“对话”中,这是个比喻。类似于两个人对话,比如你说了一句话,对方委婉地反驳你。想像一下,如果对方花了很长时间点头表示同意(等同于我们UI中的成功状态),但然后最终对你说“不”。这多尴尬啊?所以,乐观派UI必须在心流状态的2秒内传达出错误信息。 乐观派UI必须清楚表达错误状态给用户。最重要的是,它要在用户进入心流状态的2秒内发生。(查看大图) 现在我们掌握了这项心理原则,用来处理乐观派UI中的错误,下面我们就开始面对那1%3%的失败请求吧。

  乐观派UI的悲观一面

  目前为止,我听到最多的言辞,是说乐观派UI是一种黑魔法——作弊,如果你这么想也对。也就是说,运用这种方式,我们就是在对用户撒谎,编造他们操作的结果。从法律上说,每个法庭可能都会认同这一点。但我仍然把这种技巧当作一种预期或是希望。(记得“乐观”的定义吗?我们在这里允许某些“希望”存在。)“撒谎”与“预期”的区别在于你如何对待那1%3%的失败请求。我们来看看Twitter的乐观派“点赞”按钮在离线状态下的表现。 首先,点击按钮后它立刻变为成功状态,这符合乐观派UI模式——当用户松开并移开鼠标,它的表现和用户处于在线状态时一样。 离线状态下,Twitter的点赞按钮仍然在点击后产生视觉变化。(查看大图) 但由于用户离线,请求失败了。 (查看大图) 那么,在用户进入心流状态后,错误信息要尽快给出。2秒通常是心流的持续时间。Twitter以一种非常微妙的方式表达这一点,把按钮的状态还原回去了。 请求失败后,Twitter以一种低调的方式还原了按钮的视觉状态,没有在视觉上小题大做。(查看大图) 认真的读者会说,失败处理还能更进一步,准确告知用户请求没有发送出去,由于发生了某个错误。这就让系统尽可能保持隐形。但还有一系列问题:

  屏幕上忽然出现的任何形式的通知,会改变用户的环境,刺激他们去分析失败背后的原因,但这个原因在错误信息中可能已经说明了。

  就像所有错误信息或通知一样,它应该也要引导用户进入新的环境,提供相应的操作信息。

  操作信息又会进入一个新的环境。

  好吧,可能大家都觉得这开始有点复杂了。因为这样的错误处理对于网站的大型表单有意义,但对于像点击按钮这么简单的事情,它就杀鸡用牛刀了——对于所需的技术开发,还有用户的记忆运转,都太过了。 所以,没错,我们对乐观派UI中的失败要有开放心态。我们要尽快告知用户,保证乐观主义不会发展成谎言。但它应当与环境相称。对于点赞失败,还原按钮状态这样的微小提示足够了——也就是说,除非用户点击的是其他极其重要的状态,需要保证它时刻运转正常。

  极端悲观

  这就产生了另一个问题:如果用户获得成功的反馈,但是在服务器响应之前就关闭了浏览器标签页,怎么办?最讨厌的情况是,用户在请求发送到服务器之前就关闭了标签页。但除非用户极其敏捷,或者有本事减慢时间,这种情况很难发生。 如果乐观派UI运用得当,所有对于各元素的操作都在2秒内得到服务器反馈,那么用户就得在2秒内关闭浏览器标签页。这对于快捷键而言并不难;但是我们知道,97%99%情况下,请求是成功的,无论标签页是否激活(只是响应没有发送回客户端而已)。 所以,只有对于那1%3%的服务器错误,这才算一个问题。然后,有多少人在2秒内匆匆关闭页面?除非他们在比赛关闭标签页,我觉得这个数量没有什么意义。但如果你认为这个关系到特定的项目,可能会导致糟糕的后果,那就应该用一些工具来分析用户行为;如果这种场景存在的可能性足够高,就把乐观派交互限定在非重要元素上。 我有意没有提及那些故意延迟的请求;这些不在乐观派UI设计的范畴内。而且,我们在悲观方面讨论得已经够多了,现在我们来总结一下运用乐观派UI的核心要点。

  经验法则

  我真诚地希望,这篇文章能帮助你理解乐观派UI设计背后的核心观念。可能你很希望在下一个项目中运用这种方法。那么,开始前请牢记这些:

  我们所有这些讨论的前提:你所依靠的API足够稳定,能够返回可预期的结果。这点无需多言。

  界面要在向服务器发送请求之前,找出可能的错误和问题。最好能够完全去除可能会导致API返回错误的因素。UI元素越简单,越容易运用乐观派UI。

  在简单的是非选项上运用乐观派模式,只有成功与失败两种响应的元素。例如一个按钮的服务器返回状态包含“是”、“否”、“有可能”(每一种都代表了不同程度的成功),这种按钮就不适合用乐观派模式。

  了解API的响应时间。这点至关重要。如果你知道某个特定请求的响应时间一定在2秒以上,首先应该优化API到最佳性能。之前提到,服务器响应时间在2秒以内,乐观派UI才有最佳表现。超过2秒会导致难以预期的结果,用户会更加挫败。千万注意。

  乐观派UI不仅仅是点击按钮。这种方式可以运用于页面中的各种不同交互,包括页面的加载。例如框架页面就运用了相同的观念:你预期服务器能成功返回信息,所以直接向用户先展示占位符。

  (查看大图) 看得出来,乐观派UI设计并不是网页中的新奇事物,也不是什么先进技巧。这只是另一种方式,另一种心智模型,帮助你掌控产品的预期表现。乐观派UI设计基于人机交互的心理学基础,聪明地运用它,能够帮你的网站树立更好更流畅的体验,同时,需要做的其实很少。但是,为确保这种模式真正有效,避免产品向用户撒谎,我们必须理解乐观派UI设计的原理。

  资源

  “人机对话的响应时间” (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968

  “RAIL简介:以用户为中心的表现模型,” Paul Irish, Paul Lewis, Smashing Magazine, 2015

  “移动端网页的压力:网速对于情绪与品牌认知的影响,” Tammy Everts, Radware Blog, 2013

  心流在人类发展与教育中的应用, Mihaly Csikszentmihalyi, 2014

  “移动端设计细节:避免转菊花,” Luke Wroblewski, 2013

  “性能的重要性,第2部分:感知的掌控,” Denys Mishunov, Smashing Magazine, 2021


  今天关于那些年苹果做错的设计案例,苹果现在谁在设计的相关资讯就为大家介绍到这里,大家看完以后有没有什么收获呢,更多关于品牌宣传策划设计的相关资讯请关注匠心文化。

[版权声明]

文章内容来自互联网,如欲转载,请注明本文链接: https://www.ou-b.com/ppsj/gov_67830.html