课程：《人机交互与用户体验》

根据课程《人机交互与用户体验设计》确定，每个部分后面数字表示在教材《人机交互：软件工程视角》豆瓣链接中对应的章节。

1. 初始人机交互和用户体验

1.1 从 HCI 到 UX（1.2）

• 什么是 HCI

  “HCI is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them.” — ACM SIGCHI

• 什么是用户体验
  “User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products.”—— Donald Norman

  💡不能够设计用户体验，只能为用户体验而设计
  

• 用户体验设计

  • 借鉴了人机交互、交互设计、视觉设计、信息架构、用户研究等相关学科
  • 主要方法是以用户为中心的设计（User-Centered Design，简称UCD）
  • 没有一种用户体验设计方法是完美

• 用户体验 UX vs. 人机交互 HCI

  User Experience	HCI
  * 广泛的用户基础 * 受业界青睐 * 常见于产品设计、工业设计领域	* 较为学术化 * 常见于计算机专业研究员 * 如今也包含体验的诸多方面

• 交互设计 IxD
  包括：

  • 用户界面设计
  • 软件设计
  • 产品设计
  • 网页设计
  • 体验设计

1.2 为什么要学习 HCI（1.2）

• 人机交互的研究内容
  • 人
    • 对人的感知特性有所了解
    • 如何处理信息？
    • 可能会犯哪些错误？
  • 机器
    • 有哪些特性可供使用？
  • 交互
    • 提供了哪些便利？
    • 受到哪些限制？
    • 怎样在具体设计的时候进行选择？
      
• 人机交互的重要性
  人机交互是一门交叉学科
  

    💡 孤立地从一个学科出发永远不可能设计出一个具有良好用户体验的交互式系统
  

1.3 为什么软件会不好用（2.2）

• 框架
  • 提供理解或定义某种事物的一种结构
  • 能够帮助人们结构化设计过程
  • 认识设计过程中的主要问题
  • 定义问题所涉及的领域
• 执行评估活动周期（Execution-Evaluation Cycle，简称EEC）：交互设计领域最有影响力的框架
  • 目标（Goal） & 意向（Intention）
    • 目标：想做什么
    • 意向：达成目标的一系列活动
  • 执行（Execution）
    • 要实现目标必须进行的操作
  • 客观因素（World）
    • 执行活动时必须考虑的客观条件
  • 评估（Evaluation）
    • 用于衡量活动执行的结果与目标之间的差距
      
• 为什么有些用户界面会给用户带来问题：执行隔阂（gulfs of execution）与评估隔阂（gulfs of evaluation）
  • 执行隔阂（gulfs of execution）
    • 用户为达成目标而制定的动作与系统允许的动作之间的差别
  • 评估隔阂（gulfs of evaluation）
    • 系统状态的实时表现与用户语气之间的差别
• ECC 模型的启发
  • 设计人员要思考如何才能够使用户简单地确定哪些活动是被允许的
  • 确定系统是否处于期望的运行状态等问题

2. 交互设计的原则和目标

2.1 “以用户为中心的系统设计”由来（9.2）

• 相关技术
  • 以用户为中心的系统设计（User-Centered Systems Design, UCSD）
  • 人本中心的系统设计（Human-Centered System Design, HCSD)
  • 用户体验（User Experience, UX）
  • 以用户为中心的设计（User-Centered Design, UCD）
  • 交互设计 （Interaction Design, IxD）
  • 人机交互（Human-Computer Interaction, HCI）
  • 旨在改善人与计算机的交互方式，但研究侧重和范围各不相同
• 用户为中心的设计（用户为中心的系统设计）
  • 该领域的从业人员汲取了人类学、社会学和信息科学等领域的基础研究成果
  • 近年来与人因工效学（Human Factors）、UX、HCI、计算机支持的协同工作、以计算机为媒介的交流信息，以及普适计算等存在相当交集
    • 人因工效学：
      • 目的是使工作环境和工作操作中的安全和健康达到最优，并确保工具、设备还有其他物品的可用性
      • 人因工效学关注的是人与其工作或休闲环境提供良好的“匹配”
• 以用户为中心的设计思想：人类应该被看作是信息系统中最重要的元素，应该被引入设计
  • 包含对用户需求的关注，对活动、任务以及需求的分析，早期的测试和评估，以及迭代式的设计
  • 重点：更加强调用户，而不是关注与征集需求和说明的规范化方法
    • 不是一个死板的设计过程，而是一个更加灵活，迭代式的设计方法
  • 以人为中心的设计则更进一步
    • 不光关注用户与系统的交互，并且还考虑除了与界面或者系统自身直接交互外，系统还可以怎样影响人们的能力和特征
• 用户体验（UX）
  • 用户对于使用或者预期使用产品、系统或服务的感知和反应
  • 用户体验不仅涉及界面设计，还关注人在使用产品前、使用产品时以及使用产品后的心情、信念、喜好、感知、身体和心理的反应、行为以及成就感

  💡经常和可用性交替使用，但是两者的关注点有明显的不同
  ~ 可用性和可用性工程关注的是与任务相关的方面（即完成工作）
  ~ 用户体验与体验设计则将用户的感觉、心情、价值观等放在首位
  

• 人机交互（HCI）
  • 对人（用户）与计算机之间交互方式的研究
  • 涵义较界面设计更加宽泛
  • 根源是社会科学
• 人机交互发展的三股浪潮
  • 第一股浪潮
    • 吸收了认知理论和人因学的观点
  • 第二股浪潮发生在20世纪80年代后期到21世纪早期
    • 关注使用多种应用程序的用户群体，吸收了“情境行为”“分布式认知”以及“活动理论”等多种理论。
    • 在这个阶段“僵化的指导方针、规范化的方法和系统的测试方式”已经不再是主要的关注点，因为人机交互的研究和从业人员已经转向如“参与式的设计研讨会、系统原型和情境问答等各种主动式方法”
  • 第三股浪潮
    • 认识到计算机已经被应用到各种私有和公共领域，从公共场合进入到日常生活，其使用不再具有明确的工作相关性、目的性和合理性。
• 关键技能：确定哪些是核心、主要，哪些是边缘、次要

2.2 可用性 （3.2）

• Affordance：“可供性” 或者 “示能”
  • 指一个物理对象与人之间的关系。该物理对象可以是动物或者人类，甚至也可以是机器和机器人，二者之间发生的任何交互作用。” ——Donald Norman《设计心理学》
  • 示能指所有操作的可能性，而非特定指好的交互操作
• Mental Modal：“头脑模型” 或者 “心智模型”
  • 确定程序充分反映用户关于特定任务的心智模型
• 可用性目标
  
  • 易学性 learnability
    • 指使用系统的难易，即系统应当容易学习，从而用户可以在较短时间内应用系统来完成某些任务
    • 最基本的可用性属性
    • “10 分钟法则”
  • 高效率 efficiency
    • 效率：当用户学会使用产品之后，用户获得的生产力水平
  • 易记性 memorability
    • 用户在学会使用软件后应当容易记忆
    • 对偶尔使用的用户，也能够借助一些简单提示即能够使用系统，而不用一切事情从头学起
    • 影响因素：
      1. 位置：将特定对象放在固定位置
      2. 分组：对事物按照逻辑进行恰当的分组
      3. 惯例：尽可能使用通用的对象或符号
      4. 冗余：使用多个感知通道对信息进行编码
  • 低出错率 （low error rate）
    • 与计算机不同，人是会犯错误的
      • 有些错误会被用户发现并纠正
      • 有些错误会带来灾难性后果
    • 措施
      • 保证导致灾难性后果错误的发生频率降到最低
      • 保证错误发生后迅速恢复到正常状态
  • 主观满意度（satisfaction）
    • 用户对系统的主观喜爱程度
    • 某些情况下，系统的娱乐价值比完成任务的速度更为重要（如家用计算、游戏等非工作环境的系统）
