避免愚蠢、粗鲁、破坏性和致命性的设计

“我们使用的各种系统(应用和设备)现在如此复杂,我们无法预测所有系统行为。”

尽管计算机正在越来越多地控制着世界,他们并不是总是变得更聪明,而是正变得越来越复杂。人类必须使计算机编码得越来越智能,但我们并不总是正确的。使用旧的、临时的计划、设计与分析方法没有多少帮助。

有时我们不知道人工智能系统正在工作的原因,这很可怕。但我们更应该担心的是我们使用的各种系统(应用和设备)现在如此复杂,我们无法预测所有系统行为。

分析错误

“设计糟糕的系统很容易变得愚蠢、粗鲁、危险,甚至致命。”

分析完成后,最常用的方法仍是用例。分析后你获得了一系列前置条件,然后基于他们决定系统的行为。而问题是:复杂的系统拥有无数的用例。

我曾参与过一个银行APP的项目,我们持续为用户提供更多的内容,将他们添加到我们需要写的用例中。我意识到系统复杂性问题,并在白板上很快创建了基础选项的矩阵。经过数学计算,我发现完整的用例分析需要花费3000亿年。

你正在创建的系统可能比那个更复杂,因此如果你想要翔实的分析,用例分析是不行性的。如错误影响分析(Failure Mode Effects Analysid(FMEA))等很多其他方法要么太笼统要么来源于机械时代。这些方法需要花费很长时间,现代软件开发项目需要的时间线不适合这些方法。航空器和桥梁设计必要的分析可能持续数年,而且即使进行了所有的分析,有时仍然会失败。

我也希望我有这个问题的简单解决方式,并能给你一个检查列表来解决它,可惜我没有。尽管与很多聪明的人在一起,我仍没有想出更好的分析系统。作为替代,我开始尝试铭记弹性设计原则并与每个人分享我的想法与学到的教训。

如果你想帮助防御潜在的天启(机器人灾难),请铭记糟糕的设计很容变得愚蠢、无理、危险甚至致命。现在让我们看看糟糕的系统设计的例子以及设计可以怎么更好的解决这些问题。

愚蠢的系统

“但当机器执行简单的事情失败了,或本认为非常智能的机器却表现出怪异、糟糕和不人道的行为时,人们会觉得烦人并不信任这些产品。”

每天我们都会遇到愚蠢、野蛮的系统和经历。当系统执行复杂的任务或者机器不是那么傻的时候,人们不怎么会抱怨。但当机器执行简单的事情失败了,或本认为非常智能的机器却表现出怪异、糟糕和不人道的行为时,人们会觉得烦人并不信任这些产品。

如何识别野蛮的设计呢?想想如果人类执行系统界面同样的行为有多怪异就知道了。如果一个接待员刚刚向你要了邮箱地址,然后再问一次会怎么样?如果你不打算购买牛仔裤,却在填完问卷前禁止离开会怎么样?

有一天,一位伦敦的女士发现麦当劳的售卖机允许客户移除汉堡的每一部分,因此按照要求试了一下。她移除了面包甚至肉,然后成功地购买一个麦当劳购物袋并获得了收据,这演示了这种系统设计的失败。

知道我是用户体验设计师的人常常跟我谈到产品建议的好坏。亚马逊是很好的案例。亚马逊在大部分事情上做的很好,但却让系统缺陷更加严重。

几年前,在反复研究之后我买了一个标签打印机。当然,我是在亚马逊上买的,因为他们什么都有。在我放入购物车后及之后的几个月里,亚马逊试图卖给我更多标签打印机。别忘了,我多么不可能想要两个或更多的标签打印机。这些机器有消耗品——一起使用的胶纸——而亚马逊正建议我购买其他品牌并使用别的种类胶纸的标签打印机,而不是尝试卖给我我已购买的标签打印机配套的便签纸。实际上我很想买各种胶纸,如不同颜色的和不同防水程度的,但是新用户很难找到匹配自己设备的标签纸。给点帮助会更好。

智能的系统

“你不能假定在没有测试的情况下旧系统工作的很好或和期望的一样。你需要观察你的系统是怎么工作的,然后确保基础数据实践依然适用并在所有情况下对所有用户工作良好。”

