Usability Evaluation Considered Harmful

01 · 核心结论：先确定问题，再决定如何评价

这篇文章并不主张停止 usability evaluation。它反对把某一种评价，当作所有研究、所有设计阶段和所有创新的必经认证仪式。真正的要求是：先说明要回答什么，再选择能为这个问题提供证据的方法。

Saul Greenberg 与 Bill Buxton 的 CHI 2008 批评论文发表于 111–120 页，DOI 为 10.1145/1357054.1357074。本文使用固定的 10 页会议版本，作者网站版本虽然 PDF 字节不同，但逐页抽取的全部正文一致；不混入 2007 技术报告。

「Some of the Time」不是可省略的副标题。作者明确承认可用性评估对于修复交互问题、验收需求、比较成熟方案经常很有价值；论文批判的是不考虑目的、成熟度与使用文化的机械应用。若把本文当成「没有用户研究也永远不必解释」的理由，就与结论直接冲突。

文献类型：概念分析与规范性论证。没有新招募的实验被试、训练模型、基准排行榜或定量消融；经验素材来自既有文献、作者经历、设计图示与历史案例。下面区分 Paper Verified（原文确实写到）、Author Claim（作者主张）、Our Interpretation（本页解释）与 Research Extension（后续设想）。

作者网站会议 PDF，第 1–2 页

02 · 它批判什么：方法范围与制度背景

原文限定的 usability evaluation 主要包括实验室用户观察、受控用户实验，以及 inspection techniques 等常见检查方法。通常考察用户执行一个或多个任务时的有效性、效率和满意度。它并未将所有可能的「评价」都否定，更不把设计批评、实地理解、反思或文化探查排除在知识生产之外。

为什么会变成默认教条？

1. 教育：HCI 课程把设计、实现、评估、重设计作为典型循环。评估方法相对容易教学、考试和形成明确学习目标，因而可能压过更难规范化的设计与实地理解。
2. 学术：论文提交与审稿文化强调验证。作者引述当时 CHI 投稿指南，并结合程序委员会经历，担忧评审把「有没有评估」代替「贡献需要什么证据」。
3. 产业：专业 usability 团队能够持续找到问题并反馈给开发者，这本是进步；但部门结构和专业训练也可能让可用性问题变成唯一被组织看见的问题。

Author Claim：以上压力共同促进了方法偏好。Reviewer：作者的委员会经历与教学观察没有被系统抽样；论文没有测量三种制度因素分别造成多大影响，因此应读为有经验支撑的诊断，而非已识别因果效应。

第 2–3 页：The Heavy Push for Usability Evaluation

03 · 弱科学之一：方法反过来制造研究问题

方法工具箱的初衷，是让研究者按照具体问题、成本与所需证据选择方法。作者担心实际顺序倒置：先认定受控定量实验最容易被接受，再寻找适合该实验的问题，或只突出复杂问题中方便测量的小部分。

例如，一个协作工具真正的问题可能是组织是否愿意持续使用、角色责任怎样改变。但研究者若只会比较完成按钮点击所需时间，就可能将「工作是否变好」缩减成「某操作是否快一点」。不是时间指标无效，而是它可能回答了另一个较窄的问题。

本页形式化解释，非原文公式：设研究问题为 \(Q\)，方法为 \(M\)，证据为 \(E\)，欲支持的主张为 \(C\)。合理链条是从 \(Q\) 选择 \(M\)，获得 \(E\)，再限制 \(C\) 的范围；不能因 \(M\) 被偏爱，就改造 \(Q\) 以迎合发表。

这一图式不是算法、评分函数或训练目标；它帮助检查论证顺序。选择方法时还需考虑可行性与伦理，论文也没有宣称每个问题都存在唯一正确的方法。

原文中两组百分比不能混成新统计表

第 3–4 页：The Method Forms the Research Question · 第 9 页：相关工作比例

04 · 弱科学之二：存在证明、冒险检验与复现

创新原型常被放在对自己最有利的任务、场景与指标下测试，只为证明「至少有一个场景比旧方案好」。作者称这种评价为 existence proof。它确实回答了一个可行性问题，却不足以支持「新技术普遍更好」的宽主张。

重要细节：作者并未全面否认 existence proof。建议部分明确说，非常新颖的创新可以先用存在证明；对主流系统或已有想法的微小变体，则更应采用冒险检验。证据要求随主张与成熟度变化，不能一刀切。

为什么审稿制度会使问题持续？

