Informatics 43 — 第六周课程笔记

涵盖 Lecture 11 与 Lecture 12："如何让软件真正满足用户的需求？（第 1、2 部分）"

目录

1. 从设计走向用户 — Lecture 11 的起点
2. 为什么可用性重要
3. 以用户为中心设计的商业理由
4. 可用性失败案例 — 一组教训陈列
5. 三句值得背下来的名言
6. 可用性工程为什么这么难
7. UX 设计师这一职位的兴起
8. 八种以用户为中心的设计方法（Lecture 12）
9. 方法 1：访谈与观察
10. 方法 2：人物画像（Personas）
11. 方法 3：场景（Scenarios）
12. 方法 4：故事板（Storyboards）
13. 方法 5：线框图与原型（Wireframes & Mockups）
14. 方法 6：设计准则（Design Guidelines）
15. 方法 7：启发式评估（Nielsen）
16. 方法 8：用户测试
17. Quiz 6 复习要点
18. 总结与记忆框架

1. 从设计走向用户 — Lecture 11 的起点

第五周以设计原则收尾 —— 高内聚、低耦合、信息隐藏 —— 并提出更宏观的论断：软件工程是构建一组相关模型来表示待建系统的过程。这些模型刻画系统的结构、行为、交互和非功能属性。

第六周补上缺失的一块：一个系统可以被切分得无懈可击、解耦得漂亮、架构上无瑕疵，却仍然不可用。所以本周的问题从"系统是怎么构造的？"再退一步，变成：

至此，我们正在搭建的演进顺序是：

Lecture 11 解释为什么面向用户（可用性）很重要；Lecture 12 走过八种以用户为中心的设计方法，本季度后续课程都会建立在它们之上。

2. 为什么可用性重要

讲座一开篇有意混搭了一组图 —— MRI 机器、电厂控制墙、客机驾驶舱 —— 想说明一件事：可用性不是叠加在重要软件之上的"锦上添花"，而是嵌入在使用该软件的后果之中。驾驶舱面板上一个被读错的开关、MRI 控制台上一个看不明白的按钮，都不是"UI 小问题"，而是安全事件。

Obama '08 竞选的例子在低得多的语境下重申了同一个论点。竞选团队 A/B 测试了两个版本的主页，它们在两个维度上不同 —— 主图（Obama 单人肖像 vs 一家人合影）和 CTA 按钮（SIGN UP vs LEARN MORE）。家庭照 + LEARN MORE 那个版本把注册转化提升了大约 40%，竞选方后来估计这相当于多带来约 6000 万美元的捐款。生死攸关的系统里成立的逻辑，在营销里同样成立：界面的视觉和措辞共同改变了用户行为。

真正的要点不是"可用性是为了把按钮做好看"，而是用户的行为本身就是系统的一部分。不考虑这部分行为去做设计，等于只设计了系统的一半。

3. 以用户为中心设计的商业理由

讲座列出了把以用户为中心设计（UCD）做对的五项回报：

Lecture 11 末尾的总结幻灯片把这张清单压缩成四个要点 —— 销量上升、性能提升、流量增加、挫败感下降，配上那句口号："It's all about the user."

幻灯片还埋了一个更微妙的点：

UCD 的收益会随时间从转化（首次客户）转向忠诚度（回头客）。早期，好 UX 帮你赢得用户；后期，好 UX 帮你留住用户。

但即便如此，这些方法常常不被使用。Lecture 11 的剩余部分就在展示不用它们时会发生什么。

4. 可用性失败案例 — 一组教训陈列

Lecture 11 列出了一系列真实世界中的可用性失败。它们都很搞笑，但每一个都对应着 Lecture 12 中的一条 Nielsen 启发法。

其中几个值得"看一下"而不仅是"读一下" —— 这些搞笑的图把启发法违规演绎得比任何文字都清楚。

接下来是对比页：

要点是：第一印象很重要。同一个任务（让用户开始使用产品），在 Apple 上是一个按钮，在 Google 上是一个搜索框，在典型的企业应用上却是一墙看不懂的缩写。用户在几秒钟内就会决定这个产品值不值得学。

5. 三句值得背下来的名言

讲座引用了三句对"好 UI"的定义，它们捕捉到了整个第六周的精神：

"A user interface is well-designed when the program behaves exactly how the user thought it would."
（界面设计得好，是当程序的行为完全符合用户的预期。）
— Joel on Software

