向你的双手致敬，感恩它们带来的神奇力量Show your hands honor for the strange power they bring you

Marcin Wichary

2026年6月18日 / 7700字 / 38个互动示例

关于设计适合手指操作的交互

大约一百多年前，出现了一个问题。人们打字实在太快了。

我知道你在想什么：相对于那个时代简陋的打字机来说，他们打字太快了。但与普遍的看法相反，打字机从来没有那么简陋。即使是在第一款普及的打字机上，你也能打得飞快，而 QWERTY 键盘布局实际上正是为了让你能快速打字而设计的。

不，相对于我们认为的人体极限而言，人们打字太快了。根据我们对大脑内部神经元传递、感觉处理以及手指生理机能的理解，打字员的极限速度本应只略高于每分钟40个单词。

但他们通常能达到每分钟70个单词甚至更多。

事实证明，手指是时间旅行者。在任何特定时刻，每根手指都处于略微不同的时间点——当一根手指正向下移动按键时，另一根手指已经在前往下一个按键的途中了，而你的大脑则在提前思考接下来的几个键，想象着你的双手移动到正确的位置。

这些都不需要盲打。即使你处于“寻找”和“敲击”（二指禅）这种尴尬的打字方式中，我们最终称之为“重叠”的现象也会发生。重叠是一个发生在你眼前的微小奇迹，而且几乎会发生在每个人身上。

这是我们的双手和大脑的一种能力，它们能相对独立地控制手指，让它们以自己的节奏移动，而无需等待（同一只手上的）其他手指完成动作。

而且，这远非唯一的奇迹。我们的双手令人惊叹，我们的手指令人惊叹，我们的大脑同样令人惊叹。它们结合在一起所能创造的壮举，就在不久前还完全无法用科学解释——甚至在今天有时也无法解释。

几个世纪以来，艺术家和表演者一直凭直觉明白这一点。如今，大量的创意和生产力都发生在屏幕上，但我们的界面却往往无法像老式乐器那样尊重手指。

我想向你讲述更多关于这方面的内容，以及作为设计师，你有哪些责任来确保界面能够做到尊重手指。

关于乐观主义的早期教训

这是一篇互动文章。

你可以关闭声音、跟踪你的任务，或者使用屏幕顶部的菜单进行导航。

你的进度将在不同会话之间保存。

当计算机还是像冰箱一样庞大的机器，藏在房间里伴随着20世纪60年代最顶尖的空调技术嗡嗡作响时，与它们的任何交互都带着一种理所当然的冷漠：它们允许的唯一接触方式就是通过终端进行远程操作。

终端机就是一台去掉了昂贵部件的台式电脑。它的 CPU 性能不佳，内存很小，逻辑处理能力极弱。早期它连屏幕都没有，而是使用打印机甚至打字机作为人机交互界面。

鉴于这些局限性，构建键盘操作最简单的方法是：每次按键都必须通过缓慢的调制解调器一路传输到大型计算机，只有在“机器”确认其到达后，它的回显才会被打印出来返回给你。

这种往返过程造成了延迟。而延迟让打字变得极其不愉快：

带有缓慢回显的打字

终端

延迟

输入受限

这有时甚至比你现在在这里体验到的还要令人不快：刺耳的蜂鸣声，甚至终端会在物理上锁定键盘。（你知道那种下楼梯时以为还有一级台阶，结果一脚重重踩在地上的感觉吗？想象一下这种事一直发生在你的手指上，一整天都是如此。）

针对这个问题的第一个解决方案是创建一个缓冲区（buffer），这样你就不必等待输入下一个按键。现在，只有当你打字太快填满整个缓冲区时，才会发生锁定或蜂鸣：

使用缓冲区输入

终端

延迟

缓冲区

正在使用的缓冲区

缓冲区溢出

延迟依然存在。但只要按键本身没有变脏或卡键，这就没关系，对吧？毕竟，手指非常灵巧，它们不需要眼睛的确认。手指是如此灵巧，以至于有时会替你按下退格键（Backspace），既不需要你看，甚至也不需要你意识到，仅仅因为它们自己就能感觉到上一次按键按错了。

但到了20世纪60年代，打字已经从单纯的重新录入备忘录，发展到了创意写作、编程以及其他不那么死板的键盘使用形式。方向键首先出现；不久之后，显示器出现了，然后全屏菜单也出现了。如果你不看键盘，除了那个持续且令人绝望地延迟的屏幕，你还能看哪里呢？

而且你本就不应该看着键盘——这对于肌肉记忆的养成其实非常重要！

因此，下一个发明就是所谓的“本地回显”（local echo）。

本地回显是一个善意的谎言。你的按键现在会立即且乐观地显示在屏幕上，假设它能毫无阻碍地到达计算机。这似乎是最显而易见的解决方案，但它确实比以前增加了复杂性：现在你的终端不能再是纯粹的哑终端了，而且你必须处理系统两端的配置，以确保只有一个回显，而不是零个……或者两个：

在服务器或计算机传回确认信息之前，操作的确认就会立即显示在屏幕上。这样做是为了让 UI 看起来比实际运行得更快。对于重要的更新，需要做出特殊处理，以检查更新确认是否未能到达，并告知用户（例如，这种乐观假设是否错了）。

使用本地回显输入

终端

本地

远程

回显

就这样，我们用一些新获得的计算能力，换来了重建我们在五十年前就已经拥有的东西：以手指速度运行的打字体验。

但在此之前，缓慢的传输速度早已在当时的软件上打下了烙印；据说，Unix 隐晦的简短命令和流行编辑器 vi 极其隐晦的界面，都是针对那个即将逝去的时代而优化的。

这将是本文的一个主题。

“五十年前”指的是20世纪10年代——那是我们开始分析和理解打字的第一个时代。但是，早期量产的打字机比这还要早出现半个世纪，而钢琴键盘的历史则更为悠久。这意味着我们对手指和打字的深入理解，基本上是伴随着打字机出现的，而不是超前于它。

19世纪70年代：首批 QWERTY 打字机

19世纪90年代：盲打实验

1910年代：QWERTY键盘与盲打标准化

1940年代：人机工程学（也称人类工效学）的早期研究

1950–70年代：机构用计算机