• 可用性
  • 是衡量交互式系统质量的一种重要度量
  • 体现了软件质量观念的转变
    • 传统软件质量观
      • 侧重内部效率和可靠性
      • 如程序代码运行时的效率以及灵活性、可维护性
    • 人机交互软件质量观
      • 转向用户视角

2.3 可用性工程（Usability Engineering）(3.3)

• 关键步骤
  • 了解用户
  • 竞争性分析
  • 设定可用性目标
  • 用户参与的设计
  • 迭代设计
  • 产品发布后的工作
• 简易可用性工程（DUE: Discount Usability Engineering）
  • 步骤
    • 用户和任务观察
      • 了解产品的目标用户

        ⚠️ 注意
          - 要直接与潜在用户进行接触，不要满足于间接的接触和道听途说
          - “你”不是用户
          - 不要“闭门造车”
      

    • 场景（scenario）
      • 简便易行的原型工具，可节省时间和成本
      • 作用：
        • 在界面设计过程中可以把场景作为用户最终如何与系统进行交互的描述手段
        • 在用户界面设计的早期评估阶段，可以在没有实际可运行原型的情况下通过场景来获得用户的反馈
    • 边做边说
      • 最有价值的单个可用性工程方法
      • 让真实用户在使用系统执行一组特定任务的时候，讲出他们的所思所想
      • 可了解用户为什么这样做，并确定其可能对系统产生的误解
      • 对用户而言不是那么自然，因而实验人员需要不断地提示用户，或请他们事先观摩测试案例
    • 启发式评估
      • Jakob Nielsen等人开发的非正式可用性检查技术
      • 过程
        • 专家使用一组称为“启发式原则”的可用性规则作为指导，评定用户界面元素（如对话框、菜单、导航结构、在线帮助等）是否符合这些原则
      • 启发式规则不是一成不变的
        • 评估不同的设备，如玩具、WEB应用、可穿戴计算设备等，需要根据设计原则、市场研究和需求文档，相应地修改相关原则
          
          其中：
          1. N 是设计中存在的可用性问题的总数，L 是单个参与者所能够发现的可用性问题的比例 （经验取值约为31% ）
          2. 5 名专家能够发现约 80% 的可用性问题，被认为是最恰当的可用性测试用户数量
          3. 若用户数量较多，建议将测试分阶段进行

2.4 设计的基本原则 （3.4）

• 标准与原则
  • 标准
    • 由专家制定的，汲取了研究领域中公认的知识和最好的实践。
  • 原则
    • 不仅详细列举了那些可以支持设计决策的一般性理论想法，还能够解释为什么有些产品是成功的，以及可能是什么原因导致了产品的不成功，相较而言更具宽泛性。
    • 理想情况下，原则都是以基于大量数据的采集和测试中得到的理论观点为基础的。
• 代表原则
  • Alan Dix（基本规则）
    • 可学习性：新用户能用它开始有效的交互并能获得最大的性能
    • 灵活性：用户和系统能以多种方式交换信息
    • 健壮性：在决定成就和目标评估方面对用户提供的支持程度
  • Ben Shneiderman：黄金规则
    • 尽可能保持一致
    • 符合普遍可用性
    • 提供信息丰富的反馈
    • 设计说明对话框以生成结束信息
    • 预防并处理错误
    • 让操作容易撤销
    • 支持内部控制点
    • 减轻短时记忆负担
  • Donald Norman:
    • 应用现实世界和头脑中的知识
    • 简化任务结构
    • 使事情变得明显
    • 获得正确的映射
    • 利用自然和人为的限制力量
    • 容错设计
    • 当所有都不成功时进行标准化
  • Nielsen and Molich: 启发式（Heuristics）规则
    1. 系统状态的可见度
       • 系统应该始终在合理的时间以适当的反馈信息让用户知道系统正在做什么
    2. 系统和现实世界的温和
       • 告诉用户他们可以做什么；阻止受限制的操作
    3. 用户享有控制权和自主权
       • 对于因错误而做出的选择，提供一种“返回方法”［如撤消或重做］，或者重新启动的方法［如网站上的返回主页］
    4. 一致性和标准化
       • 不要在不同的地方为同一个功能使用多个概念或名称
       • 提示符、菜单和用户手册的术语要保持一致
       • 使用没有歧义的图标或图像
       • 在整个应用程序使用一致的颜色、布局、大小写和字体
    5. 避免出错
       • Avoid possibility for users to make errors
    6. 依赖识别而非记忆
    7. 使用的灵活性和高效性
       • 对于新手用户，提供简单（但流程较长）的交互操作
       • 对于高级用户，提供快捷键，宏操作等
       • 充分考虑不同类型用户的使用偏好
    8. 审美感和最小化设计
       • Do not put too much, irrelevant information in Dialog boxes
       • Use standard and commonly accepted controls (sliders, buttons etc.)
       • Select fonts/sizes that are suited for screen display to maximize readability
    9. 帮助用户识别、诊断和恢复错误
       • 错误信息应该用简单的语言表达（没有代码），准确指出问题所在，并建设性地提出解决方案。
    10. 帮助和文档
        • Must provide help/manual/user-guide
        • Language and format of User-guide should use simple, standard terminology

3. 如何定义交互系统的需求和用户

3.1 交互需求的差异（5.2，5.3）

• 不论初始情形如何、项目的目标是什么，都需要讨论、提炼、澄清用户的需要、需求、以及期望
• 了解用户及其对产品的使用能力，产品相关的所有目标，产品的使用条件，和产品性能需求等
• 需求获取是项目设计的第一个阶段
  • 关于自标产品的一种陈述，它指定了产品应做什么，或者应如何工作
  • 应该是具体、明确和无歧义的
    • “完整下载任何网页的时间应少于5秒”：具体的需求“
    • 女孩们应觉得这个网站吸引人”：不具体的需求
• 交互需求的差异
  • 产品自身决定
  • 用户群体决定
• 产品特性差异
  • 功能不同
  • 场景因素
  • 非功能需求
    • 交互式设备涉及许多类型的非功能需求：如大小、重量、颜色、有效性等
  • 环境因素
    • 设备环境（物理环境）：所处的物理环境可能会影响交互范围的选择
    • 社会环境： 需要考虑协作和协调等社会因素
    • 组织环境：用户支持的质量、响应速度如何？是否提供培训资源或设施？
    • 技术环境： 产品应能运行于何种平台上？应与何种技术兼容？
