亲爱的界面

杂谈

作者认为产品的工作应该"开发产品"，而不是开发解决方案。所以开发产品应该始终是在调研、设计与实现这三个组成环状的目标中螺旋前行。

做用户调研的目的是为了摸清自身、用户和市场之间的关系。设计则是依据方法创造出符合用户心智模型的可用、有反馈、有层次的界面。实现则是尽可能事实现模型和界面模型不干扰用户认知，并在产品完成后跟进测试，量化结果，完成产品开发流程的闭环。

调研

就像福特所谓的"如果问我的客户他们需要什么，他们会说要更快的马车"，尽管可以通过询问的方式从用户口中知道他们想要做什么，但这并不可靠，因为人们在情感预测的准确性上非常不灵验。此外，你比用户更专业，应该知道从用户口中说出来的只是功能而不是需求，往往需要再多追问几个为什么才能挖掘出真正的需求。此时你会意识到，问题是网状结构而非点状结构。

作者在书中推荐了"工作影子及情形访谈"这种用户调研方法。

工作影子，顾名思义，在某人工作的时候跟随在他身后，观察他是如何工作的。如果没有跟随条件，可以观看录屏，或者使用邮寄录像机等替代方案。情形访谈则是在工作影子之后根据他们的工作内容做具体提问，比方：

• 除了观察到的，他们还经常做哪些任务
• 需要经常解决什么问题（以及用到了哪些权宜之计）
• 经常和谁交流，如果交流的对象不在怎么办

所有的调研，都是为了要明确以下问题：

• 用户现在在做什么
• 有哪些是用户不想做却不得不做的
• 用户想做什么

设计

类似用户调研，设计前也有一些概念需要理清。

根据产品的不同，需要选择不同的设计导向。

说起来可能会让人觉得不可思议：某些时候，以用户为中心比以活动为中心更不适合作为设计导向。比方说，鼠标最广泛的功能时能点击，而不是切换 DPI。以活动为中心做设计，用户会自然适应你的设计。

如果你还是毫无头绪的话，可以从编写用户手册开始做设计，手册的形式多种多样，博客、案例、录屏或新闻稿都行。编写手册这能强迫你思考设计细节。好的手册是好产品的及格线。编写文档应该仔细，你要知道，当用户开始查看手册时，他们已经很恼火了。就算不从编写手册开始做设计，手册也是高优先级任务。

无论知识水平如何，人们总是变得越来越不愿意"阅读"。其实人们不是不喜欢通过阅读吸收知识，只是他们不愿意阅读内容啰嗦或晦涩难懂的内容。为了做到编写出易读的用户手册，你可以尝试去学习如何写作，或者至少，学习如何进行技术写作。这样，能保证你的文字功力在平均水平之上。

编写用户手册的同时，你可能会一边构想应用的界面。这时候的界面无需多花哨，只要层级结构正确就可以了。人们天生就有分层的抽象思维，层级结构正确是好产品的底限。

好比大多数人西方人天然就觉得从上到下、从左到右的是正确的层级结构，大多数人也会认为在浏览器中，由于标签页的关闭按钮靠近标签页、刷新按钮靠近地址栏，所以关闭按钮只对一个标签有效，刷新按钮对所有页面有效是对的。

最后，你需要对界面和内容做一些简单的可用性测试。

• 文字性的内容，如手册和文案，可以使用完形填空法
• 层级结构，可以使用卡片分类法

创建可用的层级结构

也许你在想我们讨论的层级结构是一个固定的分类方法，但是我们使用的实际上是层级与标签相结合的方法，所以在某些情况下，一个类目出现在不同层级中是情有可原的。

合理的层级结构 > 用户在层级结构中找到目标的点击次数，同时也不应该拘泥于“一次性仅提供七个以下的选项”，因为，人们扫视菜单时，喜欢选择第一个看起来像他们要找的目标的菜单。

关机相同层级下子项的分组，可以遵循亲密性的原则，也可以使用方向、大小、形状、颜色等其它属性作区分。

心智模型

心智模型是用户对当前产品的全部认知，是现实逻辑的简化版本。比方说，说到“油门”，人们的心智模型很可能是“踩下油门，油箱的门打开，发动机进入更多油，汽车得以加速”。