1980–90年代：家用（微型）计算机

2000年代后期：现代多点触控智能手机与平板电脑

最好的例子？盲打的兴起。第一台流行的 QWERTY 打字机就是为了追求速度而设计的——它最早的应用场景之一就是实时记录 Morse 码信号，操作者随随便便就能达到每分钟 50 个单词的速度。令人惊叹的是，这种速度在当时是用我们今天所谓的“二指禅”（看着键盘找字敲击）实现的。

键盘的出现让人们有了更多梦想，包括备受追捧的实时语音转写构想。为了实现这个梦想，许多人开始摸索“盲打”——九指敲击键盘，眼睛不看键盘。这项技术花了数十年才发展成熟，当时许多人认为它只是一时的狂热，而且在之后的好几年里，也没人能对什么是“标准”盲打达成共识。

打字机上的盲打从未达到过人类语音的转写速度，据估计英语语速约为每分钟 150 个单词（150wpm）。要做到这一点，必须使用特殊的速录键盘，这种键盘按音节输入，并支持和弦式组合按键（同时按下多个键）。

到了 1910 年代，盲打已完全确立并相当普及，并伴随打字机一直走到它们生命的尽头。但是在 1940、1950 和 1960 年代，那些早期且笨拙的计算机（和终端）配备了笨重的“实验室”键盘，通常比早期的打字机还要糟糕。这也是合情合理的——如果远程回显和缺少缓冲区让盲打根本无法实现，谁还会去关心它呢？

前端大脑与后端大脑

但人机工程学的进步并不均衡。仅仅十年后的 1970 年代，情况就发生了翻天覆地的变化。随着计算机变得更小、更快，且交互距离越来越近，并配备了回显和缓冲区，它们的键盘也需要随之改进。它们开始吸取前代最优秀打字机的诸多经验，并且摆脱了机械打字杆的束缚，其人体工学设计达到了打字机无法企及的高度——这反过来又使得操作者的手指移动速度快到不可思议。

除了机械上的优势，又增添了空间距离上的优势。如果你的计算机现在离你的键盘只有几英寸远——或者干脆就藏在键盘里面——那么本地回显和缓冲区就成了历史名词，对吧？

并非如此，因为较小的计算机也比大型机慢得多。此外，现在需要让人感觉“快”的不仅仅是按键和打字。键盘上的按键无非就是按钮。在 1970 和 1980 年代，计算机屏幕上也配备了按钮——起初通过配有新发明的方向键的键盘来操作，后来则用鼠标来操作。旧的概念再次变得重要起来。

试着按一下这些无法在“指尖时间”（即时）内做出反应的按钮，看看感觉有多糟糕：

缓慢的磁性贴诗

鼠标事件延迟

按钮处理时间

忙碌

重置

吸取过去的教训，我们可以想象在这里加入缓冲。这很有用，但也仅限于此。操作可以被缓冲并以最快的速度处理，但鼠标事件同样不得不排队等候。因此，即使一台计算机的速度快到足以在你的鼠标悬停或按下时瞬间绘制出不同的按钮状态，在缓冲区耗尽之前，它也无法这么做：

带缓冲的磁性贴诗

鼠标事件延迟

按钮处理时间

正在使用的缓冲区

忙碌

重置

这感觉依然很糟糕。在现实生活中，一个又脏又粘的按钮已经让人很不舒服了。而在这里，按钮那种又脏又粘的感觉极其怪异，因为缺少了现实生活中那种能让大脑理解状况的触觉信号。过去打字机物理上的卡键感觉也很糟。但在计算机尚未准备好处理时，哪怕只是暂时挂起界面，同样令人不悦。

“Haptic”（触觉的）指的是与触觉相关的事物，而“haptics”（触觉反馈）是科技产品的触摸响应，是一门通过模拟对人类触摸的物理响应来提升产品手感的现代科学。例如：现代 Apple 触控板的合成点击声，或智能手机中的振动马达。

用专业术语来说，这通常被称为 UI 阻塞（UI blocking）。

（如果你的设计师没有对 UI 阻塞深恶痛绝，那你需要换一个设计师了。）

指的是那些完全阻碍界面做出反应的操作。在现代操作系统中，鼠标光标本身永远不会被阻塞，但这可以指代无响应的按钮和其他控件，或者无法在输入框中输入内容以及拖动窗口。

一个简单的解决办法是去抖（debouncing）——即对任何繁重的操作稍微延迟响应，让界面在计算机处理繁重任务之前先完成简单任务的处理。这完全是本地回显（local echo）概念的一种遥远的回声。

一种在短时间内处理并平滑大量小事件的方法。它源于现实世界中的开关（如电灯开关），其从“关”到“开”的物理变化可能是不稳定的（弹跳的），并在两个状态之间快速连续转换多次。

但最好的解决办法是将计算机的注意力分成两条轨道。“后端大脑”可以处理繁重的操作并根据需要将其缓冲，而并行工作的“前端大脑”则实时处理界面事件，绝对不会出现阻塞用户界面的情况：

这就是当今所有计算机上鼠标指针的工作方式。鼠标指针的移动始终在单独的 CPU 线程上运行，因此它永远不会卡顿，也不会破坏这种完美的体验。然而，智能手机上的触摸键盘却并非如此，它们可能会发生 UI 阻塞，并以令人不安的方式停止响应。

并行 UI 线程

按钮处理时间

正在使用的缓冲区

忙碌

重置

但即使是这种方法也有注意事项。一旦你将某些东西放入缓冲区，缓冲区就必须将其完全耗尽（处理完）。

我们都经历过这种情况：长按方向键移动物体，发现计算机比我们想象的慢，于是开始按反方向键，结果矫枉过正，陷入了一个奇怪又令人沮丧的来回拉锯中：

耗尽缓冲区

↑ 按键重复时间 ↓ 窗口移动时间

正在使用的缓冲区

忙碌

紧急停止

这个问题没有简单的解决办法。

上面的“紧急停止”按钮有点像个玩笑，但你可以想象一种特殊的快捷键，比如 Esc 或 ⌘.，可以立即清空缓冲区。不过，用户必须知道这个快捷键，而且该快捷键本身根据定义是不能被放入缓冲区的，这可能会有问题。

