Hacking，骄傲与不适

「Hack」的意思有很多，这里指的是：

Hack (computer science), an inelegant but effective solution to a computing problem

Hack（计算机科学），对计算问题的一种不优雅、但有效的解决方法。

欧路词典 的例子

前些天下载了 欧路词典 的 iOS App，其具有特色的「跨软件取词」功能。使用方式是通过对需要翻译的词进行 拷贝 操作，然后软件将词的解释推送的方式在 通知中心 呈现。

*欧路词典* 跨软件取词介绍页面

介绍页面尽管制作实在称不上精良（图片素材为 iOS 6 的界面；右上角的「iPod」字样与 iPhone 素材不符），但较清晰地表述了使用步骤。紧接着我开始尝试着使用，却引发了不适感。

实际使用

当进行 选择 > 拷贝 操作之后，通知中心推送出解释，发出读音。很奇怪，所有的反馈都合情合理，但只有实际使用时才萌生出这样的感觉：「通知中心怎么会出现通知以外的信息？」

这是一种 hack：巧妙地利用多种工具的特性，加以特殊的使用方式，以达到目前难以实现的目的。这与 Wikipedia 上的定义有略微冲突，后者中「inelegant」（不优雅）一词略带贬义。

在 欧路词典 for iOS 的例子中，开发环境是：

• iOS 8 中选择文字后能进行的操作十分有限，且操作列表没有相关的 API，但「拷贝」选项是通用的
• iOS 8 开放了通知中心快速操作的 API

其采用的设计是：

• 选择了用 拷贝 按钮对应「取词」操作
• 选择了 通知中心 作为「单词解释」信息的呈现平台
• 推送「单词解释」后，下拉可进行 加入单词本 和 发音 操作

其中的交互、反馈与其名称或者用户心智模型（假设用户对系统有一定熟悉程度）的冲突是造成不适感的主要原因。特别是在 通知中心 中呈现，单词解释不仅会一直保留至手动删除，更会与其他推送通知比如 IM 软件、邮件等以时间线形式混合排布。这种「信息出现在不恰当区域」的设计，相对容易被开发者忽略。

「单词解释」在 *通知中心* 中与其他推送混杂

相比之下，iOS 自带的词典则凭借其系统级优势，给出原生的优秀体验。

iOS 系统自带词典

系统自带词典的功能非常精简——只有查询单词解释。这跟现实世界中的词典功能完全一致，符合隐喻；而其他词典 App 则通过单词记忆管理、外语内容聚合等形成竞争力，更符合「英语学习应用」的定位。在 1Password 这个著名的跨平台密码管理应用第一次出现的时候，苹果对此的评价是：

密码管理应该是一个系统功能，不应该由一个 App 实现。

这句话等于变相承认自己的系统在密码管理方面的弱势。当然，掌握着系统控制权的苹果可以通过「卑劣」地将其整合在系统层级，而弱化没有抓住市场先机的恶果，之后的 iCloud Keychain 也证实了这一点。词典也一样。仅仅是「查询单词解释」根本不需要一个专门的 App ，但学习外语肯定需要（尽管词典应用大多数情况下的使用场景仍然是查询解释）。系统词典是一个足够好的词典，但不能满足很好的外语学习需求（它也从来没想着满足）。其他的词典应用因为没有足够好的取词接口，所以要通过「巧妙」利用 拷贝 功能的方式实现，并在 * 通知中心* 呈现（形成了 hack ）。

Hacking 无处不在

下面是 搜狗号码通 lite 是如何在不越狱的情况下判定骚扰电话的？ 中 Ryekee 的回答 中「hacking」的例子：

机智的产品经理是怎么绕过 iOS 沙盒机制的

** 如何在锁屏界面显示歌词？
利用锁屏界面的封面图片。为每一句歌词生成一张新的图片，不停的更换图片。

** 如何清理系统缓存？
利用 iOS 7 之后的系统特性（当空间不足时自动清理缓存）。生成大量冗余文件，快速占用系统空间，触发系统进行清理。

** 如何显示农历？
获取日历读写权限，为每天的日历都添加一个全天事件，事件名就是农历历法。

** 如何识别骚扰电话？
获取通讯录读写权限，把所有电话暴力写入通讯录。

关于 hacking 的看法

哪里有压迫，哪里就有反抗。只要限制存在，hack 行为就不会停止。Hack 是一种带着「功能至上」思想，把形式和体验的优先级放得很低的行为。甚至越是反常的和「不优雅」的结果，就越能体现出 hack 的精神，体现其创新性和硬核（hardcore）性质。对于崇尚者来说，其中的叛逆感、成就感和强烈的目的性无疑是刺激而令人骄傲的。另一方面，其非原生、「不优雅」、较陡峭的学习曲线也注定其产品至少阻挡了一部分用户的脚步。

Power user 通过 hacking 产出产品，再提供给其他用户使用。在上面的例子中，欧路词典 的开发者是「power user」，我们是「其他用户」。

Hacking 代表着一部分用户的需求，具有自发性和实验性。「hacker」往往是因为自身的需求而不是商业目的做出 hacking 行为（这一点跟创业者很相似）。Hacking 就像是一种模因（meme），越能切中痛点和硬需求，自身竞争力就越强，也越有「存活」下去的竞争力。事实上，成功的 hacking 最终很大程度上会贴上商业化的标签，成为「正统」的方式（上文例子）。

而代表着大众认知的人群，hacking 做出的产品往往不是彻底的解决方案，不能提供友好的、完整的体验。因此，用户体验设计师的工作中应该包括尽其所能把「hacking」带来的不适感降到最低。在 欧路词典 中，受限于系统的封闭性，虽然这算得上是目前为止的优秀设计，但仍有不足。个人更倾向于 [WhatFont][WhatFont] 插件开发者的做法：在 iOS 8 开放出 Safari Extensions 时才把搁置的插件完成并发布，以保证有友好而完整的体验。
[WhatFont]:http://chengyinliu.com/whatfont.html

WhatFont 插件介绍页面

Hacking 无处不在，也不会消亡，甚至不仅仅在软件世界里出现。任何一种不以其原先设计的方式使用的行为中都可以看到「hacking」的影子。正如 深泽直人 经常在书和演讲中谈论环境与人的关系时常常用到的例子：

Affordance

牛奶盒底面与扶手上的台面吻合，手臂和车窗的高度正好相符，因此物品存在着另一种可能的使用方式。Hacking 是高度发掘产品的 [affordance][affordance] （可供性）的例子。
[affordance]:http://en.wikipedia.org/wiki/Affordance
甚至有一个叫做「[Life Hack][lifehack]」的单词形容生活中的 hacking，比如：
[lifehack]:http://en.wikipedia.org/wiki/Life_hacking

Life hack 1

Life hack 2

用户实际的需求和设计师想解决的问题有出入时，会造成「用户以设计师没想过的方式使用产品」的情况。Hacking 是其中用户主动性比较强烈的例子。因此，hacking 对用户来说可以解决实际问题，对设计师而言有体现用户需求的作用，尽管这个需求可能是已经被察觉但由于种种原因（目标用户需求不吻合，缺乏技术支持等）被放弃。

在 欧路词典 的例子中，我更愿意相信是缺乏接口的原因。

在设计中，设计师应注意是否做出了「design hack」，如有则需将伴随的风险纳入考虑。完成巧妙设计的骄傲，可能给用户带来的不适，两者之间的衡量在实际设计过程中肯定也是一个难题。

最后，愿所有优秀的 hacking 都会被开发者「合法化」：）