人机交互

HCI human computer interaction

凡是与人交互的计算系统都有人机交互，包括手机、电脑、微波炉

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

中国人机交互圈

  1. CCF 学界
  2. UXPA 工业界

用户体验

user Friendly –> usability –> user exprience

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

设计和开发人员易犯的错误

  1. 假设对于技术的使用方式的理解可以通过他们的自主思考实现，即想象这个技术是如何被使用的
  2. 认为每个人都是相同的

以用户为中心的设计方法

本科人机交互研究的内容

交互设计方法

  1. 评估技术
  2. 示例系统和案例学习
  3. 设计方法
  4. 实现技术和工具

命令行交互–基于记忆的交互

图形界面–基于识别能力

人机交互的发展历史

一大特点：新的交互方式出现后，旧的交互方式往往并不会消失

1945 Vannervar Bush “As we may think” Memex

1960 人机共生

1970 施乐公司 Palo Alto研究中心

1980s Interface -> Interaction

1990s 智能化交互、多通道交互…

四个阶段

  1. 批处理阶段（打纸袋，插硬件）
  2. 联机终端时代
  3. 图形用户界面时代

人机交互中常见的问题

  • 不要隐藏关键的信息
  • 将操作放在正确的地方
  • 正确的命名

EEC模型

stateDiagram
    形成目标 --> 形成意图
    形成意图 --> 明确动作
    明确动作 --> 执行动作
    执行动作 --> 外部世界: 执行阶段
    外部世界 --> 感知系统状态: 评估阶段
    感知系统状态 --> 解释系统状态
    解释系统状态 --> 评估输出
    评估输出 --> 形成目标

执行隔阂： 我想这么做，但是系统没有提供我想要的（e.g 找不到确认按钮）

评估隔阂：系统给了这个操作并且我执行了，但是我不能确定事务的状态（e.g 支付完成后既没有支付成功也没有支付失败）

扩展EEC模型

可用是用户使用的基础

可用性目标：目的是为交互设计人员提供一个评估交互式产品和用户体验各方面的具体方法

  • 易学性：“十分钟法则”
  • 易记性：学会以后能够迅速回想起使用方法
  • 效率高：使用这个系统后应该比不用这个系统好
  • 效用高：提供了正确的功能，能让用户做他们需要做的事
  • 安全性：避免用户陷入危险（e.g 减少危险功能被直接启动的风险）

用户体验目标：多样性的用户体验目标，涵盖一系列主观感受

体验和可用性的关系

主观vs客观

矛盾性

  • 大家喜欢玩有挑战性的游戏
  • 用锤子砸地鼠比用鼠标点更累但是更有趣

有些可用性和用户体验目标是不兼容的

  • 设计一个安全又有趣的过程控制系统是不可能或不可取的

认识和理解可用性和其他用户体验目标之间的关系是交互设计的核心！

四种主要技术

  • 完整的可用性工程过程
    • 了解用户
    • 竞争性分析
    • 设定可用性目标
    • 用户参数的设计
    • 迭代设计
    • 产品发布后的工作
  • 简化
    • 用户和任务观察
      • 了解产品的目标用户是可用性工程的第一个步骤
      • 注意
        • 直接与潜在用户进行接触
        • 不要满足于间接的接触和道听途说
        • “你”不是用户！
    • 场景
    • 简化的边做边说
      • 让真实用户在使用系统执行一组特定任务的时候，讲出他们的所思所想
      • 最有价值的单个可用性工程方法
      • 可了解用户为什么这样做，并确定其可能对系统产生的误解
      • 实验人员需要不断地提示用户，或请他们事先观摩
    • 启发式评估
      • 专家以角色扮演的方式模拟目标用户
      • 5名专家大致能发现80%的问题，被认为是最恰当的可用性测试用户数量
      • 启发式原则