• 需求验证：迭代式
  • 检查获取的需求是否真的符合用户的要求
  • 原型的优点
    • 能够给用户一个更加直观的产品形象
    • 是用户乐于接受并愿意与设计人员合作的一种需求验证方式
    • 特别对交互方面的需求验证，原型可谓最为恰当的验证工具
  • 原型的重要性
    • 用户往往不能准确描述自己的需要
    • 用户在看到或尝试某些事物后，就能立即知道自己不需要什么
    • 原型可用于检查需求获取结果是否存在偏差
    • 对设计方案也有很好的验证效果
  • 原型分类（5.6.5）
    • 低保真原型：多数项目的首选
      • 定义：与最终产品不太相似的原型；使用与最终产品不同的材料
      • 优点：简单、快速、便宜、易于制作和修改
      • 常见形式：草图、故事板、绿野仙踪法
    • 高保真原型：
      • 定义：与最终产品更为接近，使用相同的材料
      • 缺点：制作时间长，难以修改
      • 风险：用户会认为原型就是系统，开发人员可能认为已找到了一个用户满意的设计

3.2 用户的差异（5.4）

• 背景
  • 任何一款交互式计算系统其所面对的用户都是成干上万，上百万，上千万的。而这数以干万计的用户并不是完全相同的。
  • 设计人员应该意识到个体的差异并在设计中尽可能地体现这些差异。
  • 长期差异：性别、身体能力、智力
  • 短期差异：压力、疲劳
  • 年龄：随着时间变化
• 计算机操作水平的差异
  • 新手用户
    • 特点：敏感，且很容易在开始有挫折感
    • 设计要求
      • 不能将新手状态视为目标
      • 让学习过程快速且富有针对性
      • 确保程序充分反映了用户关于任务的心智模型
      • 无论什么样的帮助，都不应该在界面中固定
      • 具有向导功能的对话框在不需要帮助的时候消失
  • 中间用户：数目最多、最稳定和最重要的用户群是中间用户（或称主流用户）
    • 特点
      • 高级特性的存在会使其放心
      • 能够区分经常使用和很少使用的功能
      • 高级功能的存在让永久的中间用户放心
    • 设计需求
      • 常用功能放在用户界面的前端和中心位置
      • 工具提示（Tooltip）是适合中间用户最好的习惯用法
      • 提供高级功能特性，即便不需要
  • 专家用户
    • 特点
      • 对缺少经验的用户有着异乎寻常的影响：”专家说不好就不好”
      • 欣赏更新的且更强大的功能
      • 不会受到复杂性增加的干扰
    • 设计要求
      • 对经常使用的工具集，要能快速访问（提供快捷方式）
  • 存在的问题：程序员只创造适合专家的界面，而市场人员要求只适合新手的交互
  • 目标
    • 让新手快速和无痛苦地成为中间用户；
    • 避免为那些想成为专家的用户设置障碍；
    • 让永久的中间用户感到愉快
• 年龄差异：感知、身体和认知
  • 老年用户
    • 误解：老年人缺乏对新技术的热情
    • 事实：老年人有更多空闲时间和可花费的收入——市场巨大
    • 技术应能提供对缺失能力的支持
    • 设计必须清楚、简单并且容许出错
    • 信息访问应该采用多种方式（冗余）
  • 儿童用户
    • 他们有自己的目标、喜好和憎恶
    • 在为儿童设计交互式系统时让他们参加很重要
    • 允许多种输入模式（包括触觉或手写）
    • 通过文本、图形和声音呈现信息的冗余显示也将增强他们的体验
• 文化差异：语言、文化符号、姿势和颜色
  • 在不同的文化中符号有不同的意思
    • 勾（√）和叉（X）分别表示肯定和否定
    • 不能假设每个人都以同样的方式解释符号
  • 姿势的理解存在差别
    • 点头 vs. 摇头
  • 颜色的使用
    • 通过冗余阐明特定颜色的指定意义
    • 切忌在界面上仅以颜色作为信息区分的标志
• 健康差异
  每个国家至少有 10% 的人口有残疾
  • 视觉损伤
    • GUI 应用的增加将阻碍视觉损伤用户的使用
    • 辅以声音的应用和触觉的应用（Hearme，seeing AI）
  • 听觉损伤
    • 较视觉残疾对与图形界面交互的影响要小
    • 给听觉内容加文字描述
    • 姿势识别可作为信息输出方式
  • 身体损伤
    • 身体损伤导致的肢体控制问题，语言表达能力的损伤

3.3 理解用户 （2.4）

• 人类处理机模型 Model Human Processor
  • 最著名的信息处理模型，描述了人们从感知信息到付诸行动的认知过程
  • 三个交互式组件
    • 感知处理器：信息将被输出到声音存储和视觉存储区域
    • 认知处理器：输入将被输出到工作记忆，能够访问工作记忆和长时记忆中的信息
    • 动作处理器：执行动作
      
  • 用途
    • 人机交互本质上也可以被看作是一个信息处理过程
      • 在进行界面设计时，可将与人的信息处理能力相关的知识和理论作为参考
      • 可评估完成不同任务所需的认知要求
      • 可预测不同界面下任务的完成效果
• 人脑的记忆结构
  
  • 感觉记忆
    • 又称瞬时记忆在人脑中持续约为1秒钟
    • 作用：把相继出现的一组图片组合成一个连续的图像序列，产生动态的影像信息
  • 短时记忆
    • 感觉记忆经编码后进入短时记忆（Short-Term Memory，STM）
    • 又称工作记忆，约保持30秒
    • 储存的是当前正在使用的信息，是信息加工系统的核心，可理解为计算机的内存
    • 容量
      • 实验证明，人的短时记忆的存储容量大约为 个信息单元，这一发现被称为 理论，有时也被称为“MAGIC NUMBER”
      • 通过将信息组合成一个个有意义的单位可以帮助我们记住复杂的信息
      • 正确理解 理论
        • 界面设计时要尽可能减小对用户的记忆需求，同时可考虑通过将信息放置于一定的上下文中，来减少信息单元的数目
        • 对命令行界面设计非常有用
  • 长时记忆
    • 短时记忆 -> 长时记忆
      • 短时记忆中的信息经进一步加工后会变为长时记忆；
      • 只有与长时记忆区的信息具有某种联系的新信息才能够进入长时记忆；
    • 长时记忆的信息容量几乎是无限的
    • 启发：注意使用线索来引导用户完成特定任务在追求独特的创新设计时也应注重结合优秀的交互范型
    • 遗忘
      • 短时记忆中的信息经进一步加工后会变为长时记忆不代表长时记忆区的信息丢失了
      • 可能失去了提取信息的途径，或原有联系受到了干扰
• 视错觉
  • 知觉感受的扭曲
    • 前后景互换实际上就是视错觉的一种
  • 视错觉是不可避免的
  • 启示：对于物体的视觉感知与物体所处的上下文密切相关

3.4 格式塔（Gestalt）心理学（2.4.2）

• 认知心理学（Cognitive Psychology）
  • 有助于理解人与计算机的交互过程，同时也可对用户行为进行预测
  • 人对于外界的感知有 80% 来自于视觉获取的信息
• 格式塔心理学 (Gestalt)
  • 研究人是如何感知一个良好组织的模式的，而不是将其视为一系列相互独立的部分一 事物的整体区别于部分的组合
  • “GESTALT”一德语，“完形（configuration）”或“型式(pattern) “
  • 格式塔心理学又称完形心理学
  • 表明：用户在感知事物的时候总是尽可能将其视为一个”好”的型式
• 主要原则
  • 相近性原则
    • 空间上比较靠近的物体容易被视为整体
      • 设计界面时，应该照相关性对组件进行分组
  • 相似性原则
    • 人们习惯将看上去相似的物体看成一个整体
      • 功能相近的组件应该使用相同或相近的表现形式
  • 连续性原则
    • 共线或具有相同方向的物体会被组合在一起
      • 将组件对齐，更有助于增强用户的主观感知效果
  • 对称性原则
    • 相互对称且能够组合为有意义单元的物体会被组合在一起
  • 完整性和闭合性原则
    • 人们倾向于忽视轮廓的间隙而将其视作一个完整的整体

