那些令人愉悦的设计，都存在怎样的风险？

">

哪些让你感到快乐的事情，往往到最后会给你带来诸多麻烦。

令人愉悦的设计是如何给你带来麻烦的

如果让你思考哪些东西可以给你带来愉悦感，你可能会联想到那些从内到外都让你感到温暖和舒适的东西。比如，毛绒玩具、蛋糕、或者是一个拥抱。

但是你有没有想过，那些令人愉悦的事情都有消极的方面。比如，一个愚蠢的玩笑很可能会惹你生气；一个有针对性地广告可能会误导你；一个可爱的声音效果可能会把你逼疯。

在设计圈内，我们常常夸奖那些令人愉悦的设计方案。但不久你就会看到，那些令人愉悦的细节可能会给你带来很多麻烦。

令人愉悦的设计挡道了！

如果你稍不注意，令用户愉悦的设计细节可能会降低产品的可用性。

Morimoto是以日本著名的厨师Morimoto来命名的，它是一个典型的用户愉悦感高于网站可用性的例子。它们的桌面网站已经尽可能使用户感到很愉悦，但是结果却导致了网站特别不好用。比如：

Morimoto的网站

令人愉悦的设计给你一个机会去表达品牌的声音，这些设计给了你的产品生命。

但是如果你稍不注意，这些设计就挡道了。就像Morimoto的网站，太多令人愉悦的细节的堆放很烦人，而且这些设计细节降低了用户做自己想做的事情的效率。

愉悦感也有保质期

为了创造愉悦感，你需要不停地创造惊喜。当你为了让用户开心做了一些奇特的、超出用户预期的事情时，用户才会产生愉悦感。

我仍然记得我第一次打开我的android手机看到如下图所示的启动画面时的情景：

android手机开机动画

当我看到这些圆圈神奇地变成Android标志的时候，我都惊呆了。我觉得这是有史以来我见过的最炫酷的加载动画。

用了一段时间的Android手机后，看了一遍又一遍这个动画效果，我就没有第一次时的那种愉悦感了，而且，我也不觉得它有丝毫的惊喜了。

随着时间的消逝，令人愉悦的设计细节也会风化的。愉悦感是否保质期的，即使是很用心的设计细节，用户看过几次之后，也就没什么感觉了。为了保持用户长久的新鲜感，你可能需要长期地修改设计细节。

愉悦感是一种主观感受

有没有曾告诉设计要尽量好玩有趣？但这个一个错误的观点。当你尽力想要在一个糟糕的场景下制造点乐趣时，别人可能正在绝望地只想要完成自己的任务。这个时候的乐趣在别人看来就带有一种冷漠和侮辱的感觉。

而且，愉悦感对不同的人是不同的。一个人感到很愉悦，另一个人可能觉得很糟糕。根本不存在所谓的通用的愉悦感。

愉悦？糟糕？

当你想要让别人感到愉悦时，也许你是出于一片好心，但是你永远不知道你什么时候会惹恼别人。

愉悦感无法衡量

随着你的用户量的增大，让用户愉悦这件事会变得越来越难。如果你只是一个小品牌，你还可以在你的产品里尝试使用风趣的表达方式。 但随着你的用户越来越多样化、越来越国际化，让每个人都觉得很愉悦这件事会变得特别难。

通过比较大品牌（左边）和小品牌（右边）使用的语言表达方式就能看出这一点：

Microsoft Teams vs. Slack

Google Docs vs. Quip

Eventbrite vs. Splash

有没有发现一个趋势？一般来说，大型国际品牌往往倾向于使用更直接、更传统的语言表达方式，因为这样对他们来说最安全。直接的表达方式更容易本土化，而且让人觉得很亲近。

相对而言，右边图片里使用的语言表达方式对我而言更加有趣，但更像是对某个特殊的人群说的，而不是所有人。如果你不是这个特殊人群的一员，你可能不会觉得这种语言表达方式让人感到愉悦。

什么时候适合做愉悦的产品设计呢？

到目前为止，你应该已经知道了一些令用户愉悦的设计细节给你带来了一些麻烦。设计令人愉悦的产品细节是有风险的，但是这并不代表你可以完全抛弃它。最难的部分应该就是明白什么时候可以展现令用户愉悦的一面。

根据我的经验，以下是一些用户不会经常注意到的地方，在这些地方增加令用户愉悦的设计细节是相对安全的。比如：

这些都是只在用户眼前出现一次的场景，在这些场景里设计令用户愉悦的产品细节不会让用户觉得厌倦。

这也是为什么你会经常在新员工培训时看到愉悦的图片的原因。下图是谷歌网站第一次访问时的例子。谷歌大多数的UI都是非常传统、非常直接的，但是在一次性的新员工培训中，新员工会很惊讶地看到这些可爱的插图，看到谷歌令人愉悦的一面。因为你只会经历一次新员工培训，你只看一次，你也就觉得很愉悦了。

说实话，我一直在想这个问题（什么时候适合做愉悦的产品设计呢？）。但是愉悦感真的是太主观了，以致于很难制定通用的规则去衡量它。我特别想要找到关于什么时候可以使用愉悦的设计细节以及什么时候不能这么设计的标准，但是这比想象中要难得多。因为每个人都可以定义什么是愉悦感。

你的产品是怎么制造愉悦感的？有没有什么标准？如果有的话，我洗耳恭听。你可以在评论区里给我留言。

— end —

翻译：Q_misky

作者：John Saito @Dropbox. Previously @YouTube and @Google

本文由 @Q_misky 翻译发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议