设计规则

  • 说明
    • 不是完美的，有的还相互矛盾
    • 基本来自经验
    • 必须和实际情况相结合
  • 基本规则
    • 可学习性
    • 灵活性
    • 健壮性
  • 黄金规则
    • 尽可能保持一致
    • …
  • 十条启发式规则
    • 系统状态的可见度
    • 系统和现实世界的吻合
      • 让用户听得懂
    • 用户享有控制权和自主权
    • 一致性和标准化
      • 不要搞得像是好多设计师设计的
    • 避免出错(预防并处理错误)
    • 依赖识别而非记忆
    • 使用的灵活性和高效性
    • 帮助文档
    • 简单/最小化设计
    • 帮助用户及时识别诊断恢复错误

评估

  • 评估应该依赖于产品的用户
  • 评估与设计应结合进行
  • 评估应在用户的实际工作任务和操作环境下进行
  • 要选择有广泛代表性的用户

快速评估：找到用户就问

可用性测试

  • 20c80s主导方法
  • 评测典型用户执行典型任务时的情况
  • 问题：测试用户数量通常较少（最佳用户数5-12，一般研究得有20+）。不适合进行细致的统计分析

实地研究（feild research）

基本特征：在自然环境中工作

目的：理解用户实际工作庆幸以及技术对他们的影响

作用：

  • 探索新技术的应用契机
  • 确定产品的需求
  • 促进技术的引入
  • 评估技术的应用

重难点

  • 如何不对受试者造成影响
  • 控制权在用户，很难预测即将发生和出现的情况

预测性评估

  • 研究人员通过想象或对界面的使用过程进行建模
  • 基本目标：
    • 用户可以不在场
    • 整个过程快速、成本较低

评价指标

  • 提供的信息
  • 相应的及时性
  • 干扰程度
  • 所需资源

实验假设

零假设

假设不同条件下没有差异

备择假设

一般和零假设相反

因变量自变量

自变量是研究人员感兴趣的因素

因变量随着自变量改变发生变化

寻找自变量的变化是否会引起因变量的变化，以及如何引起因变量的变化

研究必须可以复现

实验条件：我们需要比较的不同技术、设备或程序

试验单位：我们应用实验条件的对象

分配方式：将实验单位分配到不用实验条件的方式，可以掷骰子，可以用随机数表

实验设计

真正的实验

  • 以至少一个可检验的研究假设为基础，并旨在验证它
  • 通常至少有两种条件（实验条件和对照条件）或组（实验组和对照组）
  • 因变量通常使用定量测量
  • 通过各种显著性检验对结果进行分析
  • 具备不同的参与者样本

如果没有使用随机分配但是有对照组，只能算准实验，如果对照组都没有，那么就不是实验了

绿野仙踪法：在控制条件时，如果实在是达不成某种条件，比如不出错的语音识别器，那么就搞个活人来扮演机器

实验结构

  • 实验中我们要研究多少自变量
    • 基本设计 or 析因设计
  • 每个自变量有多少个不同的值
    • 条件数 => 组件设计、组间设计、裂间设计

组件设计：每个参与者只暴露在一种实验条件下

优点：设计简洁、避免学习效应

缺点：结果受个体影响大、样本量大

组内设计：一组用户要参加多种实验条件

减缓学习效果和疲劳

  • 使用拉丁方设计进行平衡（专门的工具生成）

多个自变量的实验

析因设计

  • 分析数据时，比较同一行可以检查不同键盘的影响，任务效果可以通过比较同一列的数据来检验
  • 组内设计or组间设计

裂区设计

  • 析因研究中的一种设计，既有组间成分，又有组内成分
  • 举例
    • 研究问题：年龄和GPS的使用情况对驾驶效果的影响
    • 自变量：年龄（组间设计）、有无GPS（组内设计）

优点：允许在一个实验中研究两个或两个以上自变量之间相互作用的影响

相互作用可以被描述为“一个自变量对因变量的不同影响，取决于另一个自变量的特定取值”

DECIDE评估框架