3.5 如何构建人物角色（5.5）

• 什么是人物角色
  • 交互设计中的问题：似乎每个调研到的用户都略有差异，如何满足所有用户的需要？
  • 人物角色 （Personas）
    • 不是真实的人
    • 基于观察到的真实人的行为和动机，并且在整个设计过程中代表真实的人
    • 是在人口统计学调查收集到的实际用户的行为数据的基础上形成的综合原型
• 人物角色的构建
  • 理想过程
    
    • 现实情况
      • 跟用户说什么
      • 提什么问题
      • 应该怎样进行对话

        ⚠️ 注意：过分依赖用户或者怀疑用户都不会带来最好的设计
        

    • 方法
      • 从构思带有少量细节的候选角色着手，将类似或相关角色归到一组，然后再填充细节

        ⚠️ 注意：要特别关注使角色之间彼此相区别的那些特征
        

• 人物角色包含的内容
  • 姓名、年龄、性别和照片。
  • 关于他们在“现实生活”中所做事情的描述。
  • 他们在产品或服务领域的经验水平。
  • 他们将如何与你的产品互动，以及他们使用产品的频率。
  • 他们执行相关任务时的目标和关注点：速度、准确性、彻底性或任何其他可能影响他们使用的需求。
  • 引用用户的话来总结该人物角色的态度。
• 人物角色的作用
  • 弹性用户
    • 产品团队的每一个人都有对用户及其需要的不同理解，这种不确定性会使产品变成“四不像”
    • 如设计医院产品时，考虑设计能够满足所有护士的产品
  • 自参考设计
    • 设计者或者程序员将其自己的目标、动机、技巧及心智模型投射到产品的设计中
    • 非程序员用户通常难以理解产品的工作方式
  • 边缘情况设计
    • 边缘情况指的是一定会发生，但通常不会发生在人物角色上的情况
    • 必须考虑边缘情况，但它们又不应该成为设计的关注点

3.6 基于人物角色和场景交互需求定义（5.6.3）

• 人物角色 + 场景剧本 → 需求
  需求定义的 5 个步骤（迭代）
  1. 创建问题和前景综述
     • 问题综述：定义了设计的目标
       • 应该简明反映需要改变的情况，来服务人物角色和提供产品给人物角色的商业组织
     • 前景综述高层次的设计视图是问题综述的倒置
       • 从用户需要开始，转向如何用设计视图来满足商业目标

         ⚠️ 注意
           - 问题和前景综述直接从研究和用户模型中获得
           - 用户目标和需求应该从焦点和次要人物角色中推导出
           - 商业目标应该从利益相关人的访谈中获得
         

  2. 头脑风暴
     • 在创建情境场景剧本时，需要摒弃头脑中先入为主的偏见和成见
     • 开展头脑风暴的原因
       • 将头脑置于“解决问题模式”
       • 不受约束且不加以评判
       • 将所有想法表达出来，并整理记录下来
     • 头脑风暴的时间
       • 不要花费太多时间
       • 当想法开始重复或出现得越来越慢时停止
  3. 确定人物角色的期望
     • 心智模型 Mental Model
       • 一个人思考或者解释事务的方法，是其对外部现实的内部表达
       • 一个人的心智模型通常是根深蒂固的
       • 人们对产品的期望和对产品工作方式的想象大部分来自于他们的心智模型
     • 界面表现模型与用户心理模型尽量匹配是非常重要的
     • 理清如下问题
       • 理解人物角色目标、经历、渴望，以及其他社会、文化、环境和认知因素
       • 人物角色在使用产品体验方面可能有的一般期待和愿望
       • 人物角色对产品行为的期待和愿望
       • 人物角色关于该领域下基本数据单元或者元素的认知
  4. 构建情境场景剧本
     • 情境场景剧本
       • 关注人物角色的活动，及其心理模型和动机
       • 将注意力集中在设计的产品中怎样能够最好地帮助你的人物角色达到目标
       • 专注于高层次的从用户角度描述的行动，做到广而浅
         • 不应描述产品或交互的细节
         • 专注于高层次的从用户角度描述的行为
       • 与人物角色不是一对一的关系
         • 大多数时候可能不止需要一个情景场景剧本，尤其是当有多个首要人物角色时，但有时单个首要人物角色也可能有两个或者多个不同的使用场景。
  5. 确定需求
     • 直接提取需求
     • 分别提取数据和功能需求
       • 数据需求：必须在系统中被描述的对象和信息
       • 功能需求：系统对象必须进行的操作
       • 其他需求：开发时间表、产品价格、重量等

4 如何开展交互设计

4.1 交互设计的活动和步骤（6.2）

• 过早地把重点放在小细节、小部件和精细的交互上会妨碍产品的设计
  • 先站在一个高层次上关注用户界面和相关行为的整体结构（设计框架）
• Allan Cooper 定义的交互框架
  1. 定义外形因素和输入方法
     • 外形因素：设计什么样的产品
     • 产品输入方法
  2. 定义功能和数据元素
     • 在需求定义阶段确定的，需要按照用户界面的表现语言来描述
     • 数据元素
       • 交互产品中的基本主体，是能够被用户访问和操作的基本个体
       • 如相片、电子邮件、订单
       • 数据元素应符合人物角色的心理模型
       • 考虑数据元素之间的关系也很有用
     • 功能元素
       • 对数据元素的操作及其在界面上的表达
       • 对数据元素操作的工具，以及输入或者放置数据元素的位置
  3. 决定功能组合层次
     • 目的：更好地在任务中和任务间来帮助促进任务角色的操作流程
     • 需考虑的问题
       • 哪些元素需要大片的视频区域
       • 容器如何组织才能优化工作流
       • 哪些元素是被一起使用的
         • 一个过程的多个步骤
       • 产品平台、屏幕大小、外形尺寸和输入方法的影响
  4. 勾画大致的设计框架
     
     • 对界面布局进行粗略的描述最初阶段：界面的视觉化工作应该非常简单
     • 方块图
       • 用粗略的方块图来表达并区分每个视图
       • 方块图对应窗格、控制部件为每个方块图添加上标签和注解
       • 为每个方块添加上标签和注解
     • 注意：不要被界面上某个特殊区域的细枝末节分散了精力
  5. 构建关键情境场景剧本
     • 描述了人物角色最频繁使用界面的主要路径
       • 重点在任务层
       • 举例：电子邮件应用中关键线路的活动主要包括读和写邮件，而不是配置邮件服务器
     • 注意事项
       • 必须在细节上严谨地描述每个主要交互的精确行为，并提供每个主要线路的走查
       • 可使用低保真草图序列的故事板进行描述
  6. 通过验证性的场景剧本来检查设计
     • 验证性的场景剧本不用具备很多细节
       • 但包含一系列“如果怎样，将怎样”的问题
       • 目标是对设计方案指点，并根据需要进行调整
     • 三种验证性的场景剧本
       • 关键线路的变种场景剧本
         • 关键途径的替换
       • 必须使用的场景剧本
         • 必须要执行但又不是经常发生的情况
       • 边缘情形使用场景剧本
         • 非典型情形下产品必须具备，但不太常用的功能
  • 视觉设计框架
    • 确定界面使用的颜色、风格、小组件 （widget）
    • 整体的外形尺寸等
  • 工业设计框架
    • 原型产品的构建
    • 输入方法方面的研究工作