你还可以区分长按按钮和多次连按，并尝试对此进行处理。这两种情况都在下面实现了：

更智能的缓冲区

↑ 按键重复时间 ↓ 窗口移动时间

使用中的缓冲区

忙碌

紧急停止

但一如既往，最佳的解决方案是让交互尽可能快，避免延迟发生，从而极少需要用到缓冲：尽一切可能，以手指敲击的速度向用户显示反馈。

幸运的是，如今极速的计算机应该让这变得轻而易举，对吧？

对（感知）速度的（实际）需求

当然，棘手之处在于，如今的计算机不一定比 20 世纪 90 年代的更快。我知道，从技术上讲它们确实更快了，但摩尔定律带来的性能提升往往被消耗在要求计算机完成的新任务上，或者是中间新增的抽象层上。

如果你的计算机恰好处于高负载状态，许多上述早在 20 世纪 80 年代就已解决的简单示例，在今天可能对你的手指来说仍然太慢了。而且，我们对计算机的期望早已不再是简单的任务了。对此，最好的例子莫过于“边打字边搜索”（as-you-type search），在键入的瞬间就向你展示结果。让这种体验变得出色的纯粹算力，早在 20 世纪 90 年代（甚至 80 年代）就已经具备了。

但是，互联网重新引入了 20 世纪 60 年代远程计算的一些痛点，互联网浏览器这一新中介（以及后来的 JavaScript 库）吞噬了大量速度优势，而操作系统中精心实现的回显和缓冲机制，并没有奇迹般地自动适用于网站。

如今，许多拼凑而成的搜索功能仍然会阻塞 UI（用户界面），让你在每次击键后都要等待。另一些则无法妥善处理用户在结果飞速返回时更改搜索词的常见情况：

糟糕的边打字边搜索（Bad search-as-you-type）

搜索

延迟（平均）

紧急停止

我们对那些能完美处理所有这些情况、并且无论环境如何都始终感觉敏捷的搜索功能习以为常——比如 Google 的 Autocomplete，或者 Raycast。他们的秘诀是什么？他们同样知道“撒谎”也是可以的。

人们会告诉你，加载状态——进度条、旋转图标、即将加载内容的“骨架屏”以及可爱的动画——的作用是准确地告诉用户正在加载什么，以及需要多长时间才能完成。但如果要说我对加载状态了解了什么，那就是事实并非完全如此。加载状态唯一且仅有的一个目的，就是不惜一切代价让软件感觉尽可能快。

通往缓慢界面的道路，是由追求快速的意图铺就的。第一个基础模块是为任务选择合适的加载状态。过于沉重的加载状态会让界面感觉更慢，并让用户直觉地放慢操作速度。

基础加载状态

延迟

在上面的示例中，所有的加载状态在功能上都是正确的，但你能感觉到其中许多显得沉重和/或用力过猛，过度地将用户的注意力吸引到了加载这一事实上。

因此，第二个基础模块是知道何时不显示加载状态，有时只需静观其变，而有时则假装（通过乐观更新）事情比实际情况更快。

低调的加载状态

延迟

尤其是那些直接受手指控制的东西，它们无法参与到加载状态中。你的大脑能理解等待，但手指不行，它们始终在实时操作。

按键和按钮也是如此——我们已经讨论过，无论是从物理上还是通过提示音来阻断按键，都是行不通的。但这在应用到更复杂的交互时，就显得更为重要。触摸一个物体是一回事；而按住一个物体且它没有实时反应，则会更加令人不安。

我习惯参考的数据是：为了获得良好的手感，鼠标需要 30fps 或更高（即 33ms 或更低），触摸需要 60fps（17ms）或更高，手写笔需要 120fps（8ms），而键盘在软件层面的延迟达到 50ms 时就会开始让人感觉变慢了（软件延迟会叠加在硬件本身通常已有的 20–40ms 延迟之上）。

这方面的经典案例是 1984 年的 Macintosh，当你在拖动或调整窗口大小时，它只会显示一个外框。这个外框承认了当时的算力不足以实时完成这些操作，但它也是一种巧妙的加载状态，因为它明白，粗略近似所带来的速度感，远比完整却缓慢的精确度要重要得多：

拖动窗口

窗口移动时间

拖动外框

窗口移动时间

关于加载状态的“障眼法”还有更多门道。让事物感觉很快的艺术是如此错综复杂，以至于有时为了好的效果，你可能会想要刻意引入延迟。

这里有一个你可能从未留意过的简单例子。如果你正在 Mac 上阅读这篇文章，请按下 ⌘Tab 但不要松开 ⌘ 键——你应该会看到最近使用的应用程序图标。

但现在请快速敲击并松开 ⌘Tab。界面根本不会出现。如果应用程序切换器的主要用例是在最近的两个应用之间来回切换，那么一大堆图标闪现和消失只会让你分心——因此，界面的可见部分总是会有轻微的延迟。

应用切换器延迟

阈值

显示前的按住时间

另一个例子：Chrome 会巧妙地等待一下再重新排列标签页，这样你就可以轻松地连续点击几次 ×，而不必一次又一次地重新定位并寻找每个标签页的关闭按钮。

浏览器关闭标签页延迟

延迟的标签页重排

标签页拖拽死区

现代用于 AI 交互的“流式”界面也很好地利用了这一点，它们选择以更小的块更快地向你展示内容，即使有时这意味着整个对话需要更晚才能完全呈现：

文本流式传输

段落/远程速度

单词/本地速度

流式传输即等待

紧急停止

回到“边打字边搜索”（search-as-you-type）的话题：这些问题都是可以解决的，但这需要我们在结合已有经验时多加细心和斟酌。按键输入必须立即且乐观地（optimistically）输出——绝无例外。搜索过程不能阻塞界面，并且应该在每次按键后进行大约 100ms 的防抖（debounced）处理，然后再发送网络请求。返回的结果需要与当时的搜索词进行比较，只有在匹配时才予以显示。结果应当被缓存，如果你想做得更完美，你可以像手指打字那样预测未来：在后台静默地自动补全搜索词，并提前将结果排入队列，这样当用户输入完成时，就能立即展示结果。