六步

  1. 决定评估需要完成的总体目标
    • 评估目标决定了评估过程，影响评估范型的选择
    • 问什么要评估
      • 产品设计是否理解了用户需要
      • 为概念设计选择最佳隐喻
      • 界面是否满足一致性需要
      • 探讨新产品应做的改进
  2. 发觉需要回答的具体问题
    • 找出为什么用户更喜欢买纸质机票而不是互联网电子机票
    • 问题
      • 用户对新票据的态度如何
      • 用户是否能够通过互联网订票
      • 是否担心交易的安全性
      • 订票系统界面是否友好
    • 问题可以逐层分解
  3. 选择评估范型和技术
    • 范型决定了技术类型
    • 必须权衡实际问题和道德问题
      • 最适合的技术可能成本过高
      • 或所需时间过长
      • 或不具备必要设备或技能
    • 可结合使用多种技术
      • 不同技术有助于了解设计的不同方面
      • 不同类型数据可从不同角度看待问题
      • 组合有助于全面了解设计的情况
  4. 明确实际问题
    • 应选择恰当的用户参与评估
      • 能代表产品的目标用户群体
      • 可以先做测试，确定用户技能所属的用户群
    • 任务时间多长
      • 20分钟休息一次
    • 可在任务执行前，安排用户熟悉系统
    • 设施及设备
    • 期限及预算是否允许
    • 是否需要专门技能
  5. 处理道德问题
    • 保护个人隐私
      • 除非获得批准，否则书面报告不应提及个人姓名，或把姓名与搜集到的数据相联系
    • 可以申请IRB许可证
  6. 评估、解释并表示数据
    • 搜集什么类型的数据，如何分析，如何表示
      • 通常用评估技术决定
    • 可靠性
      • 给定相同时间，不同时间应用同一技术能否带到相同结果
      • 非正式访谈的可靠性较低
    • 有效性
      • 能否得到想要的测量数据
    • 偏见
      • 评估人员可能有选择地搜集自己认为重要的数据
    • 范围
      • 研究发现是否具有普遍性
    • 环境影响
      • 霍桑效应

小规模测试 Pilot Study

先试试水

对评估计划进行小范围测试

  • 以确保评估计划的可行性
  • 如检查设备及使用说明
  • 练习访谈技巧
  • 检查问卷中的问题是否明确

小规模试验可以进行多次

  • 类似迭代

可用性问题分级

对问题进行分级

方法一：基于量化数据的分级

方法二：问题严重性的主观打分，取平均值

方法三：可用性分级的两个因素

  • 有多少用户会遇到这个问题
  • 用户受到该问题困扰的程度

用户测试

  • 在受控环境下测量典型用户执行典型任务的情况
  • 目的是获得客观的性能数据，从而评价产品或系统的可用性，如易用性、易学性
  • 最适合对原型和能够运行的

测试设计

  • 用户测试须考虑实际限制并做出适当的折衷
    • 确保不同参与者的测试条件相同
    • 应确保评估目标特征具有代表性
    • 实验可重复，但通常不能得到完全相同的结果
    • 以DECIDE框架为基础
  • 定义目标和问题
    • 目标描述了开展一个测试的原因，定义了测试在整个项目中的价值
    • 目标对关注点的说明和检查
  • 设计测试任务

观察用户

两种方式

  • 真实环境中的观察

    观察者既可以观察，也可以参与实验

  • 实验室观察

    测试区，观察区

  • 用户坐在家中测试

  • 优点

    提供了可控且一致的评估环境

  • 缺点

    人为环境，不自然

实验室观察

生理反应监控

选择难以伪造的生理指标监控

观察中的问题

  • 不知道用户在想什么

    边做边说

    两位用户共同合作，以便互相讨论、相互帮助

实际场景观察

可以发现很多实验室观察不到的问题

几个难题

  • 要观察结果

  • 如何根据紧凑的开发期限和开发人员的技能相应修改现场研究技术

  • 如何降低噪音，测试中断及其他易使注意力分散的外界干扰

    方案一：健壮的评估设计

    方案二：将测试协议设计成包含“有计划的干扰”

注意事项

  • 观察人员自始至终应尽量保持安静
  • 不要在实验初期提供帮助
  • 观察人员看不懂用户在干嘛时要问一问

数据记录

  • 纸笔记录（现场记录）
  • 音频记录
  • …

日志与交互记录

举例：命令行操作系统超过30%的错误是拼写错误

定性分析

分析方法

详细分析一般都不用，只用粗略分析

定量分析

平均值、标准差、t检验