4.2 如何简化交互设计（6.3）

• 简化设计的四个策略

  1. 删除：（最明显的简化设计方法）删除不必要的
     删除什么？：

     • 功能相关：
       • 按照优先级对功能进行排序：关系到用户日常使用体验的功能最有价值
       • 开发团队有限，要尽力保证这部分功能的正常交付
       • 以用户为中心并不意味着要满足所有用户的需求，并获取用户的欢心。而是能给大部分用户一个良好的体验：通过人物角色（Personas）确定
       • 删除可能出现错误的情况
     • 删除视觉混乱
       • 通过删除多余文字，能加速用户的阅读速度，还能让重要的内容变得“水落石出”。
       • 通过删减界面上可能引起视觉混乱的情况，也可以有效减少用户必须处理的信息，从而集中主意力在真正重要的内容上，使得“数据墨水率〞越来越高。
       • 方法：
         • 使用空白或轻微的背景色对界面内容进行分割，少使用线条和各种强调效果；
         • 合理控制信息的显示层次，减少界面元素的大小和形状变化等。

       ⚠️ 注意
         - 问题和前景综述直接从研究和用户模型中获得
         - 用户目标和需求应该从焦点和次要人物角色中推导出
         - 商业目标应该从利益相关人的访谈中获得
     

  2. 组织：组织要提供的

     按照有意义的标准对界面组件进行分组：最快捷的简化设计方式

     • 分块
       • 通过分块可以把繁琐的功能组织成清晰的层次结构
       • 格式塔心理学： 法则
       • 名词：可以按字母表、时间或空间顺序排列的清单
     • 清晰的信息分类标准
       • 切忌从开发人员的视角进行思考
         • 以免设计出不符合用户视角的难以使用的产品
     • 利用不可见的网格进行组织
       • 布局对于设计能否让用户感觉简单十分重要
     • 搜索与页面组织
       • 错误观点
         • 既然有搜索，那么设计者不需要花费过多时间对界面内容进行组织
       • 实际情况
         • 用户只有在缺乏有效导航的情况下才会使用搜索
         • 实现高效搜索功能比组织页面内容困难得多
       • 结论
         • 先对内容进行有效组织
         • 然后再考虑如何设计搜索

       ⚠️ 注意：千万不要被自己规划图中清晰的线条和整洁的布局所迷惑
     

  3. 转移：各司其职

     • 目的：
       • 将功能以最恰当的方式实现
       • 可以是不同设备或平台之间的转移
       • 也可能是设备和用户之间的转移
     • 设备之间的转移
       • 开发不同终端产品时，没有必要完全复制另一端的所有功能
     • 向用户转移
       • 要求用户以计算机易于处理的方式去制定一个精确计划，则很容易使得项目失败
         • 搞清楚工作适合交给计算机，什么工作适合留给用户

4.3 设计体贴的软件（6.5）

• 如何做一个体贴的产品：
  • 效仿一个关心他人的人是如何和别人打交道的
• 体贴的软件是自信的
  • 当用户提出请求时，体贴的软件不仅不应该怀疑用户的请求，同时应该为可能发生的错误做好准备
    • 比如恢复已经删除的文件等
• 软件使用与人的记忆|
  • 为了能够使用软件完成任务，必须记住的两类信息或知识
    • 和软件如何操作相关的内容
      • 比如应当选择哪个命令或操作、文件存在哪个目录、如何去执行某个操作、其对应的快捷键是什么等
    • 和该任务所需的领域知识相关
      • 比如特定编程语言的语法规则、可供使用的标准库函数，这些函数的参数和返回值是什么；普通用户必须记住的网站名称或地址等。
• 体贴的软件会怎么做
  • 赋予产品了解用户行为的能力，记忆并灵活地根据用户之前的行为显示信息和功能
  • 一个简单的原则
    • 如果信息值得用户输入，那么就值得程序记住它们，并在下一次使用时作为默认值
    • 如果这不是用户所希望的，可以让用户纠正
• 减少用户的等待感
  • 今天的用户大多是缺少耐心的消费者，作为软件设计人员应当设法减轻用户的等待感
    • 可以以某种形式的反馈让用户了解操作进行的进度和状态
    • 或者以一种渐进的方式来把当前已完成的处理结果提供给用户
    • 或者给用户分配一些任务，从而分散他的注意力
• 出错信息的设计
  • 用户希望避免错误造成的结果，而不是错误信息
  • 好的出错信息应当遵循以下四个简单原则
    1. 使用清晰的表达语言，而非难懂的代码
    2. 语言应当精炼准确，而非空泛而模糊
    3. 对用户解决问题提供建设性的帮助
    4. 出错信息应当有好，不要威胁或责备用户
• 错误回复机制
  • 允许用户撤销错误命令产生的结果
  • 允许编辑并重新提交以前的命令，而不用从头输入等
• 设计提示
  • 设计的时候更多站在用户的视角思考
  • 通过参与式设计获取用户对特定任务的表征
  • 多次迭代的用户测试

4.4 有用的交互设计模式（6.6）

• 交互设计模式：
  • 不仅仅涉及结构和元素组织，还关注响应用户活动的动态行为与变化

    💡 交互设计模式“是从过去已证明成功的实例中学习的”，是“获得以及重新应用已有知识的一种方案”。 ——Alan Dix
  

• 模式的讨论
  • 设计模式能够帮助提供有价值、有用的设计思路
• 模式不是即拿即用的商品
  • 每一个设计仍然需要创造性和直觉

5. 如何对交互性能进行评估

5.1 为什么要进行评估（10.2）

• 邀请用户进行评估的目的不是设法理解用户，而是特定用户在特定环境背景下如何使用系统来执行特定任务。
• 有一些设计人员错误地认为他们自己能够准确地了解用户工作的方式，然而在实际观察用户操作时就会发现，用户可能会很有创意，并且使用设计人员从未考虑过的方式来使用系统。
• 评估有助于达成的目标
  • 评估系统功能的范围和可达性
    • 不仅包括具有合适的功能，也包括使用户能清晰地意识到需要执行任务的一系列行为，还包括将系统的应用与用户对任务的期望相匹配
  • 评估交互中用户的体验
    • 特别对休闲和娱乐系统而言，这一目标就更为重要
  • 确定系统的某些特定问题
    • 如用户是否能准确定位到特定菜单项，页面文字显示是否具有良好的可读性等
• 原则：
  • 最具权威性的评估不应该依赖于专业技术人员，而应该依赖于产品的用户：对软件交互性能的评估，主要应有用户来完成
  • 评估与设计应结合进行
    • 交互评估是一个过程，这个过程早在产品的初始阶段就开始了。因此一个软件在设计时反复征求用户意见的过程应与交互评估的过程结合起来进行。在设计阶段反复征求意见的过程是评估的基础，不能取代真正的评估。
    • 仅靠用户最后对产品的一两次评估，是不能全面反映出软件的可用性的。
  • 交互性能评估应该在用户的实际工作环境下进行
    • 交互评估不能靠发几张调查表，让用户填写完后，经过简单的统计分析就下结论
    • 必须在用户实际操作以后，根据其完成任务的结果，进行客观的分析和总结
    • 如果能够在用户的实际工作环境中开展测试可能会得到更为实用的结果
  • 要选择有广泛代表性的用户
    • 参加测试的人必须具有代表性

      ⚠️ 注意：
          - 尽早测试、经常测试
          - 快速但存在瑕疵的测试好过什么都没有做的测试
  

