糟糕的“设计”——产品的情感化设计

的编辑页面是无法直接通过复制/粘贴的方式上传图片的，只能通过工具栏的图片选项上传本地文件。创作者找到图片上传的按钮并不难，上传图片的产品逻辑也没有任何问题，但是冗余的使用路径会拉低创作者的效率。

另一个更通用的例子是——IOS自带的系统闹钟。网上关于苹果闹钟无法跳过国内法定节假日的吐槽已经持续了好多年，在苹果社区内也有不少帖子反馈和投诉，并且得到了广泛的响应。

苹果内部的运营及PM也一定收到过类似的反馈，也许是当前闹钟的逻辑过于“自洽”，也许是国内用户被认为过于“糟糕”，到现在也没有任何改进。

2. 嘲笑用户

社会生活中人们经常会因为沟通中的细节感到被冒犯，有的时候并不是自己有主动嘲笑的意愿，只是表达的方式过于生硬和迂回，导致对方会有被嘲笑的感觉。产品也是一样，不当的沟通和表达，会让用户感到被产品冒犯，降低使用意愿和频次。

1）缺乏“常识”的用户

任何一个产品的开发者和使用者都是完全不同的两个群体，而一个群体内的共识往往是另一个群体从未接触过的知识。用自己群体内的常识作为基础去沟通，除了会让对方群体感到困惑，也会让对方感到不尊重，最后减少交互的意愿。

以链家官网为例，用户首次注册时，并没有明确提示用户正确的密码格式。只有当用户首次提交时，才会把正确的密码格式要求作为错误提醒展示出来。

而QQ在用户注册页面，密码一栏非常简单明了。用户输入时即提示正确的密码格式，而且会随着用户的实时输入做格式校验。

也许在部分PM和开发人员的眼里，“字母+数字”的校验格式已经是默认的行业规则。但对于用户来说，打开一个新的网站就是一次全新的体验，他们不是互联网从业者，更没有行业知识的背景，按照自己的理解输入却要被系统嘲笑不懂IT常识，这会让用户产生非常负面的情绪。

2）不懂“术语”的用户

术语是加快沟通效率的常见方式，可是对于不懂术语的用户来说，他们并不需要也不愿意去主动学习一些不在日常生活范畴内的术语。

互联网用户最常接触到的术语是程序的错误码，不少产品对异常场景的页面简单处理，随意曝光错误代码。也许大家是认为程序报错的概率很低，用户见到错误码的机会较少。殊不知越是异常场景，用户越是慌张，一串不明所以的错误代码，往往会增加用户的不信任感和不安全感。

以QQ授权错误的页面为例，用户不是工程师，不需要调试各种错误，他们无法理解像“redirect”或则“回调”这类术语的含义。对于用户而言，告知下一步操作的指示比当前错误的原因更为重要。

相比之下，百度对404页面的处理就要好很多，没有直接曝光404错误码，而是提供更好理解的白话，以及下一步的操作指引，用户的安全感和掌控感会得到极大的保留。

3. 排斥用户

所有的产品都有自己的标准用户画像，有的产品对用户的年龄有限制，有的产品对用户的地理位置有限制，有的产品对用户的性别有限制。但是随着产品受众面地扩大和社会影响力地增加，产品需要承担社会责任，并接纳更多的非典型用户。最近的例子是从去年开始工信部主导各类主流APP的适老化改造。

商业产品都是利益导向的，排斥非典型用户往往是产品基于ROI的商业化选择。但是任何的公司和企业都要承担一定的社会责任，就像有些互联网企业标榜自己是信息时代的基础设施，要成为“水、电、煤”类的民生应用。那么传统企业面临的社会责任问题，互联网产品也无法避免。

像微信和淘宝这种国民级应用，虽然老年人用户的比例不高，但是换算成绝对数量也比很多主流APP的用户数量要多。随着法律法规的完善，适老化改造会逐步成为互联网产品的必备功能。

如果我们站在更高的角度看适老化这个问题，其实老龄人只是无障碍设计的一部分群体，还有很多存在视听障碍的人也无法顺利享受互联网的便利。而且因为互联网对线下的冲击，他们过去可以在线下享受到的服务也被消减掉了。

美国早在90年代就有专门保障残疾人福利的法案ADA（Americans with Disabilities Act），强制要求所有的商业机构保证残障人士正常使用服务的权利。因为很多商业网站对合规性要求的重视，美国本土还诞生了专门辅助残障人士使用web网站的公司——UserWay，目前市值已经超过1亿多美金。