设计时应该以实际的心智模型为基础，创造出简单易懂、明确、有反馈的 UI 界面。UI 界面应该靠近心智模型而不是实现模型。

保持开放的心态

相比于汽车行业如今平稳发展的时代，软件行业目前属于给马车安上蒸汽机的黄金年代。我们应该保持开发的心态，迎接这种无限的可能，不断优化方案，解决问题，而不是陷入把蒸汽机安装到马车前面还是后面这种无意义的争论中。

不要非黑即白地做判断，不要过早的确认方案，也要避免陷入沉没成本，需要谨记的是，用户界面始终有无限可能。

写实主义

写实主义有助于帮助用户快速建立正确的心智模型，前提是界面和现实是一致的，你不应该指望给用户展示一本写实的书还要他使用“上一页”和“下一页”进行翻页操作。

微软的 Metro 设计语言开创了“扁平化”的设计潮流，消除了长期以来的一些不良设计隐喻，带来了许多积极的作用。不过还是那句话，应该保持开放心态，而不是固守规范。

自然用户界面（NUI）

NUI 是继 CLI、GUI 的衍生，主要依赖用户的摄像机、麦克风、手指、触控笔做交互。

要做出符合自然的用户界面，有以下几点可参考：

• 用户可以直接操作元素，同时系统对用户地操作要及时反馈。在此之上保留容错和撤销等逻辑。
• 不要逼迫用户学习精准和复杂的交互方式，那可能是 NUI 到 CLI 的一种演进的倒退。
• 参考其它主流应用，因为用户可能习惯了某种用户界面。

费茨法则

费茨法则非常简单，即在桌面系统中，元素越大、离鼠标越近，那么越容易被点击，由此引出了一个计算元素点击难易度的公式。同时，由于鼠标一般不会超出屏幕，所以处于屏幕边缘，尤其是拐角处的元素可用性是非常高的。

人们根据费茨法则，发明了点击上下文菜单和环形菜单这种交互方式。

动画

动画并不是仅仅为了华丽的外表，它应该被用来提示界面上状态的变化，辅助用户建立正确的心智模型。为此，我们可以参考卡通，学习把元素当作“固体”，适时做出形变、加速度、模糊等夸张的效果。

一致性

人们识别界面元素（类别）的能力很强，所以不用担心你把界面元素设计成了不同的样式。相比关兴界面样式的一致性问题，你更需要担心的是，如何确保“行为不同的元素，外观也不相同”。

可发现性

屏幕空间有限，所以不要期望把所有元素都塞进有限的屏幕中。你可以依据元素的重要性，给这些属性的优先级进行排序：

• 某些元素在某些阶段可以隐藏（如选中图片后才能展示旋转按钮）
• 利用动画及元素的空间属性如尺寸、颜色、形状等增强或弱化元素的优先级

不要打断用户

从打断中恢复是需要时间的，所以打断用户是一种不明智也鲁莽的操作。系统在可能的情况下可以替用户做出操作，除非没有选择，在需要做出重大决策时再询问用户的意见。当然，最好是能一次性问完。

使用撤销代替打断

我们几乎已经快被“您确定要...”这种弹窗烦死了，从这类弹窗中，几乎不能再得到有意义的警告。不过可以使用撤销和延迟决定这种策略减少这类弹窗的出现次数。当用户习惯后，我们的系统就能重新找回弹窗的警示作用。

模式

模式标记着应用程序进入某种特定的状态，用户界面发生了变化。合理使用模式可以减少用户界面的复杂度。

不过模式也经常出问题，如“隐式模式”，用户往往难以察觉程序进入了某种模式；“意外的模式”，界面某种元素可能偷取交互焦点；“粘性模式”，按某个按钮就会持续一段时间的模式，用户往往不知道应该怎么退出模式。

为了解决模式的问题，我们可以充分利用视动觉或是听觉提醒用户，或是采用“准模式”这种办法，只有在用户持续操作时，模式才持续存在。

避免使用首选项

首先得区分设置、配置、首选项、个性化这四个词的含义：

• 设置：用户对应用程序做出的全局性质的功能或配置上的修改
• 配置：应用程序运行所不能缺失的一些设置
• 个性化：仅仅是一些视觉变化
• 首选项：不影响应用程序运行的功能性改变