反直觉的是，这种微小的延迟反而能让搜索变得更快，因为针对不完整搜索词的不必要中间查询不会让你的网络饱和。

如果处理得当，这感觉就像魔法一样——手指的重叠动作与重叠的网络请求在错综复杂却又优美的编排中交错飞驰。

优秀的 search-as-you-type

搜索

延迟（平均）

已启用防抖

已缓存

已拒绝

结果

但是，手指的“魔法”技巧远不止于重叠操作。为了深入挖掘，我们必须倒回时间，面对一个令人不适的真相：Caps Lock 的出现早于 Shift。

按键两次不如一次

这感觉有点反直觉，但仔细想想可能就顺理成章了。Caps Lock 并不是对 Shift 的改进。它们只是同一概念的两种不同交互界面。Caps Lock 是传统的模式切换（mode toggle）；Shift 是瞬时切换，有时被称为弹簧加载模式（spring-loaded mode）。

第一台引入小写字母的打字机有两个按键：一个用于启用大写字母，另一个用于禁用大写字母。这相当于把 Caps Lock 拆成了两个……

这种模式只要用户正在执行操作就会一直保持——一旦停止操作，界面就会迅速弹回其先前的状态（就像有弹簧辅助一样）。其他例子包括电子游戏中的按键说话（push-to-talk）、拖动窗口以及 iOS 中的文本选择放大镜。这个概念的一个特殊版本是“死人开关”（dead man's switch），即整台机器只能在按住（弹簧加载）的状态下运行。（Jef Raskin 在他出色的著作《The Humane Interface》中，曾略带调侃地试图建议将其命名为“quasimode”。）

……而且用起来实在没什么乐趣：

两个独立的 Shift 键

你好

Caps Lock

但这一切都发生在各种盲打发明风靡世界的时期，于是有人产生了一个想法：我们为什么不利用打字员通常还有另一只手的手指……随时待命这个事实呢？

于是，Shift 诞生了。不需要连续按三个键，而是一只手敲击字母，另一只手差不多同时按下 Shift。进一步的改进？在键盘两侧各放一个相同的键，这样每只手就都有一个 Shift 键了。再进一步？把按键做大，以满足 Fitts's Law（费茨定律）！

这个等式描述了这样一个现象：如果某个目标距离用户当前指向的位置（用鼠标或手指）越远，若要保证指向的速度和准确性，该目标的尺寸就应该越大。

1901 年，一款出色的打字机做到了这一点，随后成为了热销爆款。这就是我们至今仍在使用的键盘布局。

当时还有更多流传的想法最终被淘汰了——从两三个 Shift 键，到完全没有 Shift 键。

你们当中可能已经有人想到了接下来这个显而易见的想法：你其实不需要同时保留 Caps Lock 和 Shift 键。按下 Caps Lock 和按住 Shift 是两个互斥的操作，所以没有理由不能把它们合并在同一个键上。

如果在 19 世纪向 20 世纪交替时曾有人考虑过这个问题，那对于当时的机械世界来说可能太复杂了。然而后来，当计算机出现时，一些工程师——对于 Ctrl 在争夺“A 键旁边的大键”这个令人垂涎的位置时输给了 Caps Lock 永远感到不满——开始修改他们的键盘软件来实现这一做法。在他们的键盘上，Shift 键通常照常工作，只有一点不同：如果你像按普通键一样按一下它，它就会起到 Caps Lock 的作用。然后，无论怎么看都不配占据键盘这个位置的 Caps Lock 键本身，就可以被重新分配去做其他事情。

除了在日本。

Shift/Caps Lock 组合键

Hello

Caps Lock

我想知道为什么这个方案没有流行起来。我见过它最接近主流成功的一次是在 NeXT 键盘上，它正是采用了这种设计，并将其称为“AlphaLock”，甚至在两个 Shift 键上都装了指示灯。

NeXT 键盘还有更多有趣的想法，比如取消了功能键，或者在空格键下方设置了一个 Command 条，但它们都没能在 1997 年与 Mac 重新合并后存活下来。

然而，即使是今天，Shift/Caps Lock 组合键的精神依然活在你的 Mac 上。按下 F3 (Dashboard) 键，它的行为会因你是快速按下（然后再按一次返回），还是长按（在这种情况下，松开按键即可恢复原状）而有所不同。

显示桌面：点按与长按的对比

点按与长按的触发阈值

100

计时器延迟

模式

后一种准模式（quasimode）对于那些手指想要动得稍微快一点的人来说，是另一种贴心的设计。这与你遇到的大多数菜单是一样的：你可以点击打开一个菜单，然后再点击相关的选项，或者你可以点击并拖动，以稍微快一点、更流畅的方式选中某个选项。

菜单点按

菜单已激活

菜单拖动

菜单已激活

拖动

这甚至适用于 iOS 菜单，用你的手指就能操作。它甚至也适用于 iOS 键盘，你可以用手指在按键上滑动，而不必一个个地敲击它们。

当缓慢的按键变成快速的手势时，这能创造出神奇的效果。但你也必须小心。

肌肉记忆的无情与美妙

我在机场经历过的最紧张的时刻之一，与坐飞机毫无关系。

我正准备登上一架跨大西洋的航班。我抓起电脑，心不在焉地输入了密码——结果我所有的窗口并没有弹出，反而看到密码窗口左右摇晃并停在原地。

这是 NeXT 的一项惯例，确实一直延续到了今天。

我没当回事。肯定是我哪个手指滑了一下。我再次输入了密码，却看到了同样令人失望的反应。

到了第三次，我有点慌了。上文提到的“下意识地”这个词正是症结所在。感觉密码似乎只存在于指尖，要把它们从指尖提取出来通常只会惹麻烦。有多少次别人问你某个密码或常用快捷键，你就是说不出来？分享它的唯一方法是……真的盯着自己的手指把它敲出来，仿佛那是别人的手一样。

我开始刻意地去重新输入密码，尽管我心里清楚，刻意只会让事情变得更糟。（跳舞、滑雪，甚至走楼梯，都得益于我们不去刻意思考动作本身；一旦开始思考，我们就会慢下来并犯错。）这招没用。除此之外，还有一颗定时炸弹：计算机无法分辨到底是某人真的忘记了密码，还是某人正通过系统性地尝试常见密码来破解账户。因此，在某个时刻，我开始遇到系统为了防范第二类人而故意设置的延迟。现在，我必须等一分钟才能重试。然后是两分钟。接着是五分钟。