"A GUI should provide GUIdance!"
（GUI 应当提供"指引（GUIdance）"。）
— hallofshame.gp.co.at

"Focus on the user, and all else will follow."
（专注于用户，其他一切自然会跟来。）
— Google

第一句是可操作的定义：可用性 = 用户心智模型与程序行为之间的匹配。第二句是设计指令：界面应该主动引导用户完成任务。第三句是战略原则：把用户摆在第一位，其他指标（销售、效率、留存）会自然跟上。

6. 可用性工程为什么这么难

如果 UCD 的回报这么明显、方法又简单又便宜，为什么好用的产品仍然稀少？Lecture 11 给出两条理由：

6.1 可用性涉及 CS 之外的多门学科

传统的 CS 课程基本不训练这些。软件工程师被训练得擅长推理正确性和性能，但不擅长推理色彩对比或工作记忆容量。

6.2 受众错位的问题

工程师对"什么是显然的"那种直觉，是对工程师校准过的，不是对真实用户 —— 会计、医生、司机、小学生、退休老人。要为一个并不像你的用户做出好设计，必须用刻意的方法来跨越这道鸿沟。Lecture 12 的八种方法正是干这个的。

7. UX 设计师这一职位的兴起

正因为可用性涉及那么多 CS 之外的领域，一个独立的角色就被分化出来了：

UX 设计师处在艺术、社会科学、工程的交叉口。软件工程师不需要成为 UX 设计师，但需要和他们合作，并且在小项目里自己运用基本的 UCD 方法。

8. 八种以用户为中心的设计方法（Lecture 12）

Lecture 12 引入八种以用户为中心的设计方法，本单元后续课程会一种一种讲。这张清单需要背下来 —— 复习指南明确写了"the 8 user-centered design methods"。

这些方法大致沿着理解用户 → 描述用户 → 画出系统 → 评估设计的路径推进。它们并非严格顺序 —— 大多数项目会在多个方法之间循环往返，随设计成熟而多次回访。

9. 方法 1：访谈与观察

第一种方法也是最基础的：去找真实用户、跟他们说话、看他们做事。讲座里的图把这点说得很直白 —— 驾驶舱里的飞行员、塔台里的空管员、多屏工作台前的分析师、运营中心里的调度员。每种环境都有自己的约束（光线、噪声、时间压力、多任务），坐在办公桌前是猜不出来的。

两者互补。访谈捕捉用户的意图和挫败感；观察捕捉到用户已经习惯到忘记自己有的那些变通办法和习惯。

10. 方法 2：人物画像（Personas）

Persona 是一个虚构但具体的用户原型 —— 由访谈/观察数据构造而来 —— 设计团队在整个项目里都可以引用它（"Blake 会这么做吗？"）。

10.1 一份 persona 包含什么

MyFlix 例子（Blake、Carrie）和 OpenMoko 例子（John "The Greenhorn"、Emily "The Casual User"、Akiko "The Texter"、Stephan "The Business User"、Roberto "The Power User"、Ricky "The Hacker"）都共享一致的结构：

10.2 为什么 persona 有效

一份"用户需求清单"是抽象的；一份 persona 是具体的。当设计师问"Blake（27 岁、程序员、科幻迷、和朋友一起看电视）真的会点这个按钮吗？"时，答案比"用户会点这个按钮吗？"要锐利得多。Persona 让用户具体到可以与之争论。

10.3 Persona 是成组出现的

真实系统有多种用户类型。比如 MyFlix 项目区分：

• Blake —— 内容消费者（顾客）
• Carrie —— 一家电影制片厂的应用管理员（后台用户）

一份完整的 persona 集合涵盖每一种有意义不同的用户角色。OpenMoko 的集合更进一步，用六个 persona 覆盖从"完全非技术的（Greenhorn）"到"深度技术的（Hacker）"的全频谱，这样任何设计决策都不会意外只优化某一片受众。

11. 方法 3：场景（Scenarios）

Scenario（场景）是一段简短的叙事，描述某个具体 persona 在用系统达成某个具体目标。它用平实的语言、第三人称、现在时讲故事的语气来写。

11.1 两个 MyFlix 场景示例

场景 1：加入 MyFlix

Blake 在网上搜索本地是否有影院在放一部新上映的独立电影时，发现这部电影的简介页同时也在 MyFlix 上有发布。他兴奋于可以在自家公寓舒服地看这部片以及类似的电影，于是注册账号并开始按月付费。他通过电视上的浏览器登录账号，成功流式观看影片。