你可能知道亚马逊是怎么走到今天的。他们最初是一家书店。基础业务有时也会流失。书籍没有附件,但有时会是系列的一部分,因此读者显然需要同一系列的其他书籍,或他人喜欢的同一主题书籍。

旧系统并不是本来就不好,但是你不能假设在没有测试的情况下他们工作的很好或和期望的一样。你需要观察你的系统是怎么工作的,然后确保基础数据实践依然适用并在所有情况下对所有用户工作良好。

例如,在我花了很多时间写解析规则后,旧系统可以按照人们要求的方式展示所有限制,而不是鸣叫提醒了。但是有时我得让客户明白并重写数据库来支持现代方法、更好的索引以及完整的UTF-8格式,这样系统可以无缝支持多种语言。

现在亚马逊销售足够多不同类型的商品,他们应该构建通用系统并尝试清除各种问题,如所有引用标题而不是产品的情况。然后不仅可通过推荐用户可能需要的书籍和附件来更好的为他们服务,而且可以通过驱动更多销售的建议解决自己的组织需要,提高零售率,并使回头客满意。

麦当劳可以很容易地让顾客移除汉堡中的任意部分,但要有一个规则要求至少选择一个部分。这会增加一定的复杂性,但是可以阻止有人只预定番茄酱,同时提供一个更有用、合理的系统。考虑到人们需要食物这个事实,正规分析会发现这种问题只是简简单地思考了预定和配送的逻辑。

粗鲁的系统

“当公司以工程师的视角构建系统,把用户交互当作问题而不是系统的目标时,粗鲁的提示信息就会出现。”

现在每个人都知道错误信息多么无礼。当公司以工程师的视角构建系统,把用户交互当作问题而不是系统的目标时,粗鲁的提示信息就会出现。每天在我们使用应用和网站时都会碰到令人讨厌的错误信息。这些信息会因为输入手机号码没加连接符而对我们吼叫或坚持认为我们童年的宠物名太短。

但当系统执行了错误的行为或主动攻击我们,这些错误的行为有会怎样呢,

在2000年早期,早在Nest的自学恒温器出来之前,我在家里安装了一个联网的智能恒温器。它确实效果不错。直到有一天,我下楼时看到恒温器显示的不是温度而是LO。这是什么意思?我可以猜到他应该是(low)的意思,在类似的系统中,这是数值过低的缩写。

无论数值过高或过低,都超出了系统设计规定的或工具本身可测量的范围。但显然我家的温度并比热电偶的测量范围更冷啊,因此我还想问:LO到底什么意思?明显有东西出错了而且比错误信息更严重:事实上系统正在执行一些我没有要求它执行的功能。

在使用万用表做了一番检测并与厂商联系之后,我找出了原因。内部有东西坏了,所以恒温器获得不了温度读数。它把这种糟糕的信息视为非常非常冷。但是,它不是警告我,而是在大夏天中,自己更换了模式并以最大功率开始加热。

优雅的系统

“当电脑呆在后台时,通常表现良好。最有礼貌的技术解决方案通常是最自动、最精细及最安静的解决方案。”

智能恒温器的生产商认为这是一个电子元件问题,而不是设计错误。谁决定的恒温器要比人更智能?我要求的是制冷,为什么它自己更换到了制热模式?

现实生活中也会有这样的错误,如果碰到数据传感器显示虚假数据会怎样呢?恒温器应该意识到这种突然改变是不可能的,忽略掉这些坏数据并继续合理的执行工作,而不是因为极少超出测量范围而抓并执行灾难性的行为。

现在将避免错误这条原则扩展到我们如何获得激进的未来产品上,比如自动驾驶汽车。尽管有些汽车生产商比较张扬,其实很多新车都多少有一些自动驾驶能力。他们只是仅仅以个人安全特性出售的。想一下屏幕显示的倒车摄像机检测的障碍物距离的浮层。这是一种功能强大且无缝的增强现实形式,我们只是使用它而不是标记他。

在某些车里,自动维持车道功能表现出色。没有尖叫的警报。相反,车辆仅仅是为你服务的(精巧到你都察觉不到)并保持你持续行驶。