每多延迟一秒，我都会更拼命地回想密码。我真的改过密码吗？我的电脑出故障了吗？一想到在漫长的飞行过程中无所事事，我就感到十分煎熬。

直到那时，在这种令人抓狂的情况下煎熬了半个多小时后，我才注意到屏幕角落里的一个细节：不知为何，我的键盘被切换成了匈牙利语。我完全不知道这是怎么发生的。我按的按键一直都没错，但打出来的密码却是错的。

我将键盘布局改回英语，等待操作系统允许我再次尝试，然后紧张地——心里清楚一旦出错就要再等 15 分钟——用我重复过无数次的方式输入了密码。我成功登入了。

这不是一个关于健忘用户、刁钻电脑，或是可用性与安全性之间由来已久矛盾的故事。这是一个关于运动记忆（motor memory）力量的故事。

我们的大脑能够学习某些动作，从而自动且游刃有余地重复它们。这通常被称为“肌肉记忆”。

事实证明，密码和键盘快捷键确实存在于你的指尖。当然，这是一种比喻。大脑仍然在指挥，但这其实是大脑中一个独立的区域，遵循着另一套规则。常规的陈述性记忆与运动记忆之间存在着壁垒：这就是为什么当你把密码输入得足够熟练、甚至完全不用思考时，你却很难反过来询问你的手指密码到底是什么。

呵。

运动记忆这种“完全不用思考”的特性，让你能够完成许多奇妙的事情，比如边思考边打字、边和人聊天边打字、边看电视边打字，或是本能地用鼠标拖拽东西等等。运动记忆非常强大，它能陪伴你很多年。不对，应该是几十年。

“快捷键”这个名字起得非常贴切：它们能让你跳过大脑的某些处理环节，减轻其负担，从而让大脑可以专注于更重要的事情。

但是，软件必须尊重运动记忆。在某些时候，我的 Mac 本应该提示我，我的键盘语言可能与最初设置密码时的语言不同，就像现代操作系统会警告你可能开启了 Caps Lock 一样。

尽管后者同样可能对潜在的黑客起到提示作用。

所以，运动记忆确实有着自己的生命力，有时甚至让人觉得相当危险。但是，当硬件和软件都能理解它的微妙之处与强大力量时，一些美妙的时刻就会发生。

以另一个来之不易的发明为例：撤销。在早期计算机中，连一个16字符的键盘缓冲区都是一笔巨大的开销，很难想象把内存花在保存操作历史以便随时回溯上。在最初的几十年里，撤销功能根本不存在，多级撤销直到1990年代末才开始出现。计算机等待撤销功能的时间，几乎和打字机等待一个能从纸上抹去字母的退格键一样漫长。

就像退格键一样，我们把撤销及其带来的实验安全感视为理所当然。而撤销功能秘密力量的一部分，在于它出色的快捷键。⌘CtrlZ 中的"Z"在助记上其实没有什么含义，它只是一个有趣且快速的组合按键。但这很重要。易于按下意味着它能更快地印入肌肉记忆，意味着你会开始习惯性地使用它，意味着你在电脑上做以前可能不敢做的事情时会感到更安全。

这是一个良性循环。

将肌肉记忆与按键重叠以及界面在繁忙时仍能可靠响应结合起来，⌘CtrlZ 就不仅仅是一个巧妙的按键组合了。在某种意义上，它变成了某种……更少的东西。某种你的手指无需意识参与就能自动完成的事情。它让手指成为你的第二大脑，拥有自己的生命。

我最喜欢的设计交互的例子，是那些能清楚看出人们学到了所有这些经验并将其运用得当的案例。

可以是简单的事情。⌘CtrlG 查找下一个就紧挨着常规的 ⌘CtrlF 查找，这样你就能非常快速地浏览文件：