5.2 评估实验的规划（10.5）

• DECIDE 评估框架
  1. 确定（Determine）：评估需要完成的总体目标
     • 检查设计人员是否理解了用户需要；
     • 确保最终界面满足一致性要求；
     • 调查新技术的引入对用户工作的影响；
     • 决定如何修改已有产品的界面，以提高可用性。
  2. 发掘（Explorer）：需要回答的具体问题
  3. 选择（Choose）：用于回答具体问题的评估范型和技术
     • 定性数据（陈述性数据）
     • 必须权衡实际问题和道德问题
       • 最适合的技术可能成本过高，或所需时间过长，或不具备必要设备和技能
     • 可结合使用多种技术
       • 不同技术有助于了解设计的不同方面不同类型数据可从不同角度看待问题组合有助于全面了解设计的情况
  4. 标识（Identify）：必须解决的实际问题，如测试用户的选择
     • 明确实际问题
       • 用户：先做小规模测试确定用户技能所属的用户群
         • 类型：
           • （如新手和专家）具备不同技能的用户
           • 年龄
           • 性别
           • 文化
           • 教育程度
           • 个性
         • “如何让用户参与“
           • 稍事休息和走动
           • 努力消除用户的焦虑
           • 支付报酬，有礼貌
           • 在任务执行前，安排用户熟悉系统
       • 设施及设备
         • 所有实验设备运转正常、电量充足、项目期限以及经费预算
       • 期限及预算
       • 评估人员的专门技能
  5. 决定（Decide）：如何处理有关道德的问题
     • 应保护个人隐私
       • 除非获得批准，书面报告不得提及隐私（姓名、健康、雇佣情况、教育、财务、居所）
       • 评估前签署协议书（IRB）
     • 指导原则
       • 向参与者明确说明研究的目的以及参与者需要做的工作。
       • 向用户说明他们提供的地址、财务、健康或其他敏感资料属于机密。
       • 向用户说明测试的目的是对软件进行评价而不是对用户个人进行测试。
       • 向用户说明关于实验的任何特殊要求。
       • 实验人员应该告知用户自身与待测系统没有关系。
       • 尽量不摄录用户的面部，以减轻他们对录像的忧虑
       • 欢迎用户提问
       • 在可能情况下，应支付用户费用以建立正式的合作关系，并明确双方的义务和责任。
       • 说明参与测试是自愿行为。
       • 避免在引用和描述时无意中透露用户身份。
       • 征得用户同意以后才能引用用户的话语，且引用过程只能以匿名方式进行。在正式报告发布之前，应为用户提供报告副本
       • 牢记“己所不欲，勿施于人”的一般原则。
  6. 评估（Evaluate）：解释并表示数据
     • 可靠性
     • 有效性
     • 偏见
     • 适用范围
     • 环境影响
       • 霍桑效应（Hawthorne Effect）
         它描述了在进行观察或实验时，研究对象会表现出与他们平常行为不同的行为。具体来说，霍桑效应通常表现为当人们知道自己正在被观察或参与实验时，他们可能会改变他们的行为，通常是表现得更加积极或更加注意，以满足观察者的期望或要求。
• 小规模试验：可能会有多次试验
  • 测试评估计划
  • 避免问题：
    • 含糊不清的指令
    • 错误的时间估计
    • 模糊的任务完成标准
    • 问卷中带有误导性的问题
    • 设备使用中的一些问题
    • 练习访谈技巧

5.3 评估范型及选用（10.3）

• 评估范型（Evaluation Paradigm）

  • 在使用具体的评估方法前通常需要先考虑最适宜的评估范型，同时需要注意到每种范型都有自身的长处和短处，且并不一定适用于所有类型的系统。

  • 分类

    • 快速评估（Fast Evaluation）：可在短时间完成
      • 设计人员非正式地从用户或顾问获得反馈信息，以验证设计构思是否符合用户需要，以及是否能够令用户满意。
      • 适用于所有阶段
        • 设计初期：与用户进行非正式接触了解用户对新产品的意见
        • 设计末期：了解用户对图标设计的看法
      • 得到的信息通常是非正式、叙述性的
        • 口语
        • 书面笔记
        • 草图
        • 场景
    • 可用性测试（Usability Testing）
      • 基于特定任务场景记录用户的出错次数、完成任务的时间等
      • 根据这些观察数据计算执行任务的时间、出错次数，甚至分析用户的行为及其原因
      • 基本特征
        • 实验是在评估人员的密切控制之下实行的
        • 用户不会受到干扰
      • 主要任务：获得用户执行情况的量化数据
    • 现场研究（实地研究，Filed Study）
      • 基本特征
        • 在自然工作环境中进行
      • 目的
        • 理解用户实际工作情形以及技术对他们的影响
      • 优势：
        • 告诉人们是如何真正工作的
      • 缺点
        • 难以根据实际情况来控制实验过程
        • 难以侧重于任务变量之间的关系
      • 适用范围：
        • 往往用于非安全攸关的系统
    • 预测性评估（Prediction Evaluation）
      • 预测性评估中，一方面评估专家们可以根据自己对典型用户的了解来预测产品中可能存在的可用性问题；另一方面也可以基于已有理论模型得出评估结论。
      • 基本特征
        • 用户可以不在场
        • 整个过程快速、成本较低
      • 缺点
        • 专家可能存在个人偏见
    • 各种评估范型的特征

    评估范型	快速评估	可用性测试	现场研究	预测性评估
    用户角色	自然行为	执行测试任务集	自然行为	通常不参与
    控制权	评估人员实施最低限度控制	评估人员密切控制	评估人员与用户合作	评估人员为专家
    评估地点	自然工作环境或实验室	实验室	自然工作环境	类似实验室的环境，通常在客户处进行
    适用情形	快速了解设计反馈。可使用其他交互范型的技术，如启发式评估	测试原型或产品	常用于设计初期，以检查设计是否满足用户需要 ，发现问题，发掘应用契机。	使用启发式评估的原型测试，可在任何阶段进行；模型可用于评估潜在设计的特定方面
    数据类型	通常是定性的非正式描述	定量数据，有时是统计数据。可采用问卷调查或访谈搜集用户意见	应用草图、场景、例证等的定性描述	专家们列出问题清单，由模型导出量化数据（如两种设计的任务执行时间）
    反馈到设计	通过草图、例证、报告	通过性能评估、错误统汁报告等为未来版本提供设计标准	通过描述性的例证、草图、场景和工作日志	专家列出一组问题，通常附带解决方案建议。为设计人员提供根据模型计算出的时间值
    基本思想	以用户为中心，非常实用	基于试验的实用方法，即可用性工程	可以是客观观察或现场研究	专家检查以实用的启发式原则和实践经验为基础，采用基于理论的分析模型