场景 2：发现内容

Blake 对电影和电视剧的口味相当具体。在公司他会在 MyFlix 网站上浏览各种分类，并阅读自己感兴趣分类下的影评。读到几条匹配他偏好的简介与推荐后，他把这些片子加进越来越长的待看列表里，方便以后快速挑一部来看。

11.2 Scenario 起到的作用

Scenario 就是 persona + 目标 + 上下文，写成故事。它是从"用户是谁"（persona）到"我们需要构建什么"（原型、需求）的桥梁。每个 persona 通常有多个 scenario，每个对应一个主要目标。

12. 方法 4：故事板（Storyboards）

Storyboard 是 scenario 的视觉版本 —— 一连串连环画式的格子，每一格展示用户体验中的一个时刻，常常配手写说明文字、对话气泡和心理气泡。

12.1 一个 storyboard 格子通常包含什么

12.2 B&Q 购物示例

讲座展示了一个八格的 storyboard：Sarah 在 B&Q 五金店使用一个画笔造型的结账系统 —— 她进店刷卡，设备喊出她的名字，她扫描一桶涂料，得到一条"你可能也会喜欢……"的推荐，去找画笔，向店员求助，得到真人帮助，然后离店 —— 购物加上帮助这么多事，这趟逛得真成功！ 每一格在叙事里加上一拍。

12.3 为什么 storyboard 比纯文本更强

Scenario 用语言捕捉目标，storyboard 则用图画捕捉情绪、环境和时序。第三格里一个挫败的心理气泡（"我确实需要一支画笔，到底在哪里能找到呢……"）传达可用性问题的力度，比一段文字描述要鲜活得多。Storyboard 也强迫设计师去想物理情境 —— 用户站在哪里、手里拿着什么、周围有谁。

Storyboard 故意要画得粗糙、像手稿。把它打磨得很精致是浪费 —— 它的目的是激发关于体验的讨论，而不是好看。

13. 方法 5：线框图与原型（Wireframes & Mockups）

线框图（wireframe）或原型（mockup）是产品某个真实屏幕的低保真草图 —— 包括布局、控件、标签、导航 —— 但不承诺最终的颜色、字体或图片。

13.1 保真度光谱

13.2 MyFlix Zombie Romance 线框图

讲座的例子是 MyFlix 上 "Zombie Romance" 这部电影的详情页：

• 顶部一个浏览器外壳框（后退 / 前进 / 停止 / 主页 / 地址栏）
• 站点头部：左边 MyFlix | Categories | …，中间一个搜索框，右边 Signup - Login
• 左侧导航：Browse Movies、Read Reviews、Sign Up
• 面包屑：Home > Horror > New Releases > Zombie Romance
• 电影标题、上映年份、剧情简介、Cast and Crew 链接
• 一个 Sign Up to Watch 的 CTA 按钮
• 一行 "Similar Movies On MyFlix"，里面三个占位缩略图（画成画了 X 的方块）