另一个类似的例子是将剪切/复制/粘贴放在相邻位置，或者在 Mac 上将 ⌘Tab（切换应用）与 ⌘`（切换应用内的窗口）放在一起。

查找与查找下一个

防抖延迟

有些键盘甚至改进了 Shift 的交互方式。仔细想想，Shift 仍然有些低效——你必须按照特定的顺序按键，Shift 要先于字母键按下。但如果你能同时按下它们呢？这很棘手，因为这意味着任何一个键都可能先到。虽然打字机的机械世界只允许一种特定的顺序，但计算机可以像我们的手指一样灵活地"弯曲"时间。

在1980年代，一些日本工程师尝试了这种做法。他们修改了键盘的软件，使其无论先收到 Shift 还是字符键都能开始处理，然后等待极短的时间让另一个键到达，最后将它们（经过防抖处理后！）组合在一起。这样你既可以像以前一样使用 Shift，也可以在按下字符键的同时快速按下 Shift——即使稍有延迟也能正常工作。

实际上我认为许多拇指 Shift 键盘强制你使用新的交互方式，不支持传统方式，但下面的交互演示区支持两种方式。

这是软件的魔法，但硬件中也有一些魔法——这种键盘将拇指 Shift 键放在了空格键通常所在的位置，其创造者深知拇指的利用率有多低。久而久之，它被称为"拇指 Shift 键盘"：

拇指 Shift

你好

阈值（之前和之后）

100

之前计时器

100

之后计时器

Mac Finder 的设计者们也曾花时间思考这个问题。在 Finder 中，你可以按下空格键来快速预览任何项目。空格键是完成此操作的完美按键。在这种情况下，它是空闲的。它足够大。而且它是唯一一个奢侈到可以分配给两根手指按键的键。

在日本除外。

预览功能的工作方式也类似于上面提到的 dashboard 技巧。你可以连按两次空格键，或者按住再松开。它也很乐观：如果你预览的内容渲染较慢，或者位于远程网络上，窗口依然会迅速弹出。

再一次，使用几次后，这种组合操作就不再像是有意识地选择按下特定按键，而开始变得更像是……瞥一眼。

弹簧式空格预览

点击与按住的阈值

100

随后的定时器

模式

最后一个例子是 Twitter，在所有产品中，它因普及灵活的输入框而值得被称赞。

理论上，这里看不到什么巧妙的键盘交互。输入框被限制为 140 个字符，因此一种自然的做法是在 140 处设置硬性截断。

但在逼近 140 个字符的过程中，你可能会打出更长的草稿，你的手指会本能地捕捉词语，编辑它们，或者不假思索地移动它们。为了允许这种操作，输入框实际上并没有被限制在 140 个字符以内。你可以随心所欲地输入——只是在你将字符数控制在限制内之前，不允许发布。

带字符限制的输入

输入受限

更智能的字符限制

提交失败

真实的与虚假的错误

上面提到的输入框问题可能看起来像是一个失误：当时看到“150/140”感觉就像是个 bug。这很典型。懂手指的精细微调界面会做出一些看起来像错误的行为，但这些设计的存在正是为了防止你犯错。

我最喜欢的例子可能是这样的：页面刚加载完时，Chrome 会将合并的重新加载/停止按钮禁用零点几秒。这是一个在高流量区域中经过深思熟虑的交互，它源于这样一种认知：尽管“眼疾手快”在生理学上并不准确，但先通过视觉再通过认知处理正在发生的事情所需的微小时间，可能足以让你点错东西：你开始将鼠标移向卡顿页面的停止按钮以强制重新加载，而页面恰好在移动过程中加载完成，结果你不小心重新加载了刚刚加载好的页面。

短暂禁用该按钮可以防止这种情况发生。

浏览器重新加载按钮禁用

临时阻止重新加载

延迟标签页重排

标签页拖拽死区

另一个例子：优秀的界面不会因为你只是轻轻擦碰就移动窗口，它们理解在心流之中，快速的点击实际上可能会变成非常微小的拖拽。死区（dead zone）的概念——即光标周围几个像素的隐藏区域——源自飞机的飞行摇杆，这种摇杆需要施加更大的力才能脱离绝对中心。

设备（如摇杆）或屏幕对象中心周围的一个小区域，在此区域内不允许移动。这样做是为了防止静止位置时的意外微小移动，并补偿控制器的漂移。

同样，在死区内的微小拖动仍会被判定为点击。一旦你仔细观察，这可能也会让人觉得像个 bug……

死区

死区阈值

死区

重置

……但事实并非如此。（这也使得双击的精准度要求可以稍微降低——只要两次点击发生在死区内，就可以被判定为双击。）

另一个例子：优秀的界面能够理解，手指手势是在一个独立的层面上操作的，有时可能会忽略它下方的内容。在某些浏览器中，你可以从 × 按钮处开始拖动标签页，此时该按钮对手指来说是透明的。从逻辑上讲，这说不通。但这符合“手指逻辑”。

时至今日，iOS 上的 Google 地图和 Apple 地图都还没有意识到，有时你会在手指按住某个按钮时开始平移，而这种平移手势需要被传递给它背后的画布。

从关闭按钮处拖动标签页

拖动时忽略关闭按钮

标签页拖动死区

优秀的界面理解快速移动手指可能会产生误操作，因此允许你在拖动之前或之后按下修饰键。

（在现代软件史上，我经历过最糟糕的机械操作体验之一，就是我在 After Effects 中制作一部长片时，不小心改变了一堆元素的尺寸，而且几天后才意识到。此时“撤销”早已无济于事，我也不能直接恢复到旧版本文件，因为我还做了其他修改。唯一比重做你的工作更糟糕的，就是重做那些你已经记不清细节的工作。）

在按住之前/之后使用修饰键

拖动前

拖动后

允许轴锁定

轴锁定已激活

重置

优秀的界面明白，Backspace 和撤销（undo）还有一个盟友：经典的 Esc 键。这个键应该是软件的“紧急停止”按钮——随时可用，助你摆脱困境。

在困惑、沮丧，或者……老实说，在日常的创作过程中，用左手猛敲 Esc 键是一件强大却被低估的操作。这不仅仅是因为 Esc 键比点击关闭按钮或取消按钮要快得多。而是因为，就像我们在这里讨论的许多事情一样，它可以成为一种下意识的习惯动作。然而，只有当你创造了一个能让这种手势稳定、可靠地发挥作用的环境时，这一切才会发生。

许多人钟爱 Model M 键盘，因为它那清脆的段落声，以及它确立了现代方向键的布局。我喜欢它给 Esc 键留了一座独立的小岛，这再次体现了对 Fitts 定律的理解。

我最喜欢的一个类似设计，出现在一台被遗忘的机器上——Canon Cat。

Canon Cat 拥有一个精简的搜索界面，它使用了两个独特的 Leap 键，其位置正好是 Fujitsu 放置 Thumb Shift 键的地方。按住 Leap 键并打字，就像开启了加强版的 ⌘CtrlF——光标会立即跳转到第一个匹配的词组，无需任何额外的按键。但如果你打错字了，或者更糟的是，你改变主意了怎么办？

Canon Cat 的创造者 Jef Raskin 想到了一个古怪却令人满意的解决方案。与其猛敲 Esc 键（Cat 并没有这个键），你不如直接胡乱猛敲键盘上的按键。这几乎肯定会生成一串在你文档中不存在的按键序列，从而使光标迅速跳回它最初的位置：

Canon Cat 与 Leap 功能

Leap 激活中

Leap 失败

Cat 没有锁定你的按键，也没有弹出需要你处理再确认的错误对话框。在追求高效手指操作的同时，它没有忘记：犯错也需要以手指的速度发生。

全部手指或一个不用

我没有赶上 Canon Cat 短暂的存在，也错过了这个故事中许多更早的时刻。但我记得自己亲眼见证了 2007 年那场革命的发生。

1984 年 Mac 诞生时，人们的注意力大量集中在它的鼠标上，反而忽略了同样有趣的键盘。iPhone 发布时情况恰好反转——所有人都在谈论键盘。任何关于 iPhone 上相当于鼠标操作的评论，都只限于赞叹"滑动解锁"，或庆祝双指缩放。

我的工作就是为这类交互提出改进建议，但在这里我想不出任何需要改进的地方。那种感觉当时如此，现在依然如此——在某种意义上，它是一种近乎超自然的体验，仿佛真正超越了自然本身。

它发布时就已极为出色，第一次让横向滚动变得切实可用，日后更成为更多精良交互的基础：先是下拉刷新，最终演变为手势替代 Home 键。此后的数十年间，我为所有 Android 用户感到遗憾——他们被专利护城河挡在了这套机制之外。

我很欣赏 Apple 团队在无法精确显示滚动内容时加入棋盘格背景的做法（这与数十年前 Mac 处理窗口缩放的技巧如出一辙），据说竞争对手还用高速摄像机录下这些交互，以确认它们确实以恒定的 60fps 运行。

但我对它的热爱在几年后才达到顶峰。当时我在一个原型项目中，加入了一段 JavaScript 代码，想在页面滚动时执行一些操作……结果有一半代码根本没有执行。我花了好几个小时才弄明白发生了什么，因为发生的事情本不该发生：iOS 在函数执行到一半时停掉了我的代码，只为回去确保滚动尽可能流畅。没有任何现代编程语言敢在你的函数执行到一半时打断它；iOS 对用户手指的执着，让它打破了编程的基本契约。

但 iPhone 的滚动并非凭空出现。它的惯性物理效果在几代 iPod 点击式转盘上已经反复演练过。还有一个我本人此前用过、却未意识到其革命性的核心基础构件：2005 年在 PowerBook 上引入的双指滚动。它的手感好到令人震撼——这东西直觉到你几乎觉得它在出现之前你就已经在这么做了！

从某种意义上说，这比 iPhone 的滚动更难实现，因为触控板已经有十多年的单指操作（即移动指针）历史。添加双指平移的人必须确保在这两种模式之间轻松切换，不出任何问题。

这些过渡如果做得不好会显得笨拙，做得好又往往不易被察觉。但当你的手指想要快速操作时，它们却至关重要。

举个例子：你正在屏幕上拖动某个元素，却发现快没空间了。你需要的空间其实就在那里，但必须通过滚动才能到达。在过去，你必须放下该元素，拖动滚动条腾出空间，然后再重新抓起该元素。或者，你可以抓着该元素并将其移动到边缘附近以触发自动滚动，这听起来很实用，如果不是因为一个致命缺陷的话： 在人机交互的历史上，从来没有人把这部分做好过。

仅使用滚动条拖动

边缘滚动

在如今的触控板上，你只需抓住该元素，在按住不放的同时，用两根手指四处移动：

拖动时平移

我们之前谈到的那个显示仪表盘/桌面的操作，带有流畅的按键按下与松开的瞬间体验？你可以在此基础上进行构建：在按住某个元素的同时显示或隐藏桌面，通过一个流畅的动作将元素从一个地方移动到另一个地方。

拖动时显示桌面

点按与长按阈值

100

计时器延迟

模式

在经过深思熟虑的界面中，到处都有这样的例子。

还记得 ⌘Tab 的那些微妙细节吗？这种交互的伟大之处在于，它不仅局限于键盘。你可以用左手调用它，同时右手立刻介入并指向你想要激活的应用。这是 Shift 键在全新交互领域中的经验应用。

在应用切换器中使用鼠标

阈值

显示前的长按时间

（像 Shift 和 ⌘ 这样的左手修饰键之所以出现在如此多的交互中，原因与 Doug Engelbart 在 1968 年将按键设置在键盘左侧、将鼠标放在右侧的原因相同。它结合了双手的力量，就像 20 世纪 80 年代的警匪搭档喜剧一样，给其中一只手分配了“粗略定位”的任务，给另一只手分配了“精确点击”的任务。）

这对左撇子来说也更困难，尽管一些左撇子告诉我，他们仍然选择用右手操作鼠标或触控板。

另一个例子：还记得 Finder 巧妙利用空格键进行预览吗？你可以在此基础上构建：一只手按住空格键，另一只手按下方向键以快速预览更多文件——并且吸取我们之前的经验教训，花哨的预览过渡效果将会被暂停。

预览时使用按键

点按与长按阈值

100

计时器延迟

模式

它的另一个版本扩展了前面提到的“弹簧加载”功能。如果你试图将一个图标拖动到一个你忘记打开的嵌套文件夹中，你只需将图标悬停在该文件夹上一两秒钟，它就会为你自动打开，而无需你放下该图标（并伴有一系列闪烁效果，提示你快完成了）。你可以继续这样深入多层目录。额外的好处是？将图标放到你想要的位置后，那些自动打开的文件夹就会为你自动关闭。

不仅如此，还有更好的体验。如果你对弹出新窗口前还要等那么一小会儿感到心烦，你可以用最亲切的按键来加速——你猜对了，空格键。（当然，你随时也可以按下 Esc 键，放弃这整个摇摇欲坠的操作。）

弹簧加载

弹簧加载延迟

弹簧加载前

构建允许人们以这种方式组合事物的界面，才是真正让人能够精通的关键，也是值得赞赏的地方。

就像在现实生活中，一扇能让你在双手提满日用品时依然可以打开的门，也是值得赞赏的。

极其重要的细节

我放弃使用 Gmail 的经历则与此截然相反。

每天我都会遇到好几次这样的情况：我用触控板点击“回复”，看着回复编辑器如期打开。我的手指从触控板移到键盘上准备打字，但令人沮丧的是，Gmail 的界面此时却将这一新动作误解为我把鼠标移到了收件人的名字上，进而弹出一个显示对方所有信息的悬浮卡。

那个悬浮卡不仅烦人、让人分心——这本身就已经是个小毛病了——它还恰好挡住了我正准备开始打字的区域。每！一！次！

这下好了，我不得不把手指移回鼠标去把悬浮卡赶走。我可能每天都要做二十几次，一周七天，一年五十二周，日复一日，年复一年。如果每次发生这种事我都能得到一枚五分镍币，我大概早就得铜中毒了。

为什么这如此令人恼火？原因正是我们学到的那一点：你无法与肌肉记忆妥协。在其他任何地方，按钮都能正常工作，而且操作系统在我开始打字后会贴心地隐藏鼠标指针，因为它知道指针可能会挡路。多年的练习让这成为了一种在任何地方都可靠的肌肉动作。除了在 Gmail 里。

这是一个不懂手指动作的界面，而且它出自可以说是谷歌最顶尖的生产力应用。这个界面根本不明白“最后的交互模态优先”的原则，也不明白在键盘事件之后不应该再触发鼠标操作，除非鼠标再次开始移动。在我们弄清楚这个道理 30 年后，它还在犯这种错误，这是不可原谅的。而它今天依然如故（我刚刚确认过），则更加糟糕。

我以前很反感那些关于“小处见大”的细节博客，因为最糟糕的是，它们展示的那些东西看似讨喜，实际上却妨碍了产品的良好使用：比如你必须等它播放完的转场动画；比如分散你注意力的边缘动画；又比如在紧张或慌乱时刻反而让人困惑的可爱文案。

有时候人们说，真正的自信就是没有那种表面上的自信。我们在口语中常把自信狭隘地理解为某种大男子主义：从不认错、“坚强沉默的类型”等等。但真正的自信是一种更深层的力量：展现脆弱、保持可靠、承认错误。

同样地，我经常认为，真正的愉悦感往往体现在不做画蛇添足的事。在欢迎快速操作的界面和应用中，愉悦感可能就是克制住不加转场动画，或者那些华而不实甚至致命的可爱小设计。追求恰到好处的愉悦感，可能意味着要与框架进行长期的斗争，只为减少哪怕一帧的延迟；微调 CSS 确保图标之间没有浪费的像素（让你能毫不犹豫地快速点击）；对无障碍设计有超越表面的深刻理解；以及不断测试和微调，让键盘焦点保持连贯：始终停留在正确的位置，绝不延迟，也绝不被随机的弹窗夺走。

而且我不确定我们业内是否已经充分内化了这一点。

我们更善于评判实体工具——比如一把头重脚轻的锤子、一扇嘎吱作响的门，或者一个软绵绵的游戏手柄按键。专业的相机评测会花时间讨论操控手感，因为他们深知你的手指每天都要使用它们好几个小时。机械键盘制造商对材料科学和润滑工艺的痴迷，也是出于同样的原因。

但在屏幕界面设计上，我却没有看到同样的标准。提交界面 Bug 让人感到沮丧，而且即使提交了，也往往被降级为“锦上添花”或是“后续快速跟进”，如果运气好的话，可能会被算作“未来可能的小优化”。我们对 Apple 硬件和软件的评价标准截然不同。只有在情况真的非常糟糕时，我们才会反抗。

我在乎这些细节，因为孤立地看，它们似乎微不足道，但日积月累，就会让你在使用那些不断违抗你意愿、让你倍感挫败的设备时，过上令人沮丧的生活。它们就像是城市中的噪音。管道里的铅。闪烁的荧光灯。

我刚才提到了 Gmail。我没法用 Notion，因为它的选择机制无视了我从其他所有应用中积累下来的肌肉记忆。我给了 Apple 很多赞誉，但它近年来的 Finder 却失去了曾经拥有的那种键盘操作的流畅感，深陷令人沮丧的焦点问题和半吊子的转场动画之中。而且我的 Mac 上的 Notes 已经跟不上我的打字速度了，而这台机器搭载的处理器如此强大，Apple 完全可以重拾当年那则经典的军火广告了。

跟不上打字速度也许是所有问题中最不可原谅的，因为这也是我们整篇文章探讨的起点。我们在一个世纪前就已经弄清楚了这些问题。我们了解“转录流畅度”——这个概念是指，当打字速度超过每分钟 30 个单词左右时，打字就不再是一种有意识的活动，而是变成了手指自发的动作，因为你的大脑正在思考更重要的事情。我们也了解“心流”，它将这一概念延伸到了每一次交互之中。

我给这篇文章起了一个对我来说略显做作的标题。这是为了向 August Dvorak 致敬，他在 1936 年出版的《Typewriting Behavior》一书中使用了这个短语。

Dvorak 是一个备受争议的人物，他的方法也受到质疑。然而，这本书读起来依然引人入胜，它试图将手指那些复杂而令人惊叹的动作与真正重要的事物联系起来。

我觉得 Dvorak 会欣赏我在 Mac 上每天使用多次的双手操作法：你可以抓取一个对象，把它拖到 Terminal 上，然后在按住它的同时，在里面输入内容！我觉得他也会欣赏 iPhone 上的上滑手势，这是交互设计的大师级示范：始终可靠，不仅允许缓慢和快速的滑动，还能识别介于两者之间的各种手势。

没错，Terminal 应用正是 20 世纪 60 年代终端机的直系后代！

它是如此好用，以至于成了现代版的 Esc 键——如果你在某个 App 里陷得太深，有时从屏幕底部边缘把它划走再重新打开，比按常规方式寻找返回主屏幕的路径还要容易。

这两者都巧妙地结合了时间控制、防抖、重叠交互、弹簧加载、死区以及乐观更新。它们都深谙手指的实际运作方式，并且只有当设备及其软件真正理解我们的手指及其能力与需求时，我们才能真正利用计算机去创造更美好的事物，而不是与机器较劲。

我很好奇你最喜欢的例子有哪些——请告诉我！

从手指的潜能让我们大为惊叹的早期打字时代，到我们摸索出本地回显和延迟等诸多基础知识的早期计算时代，我们一路走来学到了很多。即使技术不断变革，这些经验也将历久弥新，因为……毕竟，我们的手指是不变的。现代的 VR 设备、AI 产品与终端，以及电动汽车，都受益于这些经验教训。

这是一个略显高级的词汇，专指在技术语境中出现的延迟或卡顿。

我在上面写到的这些都是来之不易的发现。Dvorak 致力于优化打字体验，Lilian Gilbreth 致力于研究人机工程学及其社会意义，Doug Engelbart 致力于精通输入控制以带来全新洞察，Jef Raskin 则对前人的成果进行了深思熟虑的重塑。还有许多比我们所有人都要聪明（或至少更幸运）的无名之辈，帮我们弄清了其中的诸多奥秘。这些只是最基本的要求，我们应当严格自律，坚守这些底线。

无论你是做出这些决策的设计师，还是对预期体验心知肚明的用户，我都希望你能对双手心怀敬意，感谢它们赋予你的奇妙力量。

它们当之无愧。