• 评估技术

  • 观察用户
    • 用途
      • 有助于确定新产品的需求
      • 也可用于评估原型
    • 输出：笔记、录音、录像和交互日志
    • 挑战：
      • 不干扰用户的前提下观察用户
      • 分析大量数据
  • 询问用户意见
    • 访谈和调查问卷
  • 询问专家意见
    • “角色扮演〞的方法，模拟典型用户执行任务的情况，并从中找出潜在问题。
    • 优势：
      • 成本较低
      • 快速完成
  • 用户测试
    • 通过测量用户执行任务的情况，比较不同的设计方案通常在受控环境中进行
  • 基于模型的分析和评估
    • 用于在设计初期（即制作复杂原型之前）预测设计的有效性，找出潜在的设计问题。
    • 常用技术
      • GOMS 模型
      • 按键模型

• 常用组合

  • 启发式评估+边做边说
  • 排除显而易见的可用性问题重新设计后，经用户测试，反复检查设计的效果
  • 选择理由
    • 经验性评估不需要用户参与就可以发现并消除系统或产品中存在的许多可用性问题。
    • 这两大类可用性评估方法所发现的可用性问题有明显的不同，这意味着两种方法可以互补而不会重复。
  • 访谈和问卷调查
    • 通过对一小部分用户进行开放式访谈，来明确定义封闭式问卷中的具体问题

5.4 评估的对象（5.6.5）

• 在开发过程中进行评估时会先使用某种原型然后在系统到一定程度后再对整个系统进行评估
• 纸质原型法非常经济适用于设计的初期阶段
  • 收集到的数据一般是定性而非定量的， 其结果只是指导设计
• 基于计算机的原型
  • 目前有很多工具可以在多各层次来构建原型，包括从草图原型到交互式的工作原型。
• 原型分类
  • 渐进式
    • 最初的原型在每次开发迭代后，都会向着最终可交付版本不断靠近。
  • 变革式
    • 当前原型在每次迭代开发周期结束时都会被丢弃，并开发出新的原型。
• 低保真原型
  • 定义：与最终产品不太相似的原型；使用与最终产品不同的材料
  • 优点：简单、快速、便宜、易于制作和修改
  • 常见形式：草图、故事板、绿野仙踪法（Wizard-of-Oz）
• 高保真原型
  • 定义：与最终产品更为接近，使用相同的材料
  • 缺点：制作时间长，难以修改
  • 风险：用户会认为原型就是系统，开发人员可能认为已找到了一个用户满意的设计
• 构建原型的成本因其复杂程度以及评估的周期而不同，如同在实验室内开展的用户测试和在现场开展的测试成本就有很大不同。但可以肯定的是，无论采取哪种评估方法，原型技术都有利于得到一个好的结果，并且适用于设计过程的很多阶段。

5.5 通过“看”来评估（11.2）

• 观察的作用
  • 观察用户怎样工作：获得数据
  • 重要性：用户并不是总是能够客观和完整的对自己使用产品的实际情况进行描述
  • 基于观察数据，可以分析用户在做什么并统计用户花在任务各个部分的时间，以及情绪反应
• 观察的优点
  • 适用于产品开发的任何阶段
    • 初期：理解用户的需要
    • 开发过程：检查原型
    • 后期：对最终产品进行评价
  • 现场观察是发现同使用环境有关问题的最佳手段
• 观察涉及看和听两个方面

5.6 通过“问”来评估（12.2，12.3， 12.4）

• 尤其适用于客观上较难度量的与用户主观满意度和可能的忧虑心情相关的问题。

• 问卷与访谈

  • 快速评估
  • 可用性测试
  • 现场研究

  问卷调查	搜集大量用户的意见从中找出普遍性的意见
  访谈	方便、快捷，若用户没有时间完成问卷，就可以考虑使用访谈方法

• 在设计问卷的过程应考虑

  • 需要什么信息？
  • 如何分析问卷？

• 为了减轻回答问题人员的负担鼓励用户提高回答率，应尽可能应用有限的问题

• 注意问题的先后顺序

  • 先提出一般化容易回答的问题再提出较难回答的具体问题

• 对征求用户意见的问题

  • 应提供一个“无看法”的答案选项
  • 避免使用专业术语等

• 访谈

  • 策略
    • 先进行小规模试验
    • 目标是消除问卷设计中的任何问题
    • 问题是否可以理解、结果是否是所期望的、以及问卷是否是期望的信息获取方式
    • 在最后版本发出以前，可以改变表述（并重新测试）
  • 避免
    • 设计问题时注意不要暗示答案
    • 访问人的肢体语言对受访人也有较大的影响

• 数据处理

  • 数据的走向和模式
  • 数量较大时，应进行数据的标准化，并计算百分比，以便比较不同组别的调查结果

• 焦点小组是集体访谈的一种形式

  • 非正式的评估方法
  • 6-9 个典型用户组成
    • 例子：大学网站评估——行政人员 + 教师 + 学生三个分别的焦点小组
  • 主持人工作
    • 列清单 + 保证不离题积极讨论 + 结果分析
  • 存在风险
    • 用户真正想要的东西并不一定等于他表达出来的东西
    • 避免风险：可以让用户接触在焦点小组中所可能讨论技术的具体实例。

• 理想情况下

  • 评估应该贯穿于整个设计过程中

• 实际过程中

  • 规律性地进行用户测试的费用是很高的
  • 寻找用户并不容易，并且很难从不完全的设计和原型获得交互经历的精确评估。

• 询问专家

  • 角色互换
  • 压力测试
  • 穷尽测试

5.7 启发式评估（12.5）

• 启发式评估是分析界面可用性的一种相对非正式的方法

• 具体方法

  • 每位专家以他们的方式独立地使用用户界面，记录符合启发式评估标准的设计。

• 步骤

  阶段	步骤
  准备（项目指导）	a）确定可用性准则。
  	b）确定由3~5个可用性专家组成的评估组。
  	c） 计划地点、日期和每个可用性专家评估的时间。
  	d） 准备或收集材料，让评估者熟悉系统的目标和用户。将用户分析、系统规格说明、用户任务和用例情景等材料分发给评估者。
  	e）设定评估和记录的策略。是基于个人还是小组来评估系统？指派一个共同的记录员还是每个人自己记录？
  评估（评估者活动）	a） 尝试并建立对系统概况的感知。
  	b）温习提供的材料以熟悉系统设计。按评估者认为完成用户任务时所需的操作进行实际操作。
  	c）发现并列出系统中违背可用性原则之处。列出评估注意到的所有问题，包括可能重复之处。确保已清楚地描述发现了什么？在何处发现？
  结果分析（组内活动）	a） 回顾每个评估者记录的每个问题。确保每个问题能让所有评估者理解。
  	b）建立一个亲和图（又称KI法“或A型图解法），把相似的问题分组。
  	c） 根据定义的准则评估并判定每个问题。
  	d）基于对用户的影响，判断每组问题的严重程度。
  	e）确定解决问题的建议，确保每个建议基于评估准则和设计原则。
  报告汇总	a） 汇总评估组会议的结果。每个问题有一个严重性等级，可用性观点的解释和修改建议。
  	b）用一个容易阅读和理解的报告格式，列出所有出处、目标、技术、过程和发现。评估者可根据评估原则来组织发现的问题。一定要记录系统或界面的正面特性。
  	c）确保报告包括了向项目组指导反馈的机制，以了解开发团队是如何使用这些信息的。
  	d） 让项目组的另一个成员审查报告，并由项目领导审定。

• 关于评估专家的人数

  • 通常情况下，只需要3~5名专家来做启发式评估，给出有用的结果。
  • 非硬性规定：很多人也就认为这是对所有评估类型的硬性规定，这种理解其实是完全错误的。
  • 评估所需要的用户数量在很大程度上取决于最终用户群体的多样性。