淘宝的官方网站也及时跟进，提供了各种残障人士的辅助工具。

二、“冷漠”的产品

优秀的产品由多方面的因素构成，而平庸的产品往往可以给自己找到一百个理由去排除自身的原因。缺少情感化设计的产品比比皆是，也很少引起PM和开发人员的注意。大家似乎已经假定产品本身只是一个软件工程的物理产物，情感化设计并不是一个值得高频讨论的话题。

但是当我们进入交互设计的范畴，特别是人机交互（HCI）领域，缺少情感化设计的产品，就像你身边从来不在意他人，只顾自己感受的“冷漠”同事。

1. 缺少反馈

人和人之间的冷漠往往源自缺少交流和沟通，那么糟糕的产品也是这样，不会主动建立沟通的闭环，只是机械地按照程序语言执行。

任何产品都需要用户的参与，交互界面会有大量需要用户采取特定行为的触发器，比如下拉滚动，左右横滑，点击按钮等……但是因为网络或则执行顺序的关系，不是所有的动作都可以及时展示最终结果。

那么这个等待的过程，应该如何展现给用户？当用户看到自己提交的大量数据已然消失，期望的动作也并未发生时，用户会产生极强的不安全感。

以Airbnb的房屋详情页为例，载入过程中会提前将整个页面的“骨架图”展示出来，获取数据后再替换为真实的页面数据。这样既符合页面的整体UI风格，又减少了客户的不安全感。

2. 将复杂交给用户

很多事情都有天然的复杂度，无论怎样优化或则转移，都规避不了系统的复杂性。这类问题在B端软件中较为常见，比如较长的表单，高度耦合的多个功能等。但是站在产品的角度上，我们可以选择将这类复杂性交给用户处理，还是程序处理。

以Hubspot添加联系人为例，常见的CRM系统因为历史销售线索量很大，很容易出现重复添加相同联系人的问题。有些产品只会在客户提交完表单后再告知哪些线索是重复的，但是Hubspot会在客户输入特定信息时自动检索已经存在的联系人，并提供快速查看的入口。

类似的复杂性问题还有很多，“糟糕”的产品会直接把这类复杂性丢给用户自己去解决。而优秀的产品则会主动承担更多，将复杂性留给产品自己，把易用性呈现给用户。

3. 完全数据化

数据驱动产品是互联网公司的重要指导思想之一，A/B test、AARRR、数据采集、用户分群……已经成为大厂工具人耳熟能详的词汇。但是完全的数据化，意味着我们需要丢掉一个个真实用户的反馈，所有的决策都是基于冰冷的数字，而不是真实用户的声音。那么这样就是对的吗？

1970年福特汽车曾经生产过一款叫平托（Pinto）的小型汽车，投放市场后因为较低的油耗和实惠的价格获得了消费者的青睐。

直到1974年，因多起事故发生，美国公路交通安全管理局调查发现平托车的油箱存在设计缺陷，相比其他汽车更容易发生爆炸事故。其实福特早在出厂时就发现了这处设计缺陷，只是因为内部测算事故发生的概率以及赔偿的金额只有不到5千万美金，但是给每辆汽车加上防护装置，需要花费一亿三千万美金。

福特管理层充分依赖数据做出了不加防护装置的决策，节省了一时的成本，却忽视了上百条被车祸伤害的车主，最终在1978年召回了150万辆平托汽车。

正如第一节讨论的互联网产品适老化改造，完全基于数据的决策就是商业上的成功吗？即使在科学实验中，定量分析也总是需要结合定性分析来印证假设。那么对于互联网产品也是一样，冰冷的数字需要和用户真实的反馈结合到一起，不管是考虑社会责任，还是企业的长远发展。

三、小结

互联网的进步和用户声音的逐步扩大息息相关，Web 1.0的PGC网站可以完全忽视用户的反馈，搭建自己的信息垄断平台；Web 2.0的UGC APP则需要依赖用户力量，鼓励大家的参与从而放大自己的网络效应；而如今正热的Web 3.0，则让用户完全作为产品的主导者控制整个产品的游戏规则和商业模式。

如果我们还在提供“糟糕”的产品，忽视用户的情感述求，那“糟糕” 的用户必然会摒弃“冷漠”的产品。

本文作者 @One

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！