当电脑呆在后台时,通常表现良好。最有礼貌的技术解决方案通常是最自动、最精细及最安静的解决方案。

破坏性的系统

“糟糕的系统有时不仅仅是不方便了,而是将人们置于危险之中并通过破坏财产让人们或者他们的保险公司付出代价。”

我的恒温器错误仅仅是不方便,而糟糕的系统有时不仅仅是不方便了,而是将人们置于危险之中并通过破坏财产让人们或者他们的保险公司付出代价。

1996年,欧洲太空总署(ESA)发射了新型的阿里亚5号运载火箭。当然现在它已经不新了。它其实是之前火箭的进化版,但确实有重大飞跃,可以载重更多,飞的更高更快。所以当第一个火箭发射升空37秒后爆炸时,人们极其绝望。

调查结果发现爆炸的原因是:他们为系统很简单部分重用的一点旧代码没有进行适当的测试。这个更快的火箭超越了旧软件的速度上限。就像我的恒温器认为超限的寒冷是不好的并自动加热一样,相似的情况,火箭系统开启了自毁功能。

上个月,我开车通过伊利诺斯州中部荒无人烟地方的时候,我的汽车表现非常搞笑。我一直检查各种设备,并一时没有发现什么问题。然后突然油灯亮了,因此我减速,发信号并停在了路旁。然后车就启动不了了。

引擎因为一条吹油线自杀了,而且再也无法启动了。我把它捐给了附近的NPR电台(全国公共电台)。故障调查显示这辆车的燃油警告灯在8磅/平方英寸就触发了,而正常的运行压力超过38磅/平方英寸。只要低于正常压力2磅/平方英寸就会被认为是坏的。换句话说,设计警告灯就是为了告诉用户引擎报废了,你什么也做不了。

保护性的系统

“如果没人清楚地定义系统关于保护用户、用户行为以及他们财产的有用限制,你必须确保这件事有人做。”

将你的系统设计的更加智能,并在可用的时候使用有效数据,而不要进入错误模式。

阿里亚5陷入了亚马逊同样的陷阱,即假设旧系统会一直工作。即使如此,在设计代码时也不要将出界情况视为错误甚至是致命错误而应是异常情况,然后尽力将异常情况处理到最好。火箭发射非常失败,以致它强行覆盖了报告有效数据的好系统。

作为用户体验设计师,你的工作就是要保证所有情况(正常或异常)都要考虑人因元素。如果没人清楚地定义系统关于保护用户、用户的行为以及他们的财产的有用限制,你必须确保这件事有人做。

这种事常常是自然出现的。在设计系统如何展示低油警报部分的时候,你需要根据相关标准选择图标、颜色及位置。对于任何错误,无论是仪表盘上的信号灯亮了还是网站上弹出了警告浮层,我都会问:

  • 系统想表达的实际情况到底是什么?
  • 是否用户需要知道这个情况?
  • 用户可以做什么回应,解决这个问题?

我实际上设计过类似低油警告灯的系统,而且用户为中心的问答引导我们给出了更好的解决方式。当还有30秒或更少时间安全关闭系统时,最高优先级信息显示。增加时间检索信息并理解它的意思,然后确定20秒限制。“高速时,操作者可以将车听到路边并在20秒内关闭发动机吗?”可能不行,因此系统可能需要超过提前30秒提醒驾驶员。然而我们想要实现它,应该增加一个清晰的停止标签(需要翻译成当地语言)及一个图标,这是一只手在停止符号点击的图标而不是仅仅是一个通用警告图标。

设计只有使用他们才会有效和安全的执行控件。设计只有重要和相关才展示的数据和警告,并及时显示它们以便用户可以为问题作出反应。

致命的系统

“数字系统很少出现工程失败。…但是这些系统很容易出现人类编码错误。”

让你的车在路边抛锚是非常不方便的,甚至是危险的。但是确实有使人冒险的设计失误。

2015年,按比例缩小的维珍银河战舰2在飞行中解体了,杀了了一名测试飞行员并导致另一个人重伤。发生这些的原因仅仅是因为副飞行驾驶员在错误时间拉下了操纵杆。全国运输安全委员会(NTSB)调查发现,没有人在培训中、设计和功能控制中、飞行员操作程序中、人机工程学甚至在安全设备检查列表中注意人类因素。