避免使用首选项是因为“你比用户更专业”。大部分情况下，你应该明白自己在创造什么产品，提用户做出决定。

层级结构

相比层级结构，我们通常更擅长使用时间和空间推理组织数据。

或者，你可以提供层级结构的优化方案，比如：减少或限制层级结构嵌套、支持在多处存放同一个文件、支持元信息编辑（打标签）、结合时间或空间推理或设置数据访问的备选方案（如搜索）。

速度

应用程序不能运行得太快（点币机），但肯定也不能太慢。如果你想让一个操作看起来“瞬间完成”，通常应该让它们在 0.1 秒内返回结果。

相比精确计时，我们更关心用户的感知速度，因为有许多小技巧可以减轻用户等待时的焦虑。

避免加入过多新功能

用户总是提一切奇怪的、可能只有他自己会用到的功能，这部分功能对其他用户来说几乎毫无益处。当然，这个得看你怎么看待用户了，比如有些公司就喜欢“如果能让一些用户季度热爱我们的产品，我们愿意失去一些用户”。

面对用户要求加入新功能时，可以尝试多问几个为什么，挖掘出需求背后的需求。这样你也许有机会通过优化现有功能、替换旧功能等方式达到完成需求的目的。

移除功能

人们总是厌恶损失，即便他们从未拥有（或使用）过某件东西，所以移除功能处理得不好的话，这会是一个很让用户沮丧的决定。如果你决定要移除一个功能，最好提供该功能的备选方案。你也可以尝试从用户数据中分析功能的使用情况以确定是否要移除一个功能。需要额外提及的是，使用率低并不意味着不重要，比如说手机搬家功能。

向电子游戏学习

根据心流理论，当满足以下三个条件时，人们会感到愉悦：

1.  面临有意义的挑战
2.  有方法估测是否离完成挑战越来越近
3.  具备完成挑战的能力

在某些方面，产品可以像游戏一样，提供合理的反馈，以向用户展示进度；提供不同层次的深度，或徽章、成就等内容，以鼓励用户探索新内容（需要警惕过度辩护效应）。但和游戏不同的是，你不需要为用户提供任务和挑战，因为往往他们使用应用就是为了处理任务，如果技能熟练的话，他们会尝试去处理更高级的任务。

后端设计

后端是对人们在电子世界中对所认知事物的一种数字实现，前端则尝试用数字实现复现该认知体验，UI 是前端和后端的桥梁，站在用户的角度设计出容易被理解的界面。

通常来说，后端设计的数据结构会对前端造成重大影响，而且并不是所有诡异的逻辑都能在后端被隐藏，所以 UI 设计师参与到后端设计中来是有必要的，这能让实现模型和用户的心智模型保持一致。

UI 设计师可以尝试学习数据库设计，以理解开发是如何完成需求的。比方说在球队管理系统，教练可以创建球队，增加球员，联络其他球队进行比赛以排名，这个需求的心智模型是非常简单的。但如果球员同时效力多个球队，球员可能被调换到其他队伍，此时历史球队得分以及比赛信息要如何处理？可以看到，这个需求的实现模型是要比心智模型复杂得多的。

用户错误即设计错误

当用户没有按预期操作软件而出发错误时，设计师与其撇清责任，不如修复问题。请勿责备用户；最好是能解释出错的原因，并提供可能的解决方式。

当然，最好的做法还是避免问题的出现，比方说减少模式或优化模式的使用以避免模式错误、提示或阻止非法输入以避免输入错误。

不好的地方

前言差点把我劝退。

前言，理念类章节小节，作者尝试使用论文《强制实施自行车头盔法案对健康的影响》中描述的现象：自行车头盔法案强制实施后讨厌带头盔的人可能会选择其他交通方式，以举证“设计的改版经常并未如你所愿，有时甚至与你的预期完全相反”。这本身没错，但他的解释太糟糕了，原文引用如下：“这些法案是避免了一些伤害，但是对于那些完全放弃使用自行车（取而代之开汽车）的人来说，他们所遭受的健康影响全然是负面的。” 啥，健康影响还能是负面的？难倒开汽车会比骑自行车安全么？我 Get 不到。