论文描述一个悖论：首先要求有评估才能发表，但初次评估通常偏确认性；随后又以「已经做过」拒绝复现，恰恰把更严格挑战原主张的机会排除。对陌生技术，评审还可能把细微但重要的变化看成同一件事，要求巨大效果；对熟悉的菜单方案，却能接受很小差异。

Reviewer：这是一种出版激励机制的假说，本文没有审稿文本编码、录用率分析或实验来估计其强度。它的实践价值是提醒研究者预先写清哪项主张可以被什么结果推翻、哪些材料可供复现，并提醒评审评价新增证据而不仅追逐表面新颖性。

第 3–4 页：Existence Proofs、Lack of Replication

05 · 弱科学之三：客观数据与专业判断不是互斥选项

作者认为，定量数字给人一种摆脱主观性的安心感；定性观察也会以事实约束解释。但若因此拒绝设计者的经验、论据、反思与直觉，研究共同体就只允许一种形式的有效理由。

本文借用建筑设计中 assessor 的讨论：专业判断并不必然随意，它受到训练、实践、共享价值、隐含规范与共同体质询的约束。设计批评可以要求清楚说明选择理由、情境、替代方案与预期效果；不能因为结果不是一个数，就宣布它没有严谨性。

Author Claim：专家反思与主观论证应有合法地位。Reviewer：「合法」不意味着任何意见都与实验数据等强，也不意味着资历可以替代论证。专家共同体同样可能有偏见、权力不平等与排他性；本文没有提出怎样量化或校正这些问题的完整方案。

读者应避免把文中客观／主观、科学／设计的修辞二分当成严格的方法分类。例如，民族志和案例研究也可以系统收集经验材料；design critique 中也能引用可观察证据。更有用的区分是：当前主张需要什么推理，证据怎样被检查，谁的经验被纳入，结论允许走多远。

第 4 页：Objectivity vs. Subjectivity

06 · Figure 1：草图与原型的差别在目的

Sketch 不是简单地指纸张；视频、互动幻灯片甚至可运行系统也可以是草图。关键是它是否用来把尚未确定的想法外化、探索问题和发现替代方向。Prototype 则更接近对一个已选择方向的具体实现，用于检验与细化。

这张图画的是连续关系，不是八项二分类评分表，也没有给出从 sketch 转为 prototype 的数值阈值。图源为作者引用的 Buxton 著作，本文将它用于解释评价对象容易被误识别的机制。

两个方向的失败

1. 过早淘汰：草图必然有缺口、粗糙交互和未实现功能。把这些当作完成品缺陷，与成熟保守方案直接比较，可能在想法尚未长成前判它失败。
2. 过早承诺：不断修复同一个草图的问题，会投入越来越多时间并锁定该方向，让团队停止考虑其他可能更好的设计。

Our Interpretation：视觉精致度或系统能否运行，并不能替代成熟度声明。研究演示应明确「本次想检验哪种潜力」「哪些交互只是暂时占位」，同时诚实承认这些占位对评价的影响；不能事后把所有负面结果都归为原型不成熟。

第 4–5 页：Sketches vs. Prototypes；原 Figure 1

07 · Figure 2：选对设计，再把设计做好

Figure 2a 描绘沿一个方向不断迭代，Figure 2b 先生成多个设计，再选择和细化。Getting the Design Right 关注选定方案内部的修复；Getting the Right Design 关注选择哪个方向。作者借用 local hill climbing 比喻前者可能陷入局部改进。

这里的局部／全局极值是解释性比喻，论文没有定义可计算的设计空间、目标函数或最优算法。多画草图也不保证找到全局最优；它的作用是延后承诺，让替代选项进入讨论。

原文主张的顺序

1. 产生多个互相竞争的想法与变体，而非只改一个界面。
2. 通过反思、讨论和 critique 比较其潜力、假设与代价。
3. 发展较有希望的方向，直到它们可以支持明确的检验。
4. 再开展合适的可用性评价与迭代优化。

作者进一步指出，think-aloud、task-centered walkthrough、heuristic evaluation 常以发现问题为主要产出。问题比潜在收益更容易被清点，若决策只数 bug，就可能低估粗糙但有用的新方向。评价应关注成本和收益，但本文没有提出二者的统一计量单位或权重。

Reviewer：这是对机械串行迭代的批评，不是规定所有项目都必须完成一次永久的「发散阶段」才允许接触用户。早期观察能帮助发现需求误解；关键是将结果用于学习与重新构思，还是作为立即淘汰想法的判决。设计过程也可能多次发散与收敛，而非一次直线流程。