这并不是机组成员在错误的时间拉下操纵杆的错,而是一种设计错误:要求很多严密计时的手动操作流程并允许飞行在飞行阶段中拉动操纵杆,这种行为本身就是很危险的。

2016年3月,一辆在丹佛国际机场各终点之间载客的自动穿梭列车突然从8公里/时加速到22公里/时,然后恢复平静停止了。这次突然运动的后果是许多乘客被甩到各处,4个人(包含一个孩子)被送进医院及27人轻伤。

数字系统很少出现工程失败。也没有某些偶然短路的情况。但是这些系统很容易出现人类编码错误。在检修环节有人只是为轨道单元输入了错误的速度,而列车只是服从了它的指令。

安全的系统

“要求用户按顺序执行很多离散任务会使玩家负载过多,这也是导致了各种错误。要求这些任务在执行特定的次数后才会出现更是加剧了这个问题。”

基础系统分析揭示了安全、适当操作的局限性。系统不是为了自身安全而存在的,而是为了满足用户的需求及实现人们的目标,或者实现一个公司的使命。举例来说,有些系统存在的意义是使救生设备可以使用。

太空船1号经历了许多人因和可用性失败,但两个最突出。首先,要求用户按顺序执行很多离散任务会使玩家负载过多,这也是导致了各种错误。要求这些任务在执行特定的次数后才会出现更是加剧了这个问题。这不止对驾驶舱设计,对整个系统设计都重要。请避免要求用户执行过多的任务,尝试聚合或自动执行某些任务。

即使假设太空船1号需要人工控制,风险分析应该包含对应的人类因素。缩尺复合体公司也许考虑了机械故障,但绝没有考虑过人也会犯错。既然需要拉下操纵杆时,指示灯和仪表盘能够提醒机组人员,因此系统也可以锁定操作,在保证使用安全的情况下激活。

丹佛国际机场(DIA)的区间列车用来载人。因此在所有的系统约束最顶端,它唯一真正需要执行的工作是:不会杀死或伤害乘客。即使在紧急情况下,自动列车也不应该能够自动加减到可以伤人的速度。

使用手册中可能有指南告诉维护人员不要使用这种设置,但是在应用中实施限制会更好。项目团队应该谨慎的增加速度和加速上限,这样列车或阿里亞5号可以如我在恒温器例子中描述的一样,忽略导致错误的界外数据或虚假信息。

人类是系统的智能组成

“在任何系统背后真正的智能是构建产品的团队。没有人因设计师或者用户体验专家的团队会构建非人性、危险的系统。”

智能设计是用户体验设计师的作用,我一直在阅读各种关于提升系统用户体验的文章,并在我们的设计中注入人性,然后完全关注材质设计,或将科幻界面的相关教训与系统的意义与功能相混合。

我们不应该只设计屏幕,还要设计更系统更广泛的用户体验。用户体验设计师必须设计信息结构,减少错误展示和最小化延迟的方法以及出现变数或没有网络时发生的各种行为。我们必须为系统、组件和用户出现不可预料的情况设计解决方案。没有其他人会代表用户,关注他们的目标并保证他们的安全。

最近有很多关于人工智能的讨论,感觉像大数据的延伸及过去这些年另一个算法决策趋势。这些技术可能确实会改变世界,但问题是它们是会将它变得更好还是更坏呢?

在任何系统背后真正的智能是构建产品的团队。没有人因设计师或者用户体验专家的团队会构建非人性、危险的系统。作为用户体验设计师,你的决定决定了系统的情感和道德。它们建立了逻辑和安全的边界。用户体验设计提供了系统的人性。我们萤爱构建人们可以安全、有效与之交互的系统。

关注下方公众号二维码或搜索公众号:Forbetterworld, 内容同步更新,

欢迎留言讨论,转载请注明出处,观点归原作者所有。

英文版地址:avoiding-stupid-rude-destructive-and-deadly-design

发布者

是观

交互设计师,对用户研究、情感化设计、游戏化设计、服务设计及行为改变等用户体验过相关领域及其感兴趣,欢迎大家一起讨论学习。

发表评论

电子邮件地址不会被公开。 必填项已用*标注