访谈

步骤

  • 开始

    访问人先介绍自己

    解释访谈的原因

  • 热身

    先提出简单的问题

  • 正式

访谈类型

  • 非结构化访谈
  • 结构化访谈
  • 半结构化访谈
  • 集体访谈

问卷

  • 常规问题：
    • 年龄、性别、职业、居住地、应用计算机的经验
  • 自由回答问题：
    • 你能对这个界面提出改进意见吗
    • 能够提出设计人员没有考虑到的建议
  • 其实5分满意度，至少要3.6以上才算基本满意

用户满意度调查表QUIS

认知走查

  • 逐步检查使用系统执行任务的过程，从中找出可用性问题
  • 专家来做，无需用户参与
  • 认知走查的主要目标是让系统易于学习
  • …

协作走查

  • 由用户、开发、专家一起合作

启发式

启发式评估基于启发式原则，不过这也只是一个参考，你可以有自己的评估原则

问题的严重性分类

严重性等级：

  • 表面问题
  • 次要问题
  • 主要问题
  • 灾难性问题

交互需求设计

  • 需求
    • 关于目标产品的一种陈述，它指定了产品应该做什么，或者应如何工作
    • 应该是具体的、明确和无歧义的
      • 完整下载任何网页的时间应少于5秒

用户特性

体验水平差异

  • 程序员总是想创造适合专家的界面
  • 市场人员想创造适合新手用户
  • 数目最多的是中间用户
  • 中间用户往往被忽略

设计目标

  • 让新手无痛成为中间用户
  • 别阻碍用户成为专家
  • 让中间用户感到愉快

开发人员总是喜欢自参考设计

新手用户

  • 特点
    • 敏感，很容易有挫折感
  • 设计要求
    • 不能将新手状态视为目标
    • 让学习过程快速且具有针对性

专家用户

  • 特点
    • 对缺少经验的用户有很大的影响
    • 喜欢快捷键

中间用户

  • 特点
    • 需要工具
    • 直到如何使用参考资料
    • 能够区分经常使用和很少使用的功能
    • 希望还是要有高级功能
  • 设计要求
    • 工具提示

找到你的用户

人物角色

是与系统有关的用户假定的一组公共需要、兴趣、期望、行为模式和责任

这些属性可能是若干用户共有

同一个用户也可以扮演系统的任意个不同角色

注意用户要被细分，同样是来高考咨询的学生，拿着985分数的学生和拿着普通本科的学生是不一样的，中产家庭的学生和低产家庭的学生和富裕家庭的学生和红三代也是完全不同的，我们最主要关注的还是核心用户和广大用户

建模过程

  • 拼凑
  • 组织
  • 细节
  • 求精
  1. 确定需求
  2. 需求验证
    • 可以直接展示原型
    • 原型分为低保真和高保真（比如用visual basic）
    • 鼓励多用低保真模型(高保真模型限制你的想象)

实验分析

通过方差分析进行

误差

  • 第一类误差：零假设为真，却拒绝了原假设（轻信错误，造成的后果更严重，因为会比目前的状况更糟糕）
  • 第二类误差：零假设为假，但是却没有推翻零假设（无知错误，会导致失去改变现状的机会）

p值：如果零假设成立，获得观测数据的概率，表述为自变量对因变量的影响有统计学意义

设计简单原型

通过验证性的场景剧来检查设计

  • 关键线路变种场景剧本：用户不想打电话了，想发电子邮件
  • 必须使用的场景剧本：手机被卖了，要删除原有信息
  • 边缘场景使用剧本：用户添加联系人，但是两个联系人同名了

卡片分类

格式塔心理学

  • 相近性原则：空间上靠近的物体容易被视为一组
  • 相似性原则：长得相似的东西容易被分为一组
  • 连续性原则：共线或者具有相同方向的物体容易被划为一组
  • 对称性原则：对称且能够组合为有意义单元的物体会被组合在一起
  • 完整和闭合性原则：人们倾向于忽视轮廓而将其视作一个完整的整体（页面上的空白可以帮助实现分组）
  • 前景与背景：前景和背景在某些情况下可以互换

任务培训可能考