第 5 页：原 Figure 2 与 Getting the Right Design

08 · 有用、好用与文化采用是不同问题

作者借用 Landauer 区分「太难用」和「提供的有用东西太少」。系统可能非常流畅却解决了没人关心的问题；另一个系统可能很难用，却因提供此前无法获得的能力而被接受。效率、有效性与满意度在指定任务下的表现，并不自动证明任务本身有价值。

表中「可能的方法」是本页依论文建议整理的选项，不是保证因果识别的处方。需求分析也可能受当前习惯限制；把已知任务放进 usability study，并不必然发现未来的用途。

Discovery 与 Invention

论文转述 UIST 2007 讨论：discovery 旨在发现世界的事实、区分理论解释；invention 则将技术创造性地带到复杂真实世界。前者可以从已知现象的少数变量切入，后者常涉及大范围变化与新实践。小而可控的任务效果，对前者可能很重要，却未必足以评价后者的潜力。

Reviewer：二者并非互斥，同一系统可以包含发明贡献和可检验科学主张。较合理的做法是把主张拆开，分别提供证据，而不是因为自称「创新」便不受任何检验。

第 6 页：Usable or Useful? 与 Discovery/Invention

09 · 历史案例怎样支撑论证，又不能证明什么

作者从这些案例提炼的五点

1. 愿景与技术本身一样重要，即使愿景后来被修正。
2. 愿景常指向新使用文化，改变人们能做什么。
3. 创新到产品有时间间隔，不是演示后立刻实现。
4. 真正的用户、用途与文化采用，可能偏离发明者预想。
5. 在技术与文化未成熟时，狭窄测试可能只测出缺陷，且测试任务与后来的实际用途没有对应关系。

Reviewer：成功案例的回顾具有幸存者偏差。作者展示了「不经常规测试也可能有影响」的例子，却没有比较大量失败创新，也没有证明提前评价一定会阻止这些成功。反事实句子应当作为提醒，而非关于可用性测试因果危害的已验证结论。

家庭技术段的脚注还专门承认：小规模 toy deployment 可以有用，但应当用来支持设计批评和反思，而不一定作为最终验证。这个限定很重要；本文不是让研究者停止接触真实使用者。

第 6–8 页：历史案例与五点讨论

10 · 五项行动建议与可执行的选择流程

1. 把 usability evaluation 放回工具箱：需求理解、文化背景、替代方案、技术新可能性都属于 user-centered design。
2. 判断此时能否产出有意义信息：明确设计阶段与问题；若不能回答关键问题，应寻找其他验证方式。
3. 取消一律要求某种测试的规则：并非接受华丽演示或空泛辩护，而是要求设计理由、替代方案、学到什么、预期问题、已有工作与情境、下一步。
4. 在适用时让科学检验更强：新颖创新可先证明可能性；成熟方案和小变体更需挑战性检验、数据／软件开放与复现。
5. 向其他设计学科学习：设计工作室、Crit、民族志和文化探查能够补足单一评估方式。

Design Critique 的具体活动

设计者先呈现产物并解释选择；不同资历成员回应喜欢或不喜欢的部分，追问假设、提出挑战，并给出具体改进建议。双方通过互动建立对设计和使用情境的共同理解。它需要可被讨论的材料、清楚理由与建设性反馈，不等于专家投票或泛泛表达审美。

本页可执行检查单（Our Interpretation）

先写一句「本研究要判断……」，再写一句「结果若为……我们将改变……」。如果无论测到什么都不改变任何主张或设计决定，该评价可能只是装饰。这个操作化建议由本页提出，不是原文的正式 protocol。

第 8–9 页：What To Do

11 · 证据层级、局限与 Reviewer 评论

Paper Verified：论文包含两张概念图、制度诊断、三条核心批评线、历史案例和五项建议；没有原编号实验表，没有受试者样本表、训练／推理设定、统计检验或性能消融。页面中的所有表格都是阅读重建／分析表，不能作为论文新测量结果引用。

Strengths：文章把「研究目的」「证据方法」「设计阶段」从一个含混的 validation 标签中拆开；也能区分成熟系统的可比性与激进创新的可行性。尤其有价值的是双向警告：测试会过早否定，也会促使团队过早投入某个方向。关于复现与风险检验的讨论表明作者要求更好的证据，而非更少的责任。