Horror > New Releases > Zombie Romance`、电影标题 "Zombie Romance"、年份 "Released in 2014"、剧情简介、`Cast and Crew` 链接、`Sign Up to Watch` 按钮、一行 "Similar Movies On MyFlix" 含三个占位缩略图（画了 X 的方块）。没有真实图片、没有最终字体、没有品牌色 —— 这是有意为之。">

注意它没有的东西：没有真实图片（只有占位）、没有最终字体、没有品牌色。线框图就是为了浮现关于布局、标签、信息层级的决策，而不是视觉打磨。

13.3 Balsamiq 风格的"草稿感"在传达什么

像 Balsamiq 这样的工具故意把线框图渲染成手绘的样子，理由是社会性的：它在传达一个信号 —— "这是粗稿，请评论结构，不要评论打磨。" 如果太早把像素级精致的原型给到一位关键人，他会去挑剔字体选择，而不是信息架构。

14. 方法 6：设计准则（Design Guidelines）

设计准则是可复用的规则和预制组件，用来在一个组织的多个产品之间保证一致性。没有它，每支团队都会自己发明按钮、颜色和表单形态 —— 结果就是混乱的用户体验。

14.1 "Before" —— 没有准则会发生什么

讲座的 "Before" 幻灯片汇集了大约两打来自美国政府网站的按钮，它们大致都在做同一件事 —— 提交表单、登录、搜索：

SUBMIT、JOIN US、Log in、Register、Search、GET THE LATEST、Apply Now、Get started、Sign In、Subscribe、Create an account、LOG IN、Where's My Refund?、Q Search、Apply、Search、Reset、Learn more、Login、TRY OUR VISA WIZARD、Get Weather、All Outbreaks、Search、go……

每个按钮都用不同的颜色、形状、大小、动词。用户在一个站点学到的东西，在下一个站点就要从头再学。

14.2 "After" —— 美国 Web Design Standards

一份典型的设计准则文档通常包含：

设计准则就是把"做对的方式"打包成组件。它让设计师不必反复决定，让开发者不必反复实现，让用户不必反复学习。

14.3 准则为什么有效

15. 方法 7：启发式评估（Nielsen）

启发式评估 = 用研究支持的原则去评估和改进系统的可用性，不需要真实用户在场。它也叫"折扣可用性测试（discount usability testing）"，因为成本远低于完整的用户研究。

15.1 流程

15.2 Nielsen 十大启发法 —— Quiz 6 的核心

复习指南明确说："Know and understand all the Nielsen heuristics." 下面是这十条，附讲座里给出的例子。

15.2.1 系统状态可见（Visibility of system status）

系统应当通过及时合理的反馈始终告诉用户正在发生什么。

例：Picnik（图片编辑器）在加载时显示一条绿色进度条，配上俏皮的提示语 "Fluffing clouds…"。或者一条行内确认信息："Your password has been emailed."。用户永远不会困惑系统是否注意到了自己的点击。

15.2.2 系统与现实世界匹配（Match between system and the real world）

系统应当说用户的语言，遵循现实世界的约定，而不是内部行话。

例：macOS Finder 用文件夹图标表示文件夹，用文档图标表示文档，用相机图标表示相机应用。iTunes 用 Library / Music / Movies / TV Shows / Podcasts / Audiobooks / Radio —— 都是听音乐的人本来就懂的词。对比 Lecture 11 失败案例里的 cr_int_sprd。

15.2.3 用户控制与自由（User control and freedom）

用户会犯错，需要一个清晰标记的"紧急出口" —— 撤销、重做、取消、后退、退出。

例：每个浏览器都有后退键；每个编辑器都有 Ctrl+Z；每个多步表单都在主操作旁边放一个 Cancel 按钮。Photoshop 的编辑工具栏把撤销 / 重做和剪切 / 复制 / 粘贴排在一起。

15.2.4 一致性与标准（Consistency and standards）

用户不应当被迫去琢磨不同的词、情境、操作是不是同一个意思。要遵循平台约定。

例：Microsoft Office 在 Word、Excel、PowerPoint 里使用同一套 ribbon、同一套图标、同一套快捷键。移动端有标准图标（电话、搜索、爱心、播放、邮件、设置），在不同 app 里含义都一样。Google Translate 把语言切换器放在每次都同样的位置。

15.2.5 错误预防（Error prevention）

比"好的错误信息"更好的是让错误根本无法发生的精心设计。

例：表单的 Update 按钮在用户输入内容之前一直保持禁用（灰掉），这样根本无法提交空内容。PowerPoint 在关闭之前问 "Do you want to save the changes made to 'Lecture7-1'? [Don't Save] [Cancel] [Save]" —— 三个清晰可分的选项，Save 是主操作（高亮），Cancel 是次要操作，让用户不会误删自己的工作。

15.2.6 识别优于回忆（Recognition rather than recall）

通过让对象、操作、选项可见来减轻用户的记忆负担。用户不应当被迫记住对话框中一个部分的信息以便用在另一个部分。

例：macOS 字体选择器把每个字体名用其字体本身渲染，让你直接认出长相。PHP / IDE 的自动补全弹出 str_pad、str_repeat、str_replace、str_rot13、strcasecmp、strchr、strcmp…… —— 开发者识别出对的函数，而不是从零回忆出来。

15.2.7 灵活性与高效率（Accelerators，加速器）

加速器 —— 键盘快捷键、手势、命令面板 —— 让专家用户提速，又不拖累新手。

例：OmniFocus 的 "Common Shortcuts" 面板：Return 表示 Add Action、⌘N 表示 New Window、^⌘S 表示 Synchronize with Server、⌘K 表示 Clean Up、⌘1 / ⌘2 表示 Planning / Context 模式、⌥⌘1 表示 Inbox、^⌥Space 表示 Quick Entry。新手永远不必学这些；专家依赖它们。

15.2.8 美学与极简设计（Aesthetic and minimalist design）

对话框中不应包含无关信息。每一个多余的元素都在与相关元素争夺用户的注意。

例：一个博客的搜索下拉，使用了对比（contrast）（一个突出的搜索按钮）、重复（repetition）（一致风格的单选按钮 Everything / Entries / Photos / Videos / Audio / Users）、对齐（alignment）（所有元素整齐成列）、邻近（proximity）（相关选项被组在一起）。这四个原则 —— contrast、repetition、alignment、proximity —— 是值得背下来的极简设计配方。

15.2.9 帮助用户识别、诊断、从错误中恢复（Help users recognize, diagnose, and recover from errors）

错误一旦发生，错误信息应当用平实的语言，精确描述问题，并建设性地提出解决方案。

例：一个有三处错误的注册表单，每处错误都显示在相关字段旁边，用友好的语气写："bert is already taken. Please choose a different username." / "Passwords must be at least 6 characters and can only contain letters and numbers." / "The email provided does not appear to be valid."。或者一个 404 页面写着 "Oh no! It seems the page you were trying to find on my site isn't around anymore. Report it missing using my contact form, or browse my articles listing or browse my blog."。

15.2.10 帮助与文档（Help and documentation）

即使系统应当无需文档也能使用，帮助也应当存在 —— 而且要易搜、聚焦于用户的任务、列出具体步骤、不要太长。

例：Picnik 的引导提示 "Welcome to Picnik Collages! Making collages from your photos has never been easier." 配 "1 of 8" 的步骤计数器。或者在容易让人困惑的字段旁边放一个小小的 ? 图标，点击会弹出 "Which one is right for me? Use Windows when… Use SNMP for… SSH works best for…" —— 上下文相关的帮助，正好出现在它该出现的地方。

15.3 总结表

16. 方法 8：用户测试

用户测试 = 把真实用户放到（真实的或原型的）系统前面，给他们代表性任务，观察会发生什么。启发式评估用专家加清单；用户测试用真实用户加被观察的行为。

16.1 测试之前先改进

用户测试很贵 —— 不要把一场测试浪费在一个明显有缺陷的设计上。先做更便宜的检查：

只有过了这些，再去预约真实用户才划算。

16.2 规划一场用户测试 —— 五件要设计的事

注意它和任意其他领域的对照实验是平行的：被试、材料、流程、测度。用户测试就是经验研究，只是专门用在 UI 上。

16.3 用户测试的两种场景

16.3.1 专业可用性实验室

带有单向镜的专用设施：一间受控的测试间（用户在一台计算机前工作，有时配眼动设备），一间观察间（研究者实时观察）。整场过程被录像以便后续编码分析。昂贵但严谨。

16.3.2 不太正式的用户测试

很多真实世界的测试要简单得多：

• Beta 发布搭配反馈通道 —— 讲座展示了一个 "Super Secret β" 页面，被真实用户用红笔批注得满满的
• 数据看板（Analytics dashboards） —— 实时图表显示 session 时长、每场屏数、最常访问的屏、目标完成、应用内收入。它们揭示用户在做什么；但不一定能解释为什么
• A/B 测试 —— 给一半用户看 A 版，给另一半看 B 版，测哪个转化更高（Lecture 11 里的 Obama 竞选例子就是这种）

大项目用实验室；日常的产品工作靠 beta 周期、数据、A/B 测试。两者都是"用户测试"，因为都靠真实用户驱动数据。

17. Quiz 6 复习要点

复习指南幻灯片明确点出了三项内容：

17.1 八种以用户为中心的设计方法

你应当能说出每一种并简短描述：

17.2 全部十条 Nielsen 启发法

把 §15.2 的十条背下来。一个有用的助记法是把它们分组：

• 告诉用户正在发生什么： （1） 状态可见、（2） 与现实世界匹配、（10） 帮助与文档
• 让用户掌方向盘： （3） 用户控制、（7） 加速器
• 让系统可预期： （4） 一致性、（8） 极简设计
• 优雅处理错误： （5） 预防、（6） 识别优于回忆、（9） 恢复

17.3 在线阅读材料的主要观点

（见 Canvas 的两份短读物；这两份的主要观点也算考点。）

17.4 其他可能出现的概念

• 为什么可用性重要（销量 / 满意度 / 效率 / 忠诚度；第一印象；安全相关情境）
• 可用性工程为什么难（涉及心理学 / 认知科学 / 美学 / 艺术；工程师 ≠ 受众）
• 三句名言（Joel：程序按用户预期行为；"GUI 应当提供 GUIdance"；Google：聚焦用户）
• 极简设计的四原则（contrast、repetition、alignment、proximity）
• 用户测试规划的五要素（subjects、system、tasks、session、measures）
• 测试前改进的方法（检查清单、启发式评估、认知遍历）

18. 总结与记忆框架

Week 6 知识结构
|
+-- 我们在哪里
|   +-- Requirements -> Architecture -> Design -> USER METHODS -> Code
|   +-- 本周的问题：怎么让软件满足
|       USER 的需求？
|
+-- 为什么可用性重要 (Lecture 11)
|   +-- 风险：从 MRI / 驾驶舱安全 到 网页转化
|   +-- 回报：simple、inexpensive、sales+、satisfaction+、
|   |        efficiency+、随时间转向 loyalty
|   +-- 三句名言：
|   |   +-- Joel：UI 设计得好 = 程序按用户预期行为
|   |   +-- "GUI should provide GUIdance"
|   |   +-- Google：聚焦用户，其余自然跟来
|   +-- 为什么难：
|       +-- 需要心理学、认知科学、美学、艺术
|       +-- 工程师不是受众 -> 需要刻意的方法
|
+-- 八种以用户为中心的设计方法 (Lecture 12)
|   +-- 1. 访谈与观察
|   |       -> 来自真实用户的直接数据
|   +-- 2. Personas
|   |       -> 照片 + 人口统计 + 引言 + 简介 +
|   |          目标 + 任务 + 技术能力 + 环境
|   |       -> 成组覆盖多种用户角色
|   +-- 3. Scenarios
|   |       -> 简短叙事：persona + 目标 + 上下文
|   |       -> 平实语言、第三人称
|   +-- 4. Storyboards
|   |       -> scenario 的连环画化
|   |       -> 心理气泡浮现困惑
|   +-- 5. 线框图 / 原型
|   |       -> 真实屏幕的低保真草图
|   |       -> Balsamiq 风格的"草稿感"传达
|   |          "评论结构，不是打磨"
|   +-- 6. 设计准则
|   |       -> 调色板 + 字体 + 组件 +
|   |          线框图 + 代码
|   |       -> US Web Design Standards 是典范
|   +-- 7. 启发式评估 (Nielsen) **
|   |       -> 流程：选任务、扮演用户、
|   |          逐启发法评审、记笔记
|   |       -> 十条启发法（背下来）：
|   |          1. 系统状态可见
|   |          2. 系统与现实世界匹配
|   |          3. 用户控制与自由
|   |          4. 一致性与标准
|   |          5. 错误预防
|   |          6. 识别优于回忆
|   |          7. 加速器（灵活性 & 高效率）
|   |          8. 美学与极简设计
|   |             (contrast, repetition, alignment, proximity)
|   |          9. 帮助用户识别 / 从错误中恢复
|   |         10. 帮助与文档
|   +-- 8. 用户测试
|           -> 测试前先改进（检查清单、启发式评估、
|              认知遍历）
|           -> 规划：Subjects、System、Tasks、Session、Measures
|           -> 正式实验室 OR 非正式（beta、数据、A/B）
|
+-- Quiz 6 复习要点
    +-- 八种以用户为中心的设计方法
    +-- 全部十条 Nielsen 启发法
    +-- 在线阅读材料的主要观点

一句话总结

以用户为中心的设计之所以存在，是因为一个架构得再好的系统，如果忽视用户，仍然会失败 —— 而软件工程师并不是自己的受众，需要刻意的方法去跨越这道鸿沟；这些方法从理解用户（访谈与观察）开始，到描述用户（personas、scenarios、storyboards），到画出系统（线框图 / 原型、设计准则），再到评估它（对照 Nielsen 十条原则做启发式评估，再用真实用户做用户测试 —— 在实验室里或通过 beta / 数据 / A/B），而贯穿其中的"好"的可操作定义就是 Joel 那句：界面设计得好，是当程序的行为完全符合用户的预期。