• 启发式评估的优点

  • 不涉及用户，所以面临的实际限制和道德问题较少，成本相对较低，不需要特殊设备，而且较为快捷。又被称为“经济评估法”

• 启发式评估的缺点

  • “专家每找到一个真实的可用性问题，将发出约一个假警报，忽略大约半个问题”
  • 专家找到的问题，可能并不是普通用户面对的问题

5.8 通过“用”来评估（13.2）

• 用户测试
• 明确用户
  • 用户的组织
  • “between-subjects”（被试间设计）
    1. 每个用户只进行一种自变量的实验
    2. 要求有足够多的测试用户，实验结果可能会受到个别参与者的影响
  • “within-subjects”（被试内设计）
    1. 每位用户都参与了所有的自变量实验
    2. 需避免“顺序效应”：参与者在执行前一组任务时获得的经验不会影响后面的测试结果
• 明确测试任务
  • 通常在设计实验时我们都会选取对于大多数用户通常都会执行的任务，即所谓的典型任务
• 度量数据
  • 定量数据
    • 完成任务的时间
    • 停止使用产品一段时间后，完成任务的时间
    • 执行每项任务时的出错次数和错误类型
    • 单位时间内的出错次数
    • 求组在线帮助或手册的次数
    • 用户犯某个特定错误的次数
    • 成功完成任务的用户数
  • 定性数据
    • 例如：用户为什么使用菜单会产生问题
      • 通过访谈或问卷调查获得

6 交互设计模式与理论

6.1 如何对用户任务进行分解（5.6.4）

• 任务分析
  • 一种用来描述用户的任务以及子任务、这些任务的结构和层次，以及执行任务时用户已经具有的或是需要具有的知识的方法。
• “层次化任务分析（HTA）”是人类工效学领域中最广泛使用的方法。

  • 目标/任务 — > 子目标/子任务

  • 采用层次图结构或表格文本格式表示

  • 每个目标以及子目标都有一个描述如何实现该目标的计划

    • 子目标序列
    • 并发需求
    • 行为对任务绩效的指导等方面的信息

  • 细分的终止规则

    • 对于不能再进一步细分的子目标，在方框下面画一条横线，表示已经不能再细分。

  • 不能细分的任务

    • 包含复杂机械响应的子任务
      • 如”移动鼠标”
    • 涉及内部决策的子任务
      • 如“选择感兴趣的商品”

  • 用途

    • 手册和教学
    • 需求获取和系统设计
      • 用来指导新系统的设计
      • 任务分析本身不是需求获取
      • 有助于需求的完整表达
    • 详细的接口设计
      • 如果知道某个任务频繁执行，就会让用户能够很容易地按照合适的顺序执行子任务
      • 如果频繁改变状态，在不同的菜单之间移动将是不可接受的

        ⚠️ 注意：
            - 层次化任务分析非常耗时，且不完善
            - 会给出一个有用的、有代表性的描述
            - 但没有说明如何去收集那些我们希望表达的任务信息
    

  • 优点

    • 有经验的分析师能够使用HTA相对快捷地提供有用的设计信息，可在早期使用

  • 缺点

    • 分析结果的展现方式不容易和软件工程师所用的表示方式联系起来

6.2 如何预测任务的完成时间（8.2）

• GOMS 模型
  • 主流的支柱之一
    • 基于人类处理机模型
    • 关于人类如何执行认知一动作型任务以及如何与系统交互的模型
    • 采用“分而治之”的思想，将一个任务进行多层次的细化
  • 四元素：用于描述用户行为
    • 目标（goal）
      • 用户执行任务最终想要得到的结果
      • 高层次目标如“编辑文章”
      • 低层次目标如“删除字符”
      • 高层次目标可以分解为若干个低层次目标
    • 操作（operator）
      • 任务分析到最底层时的行为，是用户为了完成任务必须执行的基本动作（如双击鼠标左键、按回车键等）
      • 操作不能再被分解
        • 在GOMS模型中它们是原子动作
      • 假设用户执行每个操作的时间是上下文无关的
        • 操作花费的时间与用户正在完成什么样的任务或当前的操作环境没有关系
    • 方法（method）
      • 描述如何完成目标的过程，用于确定子目标序列及完成目标所需要的操作
    • 选择规则（selection rule）
      • 确定当有多种方法时选择和方法
      • GOMS认为方法的选择不是随机的
  • 分析
    • 侧重于描述无错误的、专家级的行为
    • 可以用于评价采取多种策略来执行相似任务的情形
    • 常用于电话和全球定位系统的交互预测
      • 用户的相关知识和用户界面需要尽可能统一
      • 但专家级水平的操作人员执行任务的方式可能不同，此时适用
        GOMS模型进行分析
    • 对于多任务或并行任务的分析存在困难
• 击键层次模型（KLM：Keystroke-Level Model）
  • GOMS模型的一个简化版本，也是一种认知任务分析方法
    • 可以快速而近似地计算出用户需要多长时间执行一个任务单元
  • 分析
    • 同GOMS模型一样，KLM假定了一个简单的环境
      • 在一个时间专注于一个维务
      • 一个完全定制的界面
      • 无交叉的目标、无干扰、无差错、专家级的熟练行为等
      • 无需担心任务之间的选择关系

6.3 如何预测指定任务的执行效率（8.2.3）

• 组件与交互
  • 交互式系统界面中常常含有各种各样的交互组件
    • 用户在与系统交互的时候需要频繁地在屏幕范围内移动鼠标以激活屏幕组件
    • 用户访问组件的时间对系统的使用效率是至关重要的
• Fitts 定律
  • 基于对人类的运动特征、运动范围和运动准确性等因素的分析
  • 能够预测某种定位设备指向某个目标所需时间
  • 可指导设计人员设计按钮的位置、大小和密集程度
  • 对图形用户界面设计具有显著指导意义
  • “最健壮并被广泛采用的人类运动模型之一”
  • 定律认为
    • 如果一个任务的困难程度可等价于“信息”，那么用户完成任务的速率即可等价于人类信息处理系统的“信息量”
    • 换言之，如果我们知道一个动作的难度和执行该动作的速率，通过计算难度除以速率的商，就可以得到表示人类执行能力的值
    • 即：性能指数IP、任务难易ID和运动时间MT之间存在如下关系
      IP (Index of Performance) = ID (Index of Difficulty) / MT (Movement Time)
    • MacKenzie改写为：
      
      A 是振幅（与目标的距离），W 为目标宽度
    • 更好地符合观察数据
    • 精确模拟支撑 Fitts 定律的香农信息论
      
      常数a和b来自对实验数据的线性回归
  • 移向屏幕的某个目标所用的时间与两个因素有关
    • 设备当前位置和目标位置的距离（A）。距离越长，所用时间越长；
    • 目标的大小（W）。目标越大，所用时间越短
  • 性能指数IP
    • 也被称作吞吐量TP（Throughput）：TP = ID / MT
  • 建议：
    • 大目标、小距离具有优势
      • 对选择任务而言，其移动时间随到目标距离的增加而增加，随目标的大小减小而增加
    • 缩短到达目标的时间有两种措施
      • 缩短当前位置到目标区域的距离
      • 增大目标大小以缩短定位时间
  • 适用范围
    • 可用于指导桌面应用开发中的屏幕布局
    • 对基于移动设备的交互系统开发同样具有指导作用