Weaknesses：主要材料是历史成功案例与作者经验，不能估计危害发生率或总体净影响；创新若失败，是愿景本身不值得还是测试方法不当，文中缺少可操作的判别准则。对科学和设计、客观和主观的区分有修辞上的过度简化；对专家 Crit 如何处理偏见、冲突与权力问题讨论不充分。

公平反驳：「过早测了会毁掉创新」也可能成为难以证伪的借口。团队必须预先声明哪些结果会促使停止、转向或继续；保护探索不能免除对明显风险、可访问性问题或用户代价的责任。这是本页的规范性补充，文章没有提供完整伦理评估框架。

潜在改进研究：可以在相似设计团队中比较多方案发散后评价与单方案不断修复，观察方向多样性、最终实用价值、问题发现、时间成本与放弃理由；也可以系统分析审稿意见中的方法偏好。这些研究需要前置定义与长期跟踪，本文未执行。

不要把缺少实验误读成缺少贡献

批评论文的贡献是提出更清晰的区分、暴露惯例的盲区并提出制度和实践建议。应检验其论证是否一致、案例是否支持所需范围、反例与替代解释是否被处理，而不是机械要求它也提交一张 A/B 实验表。与此同时，批评文章中的因果措辞仍要受到证据强度约束。

12 · 对 AI Agent 与程序化材质研究的启发

Research Extension：下面是将文章原则迁移到当代研究的设想，2008 原文未研究 LLM、生成式 Agent 或程序化材质生成。

1. 拆分贡献：新图生成表示的技术可行性、生成图能否执行、材质视觉质量、艺术家是否能有效编辑，是四种不同主张。一个满意度调查不能同时证明全部四项。
2. 早期方向与成熟工具分别评价：一个尚未完成交互的节点图生成草图，可以先通过有证据的案例与专家 critique 展示新工作流；若宣称比现有编辑工具更高效，则仍需要公平任务、成熟度说明和用户表现证据。
3. 让困难案例进入评估：除了系统擅长的材质，也应考虑复杂拓扑、不可执行节点、反复修改与工具失败。目的不是堆更多 benchmark，而是检验主张最容易失效的条件。
4. 不把瞬时偏好当作采用：看一张渲染图选「更喜欢」无法说明用户会在真实项目中保留、理解和维护生成图。后者需要长期编辑、版本演化和协作实践证据。
5. 解释不评什么：如果当前阶段不做定量用户实验，应清楚说明已有证据支持什么、暂不支持什么，以及下一阶段将怎样检验；不能只引用标题作为免责。

一份好评估计划应该让读者知道「证据将改变哪项决定」，而不是只看到一串流行指标。多方法 triangulation 的意义是补充不同盲点，不是把任意多个弱证据相加就变成强因果证据。

13 · 学术脉络、来源与归档

论文与 Lieberman 的 Tyranny of Evaluation、Zhai 的回应、Cockton 的方法贫乏讨论、Olsen 的 systems evaluation 标准对话。它既回应传统实证检验，也借鉴 Buxton 的 sketching、Tohidi 等人的多方案反馈、Gaver 的 cultural probes，以及 CSCW／Ubicomp 的情境研究。这里列的是原文引用关系，未声称本次逐篇重做它们的研究。

1. 原论文 DOI：Greenberg, S. & Buxton, B.，CHI 2008，111–120。
2. Bill Buxton 作者网站会议版 PDF：与固定 PDF 全部逐页文本一致，支持页面锚点与原图引用。

固定 PDF：10 页；SHA-256 为 4fe7fb85923749f0ba9e11e883687dc1728b735b5b7cec633fbcdf4db4311f90。作者网站 PDF 的字节哈希不同，因此保留固定文件，不以下载副本覆盖。原 Figure 1–2 裁自固定文件第 5 页；没有发现可单独引用的可靠作者原图地址，故优化后内嵌。

作者关系：第一作者 Saul Greenberg；末位作者／未核实通讯候选 Bill Buxton*。PDF 列两人邮箱但没有显式通讯作者标记，不把邮箱出现当作确认。People 链接仅为待归档关联，实际记录复用与存在性需在仓库导入时检查。

新增阅读不会改写原 note frontmatter、原正文或 PDF++ anchors。仅生成 HTML、Markdown 增补和保持原文字节前缀的合并候选；People、索引和实际仓库尚未写入。浏览器 QA 按本批要求延后，不把静态检查说成浏览器验收。