导图社区 人机交互软件工程方法
人机交互软件工程方法的思维导图，介绍了以用户为中心的设计、人机交互概述、交互设计过程、交互式系统的设计等。
社区模板帮助中心，点此进入>>
论语孔子简单思维导图
《傅雷家书》思维导图
《童年》读书笔记
《茶馆》思维导图
《朝花夕拾》篇目思维导图
《昆虫记》思维导图
《安徒生童话》思维导图
《鲁滨逊漂流记》读书笔记
《这样读书就够了》读书笔记
妈妈必读：一张0-1岁孩子认知发展的精确时间表
人机交互软件工程方法
以用户为中心的设计
测试设计
用户测试须考虑实际限制并做出适当的折衷
应确保不同参与者的测试条件相同
应确保评估目标特征具有代表性
实验可重复，但通常不能得到完全相同的结果
以DECIDE框架为基础
定义目标和问题
目标描述了开展一个测试的原因，定义了测试在整个项目中的价值
目标是对关注点的说明和解答
选择参与者
参与者不同
缺点
要求有足够多的参与者
实验结果可能会受到个别参与者的影响
优点
不存在“顺序效应”
即参与者在执行前一组任务时获得的经验将影响后面的测试任务
参与者相同
可能产生“顺序效应”
解决方法：均衡处理
能够消除个别差异带来的影响
便于比较参与者执行不同实验情形的差异
参与者配对
实验结果可能会受一些未考虑到的重要变量的影响
如在评估网站的导航性能时，参与者使用互联网的经验将影响实验结果
因此，“使用互联网的经验”即可作为一个配对标准
参与者的选择对于任何实验的成功至关重要
了解用户的特性有助于选择典型用户
通常也需要平衡性别比例
设计测试任务
测试任务应当与定义的目标相关
测试任务通常是简单任务
有时采用较为复杂的任务
任务不能仅限于所要测试的功能，应使用户全面的使用设计的各个区域
每项任务的时间应介于5~20分钟
应当以某些合乎逻辑的方法安排任务
明确测试步骤
在测试之前，准备好测试进度表和说明，设置好各种设备
正式测试前应进行小规模测试
在必要时，评估人员应询问参与者遇到了什么问题
若用户确实无法完成某些任务，应让他们继续下一项任务
测试过程应控制在1小时之内
必须分析所有搜集到的数据
数据搜集
确定如何度量观测的结果
使用的度量类型依赖于所选择的任务
定量度量和定性度量
测试准备
建造一个测试计划时间表
协调参与者的日程计划、小组成员的日程计划及实验室的可使用性
在测试过程中编写对应的脚本
脚本应当包括协调者和参与者交互的每一个方面，也应当包括一些意外事件
安排小规模试验
测试可以在特定实验室里完成，也可以借助简陋的测试设备完成
应当使用一个客观的参与者
数据分析
变量
实验的目的是回答某个问题或测试某个假设，从而揭示两个或更多事件之间的关系
这些“事件”称之为“变量”
分析方法
定量数据
最常用的描述性统计方法是次数统计
定量数据的次数统计、平均数统计
定性数据
通常按主题分类
找出获得某信息的最快途径
总结报告
将测试的结果以书面形式反馈给产品的设计人员，以便于他们对设计进一步的分析和改进
网站评估实例
交互式系统的设计
设计框架
定义外形因素、姿态和输入方法
外形因素
设计什么样的产品？
高分辨率屏幕上显示的Web应用？
轻便、低分辨率、在黑暗和阳光下都能看得见的手机产品？
产品的特点和约束对设计提出了什么样的要求 (回想一下人物角色和场景剧本)
产品输入方法
产品与用户互动的形式
取决于产品的外形和人物角色的能力和喜好
哪种方式或者组合更适合设定的人物角色
定义功能和数据元素
数据元素
交互产品中的基本主体，如相片、电子邮件、订单
功能元素
对数据元素操作的工具以及输入或者放置数据元素的位置
决定功能组合层次
元素分组
更好地在任务中和任务间来帮助促进任务角色的操作流程
需考虑的内容
哪些元素需要大片的视频区域
容器如何组织才能优化工作流
哪些元素是被一起使用的等
产品平台、屏幕大小、外形尺寸和输入方法的影响
勾画大致的交互框架
最初阶段，界面的视觉化工作应该非常简单
方块图阶段
用粗略的方块图来表达并区分每个视图
方块图对应窗格、控制部件（如工具栏）
为每个方块图添加上标签和注解
注意
不要被界面上某个特殊区域的细枝末节分散了精力
构建关键线路场景剧本
描述了人物角色如何同产品交互
这些场景剧本描述了人物角色最频繁使用界面的主要路径
必须在细节上严谨地描述每个主要交互的精确行为，并提供每个主要线路的走查
可使用低保真草图序列的故事板
通过验证性的场景剧本来检查设计
验证性的场景剧本不用具备很多细节
关键线路的变种场景剧本
必须使用的场景剧本
边缘情形使用场景剧本
设计策略
删除
去掉所有不必要的按钮，直到不能再减
组织
按照有意义的标准将按钮划分成组
隐藏
把那些不是最重要的按钮安排在活动舱盖下面去，避免分散用户的注意力
转移
只在遥控器上保留具有最基本功能的按钮，将其他控制转移到电视屏幕上的菜单里，从而将复杂性转移到电视
设计中的折中
个性化和配置
问题：是否应该让产品具有用户定制功能？
个性化
人们喜欢改变周围的事物，使之适合自己
必须简单易用
在用户确定选择之前给他们一个预览的机会
必须容易撤销
配置
移动、添加或者删除持久对象
富有经验的用户所期望的
包含多种配置形式
本地化和国际化
国际化
指在设计软件时，将软件与特定语言及地区脱钩的过程
当移植到不同的语言及地区时，软件本身不用做内部工程上的改变或修正
意味着产品有适用于任何地方的“潜力”
只需做一次
本地化
当移植软件时，加上与特定区域设置有关的信息和翻译文件的过程
为了更适合于“特定”地方的使用，而另外增添的特色
针对不同的区域各做一次
审美学和实用性
漂亮的界面 ≠ 一个好的界面
审美与实用的冲突
交互设计角度
组件之间的空白非常重要
组件的对齐会影响界面的可理解性和易用性
设计的细节
设计体贴的软件
加快系统的响应时间
减轻用户的记忆负担
减少用户的等待感
设计好的出错信息
交互设计模式
定位模式：概念层面，帮忙界定产品对用户整体定位
结构模式：解答如何在屏幕上安排信息和功能元素
行为模式：解决功能或数据元素的具体交互行为，组件行为
可视化设计
窗口和菜单
窗口
源于Xerox Alto系统，后被融入Apple操作系统和Windows操作系统
菜单
访问系统功能的工具，已经成为窗口环境的标准特征
必不可少的组成部分
所有窗口必备的基本组件
菜单栏是代表下拉式菜单的菜单
菜单选项的标签、位置、归类等均已标准化
对话框
模态对话框
特性
冻结了它属于的应用，禁止用户做其他操作，直到处理了对话框中出现的问题
可以切换到其他程序进行操作
用户最容易理解，操作非常清晰
作用范围分类
应用模态 只停止其所属的应用程序
系统模态 使系统中的所有程序都停止。大多数情况下，应用程序不应该有系统模态对话框
非模态对话框
打开后无须停止进度，应用程序也不会冻结
由于其操作范围不确定而难以使用和理解
存在的问题
选择对象在对话框存在过程中会发生改变，控件处理更复杂
示例
Word的查找和替换对话框
画图程序。可以在主窗口和非模态对话框之间拖动对象
用途
属性对话框
功能对话框
进度对话框
标签对话框
扩展对话框
级联对话框
公告对话框
错误对话框
用户希望避免错误造成的结果，而不是错误消息
消除错误消息
用更健壮的软件取代错误消息
为用户提供正面反馈
最后一招：改进错误消息框
警告对话框
通知用户程序的行为，“确认”操作赋予用户忽略该行为的权利
确认对话框
程序对自己的行为不自信，用对话框来征求许可
总是来自程序，而不是用户
对话框在喊“狼来了”
消除确认对话框
原则1：做，不要问
原则2：让所有操作都可以撤销
原则3：提供非模态反馈帮助用户避免犯错误
对话框设计原则
把主要的交互操作放在主窗口中
视觉上区分模态与非模态对话框
不要用临时对话框作为错误信息框或确认信息框
不要堆叠标签
控件
命令控件
选择控件
显示控件
输入控件
工具栏
文本标签精确，但阅读与识别速度较慢
工具栏和菜单的用途不同
图标图像
屏幕复杂度度量
布局复杂度
布局统一度
交互设计模型与理论
预测模型
能够预测用户的执行情况，但不需要对用户做实际测试
特别适合于无法进行用户测试的情形
动态特性建模
状态转移网络
三态模型
语言模型
用户和计算机的交互通常是通过一种语言进行的
系统模型
为评估系统的可用性，需要知道系统做的是什么
评估的基础知识
目的
评估总是需要的
保证整个产品开发过程中都能考虑用户的需要
定义
系统化的数据搜集过程
目的是为了了解用户或用户组在特定环境中，使用产品执行特定任务的情况
目标
评估系统功能的范围和可达性
评估交互中用户的体验
确定系统的某些特定问题
原则
评估应该依赖于产品的用户，与专业技术人员的水平和技术无关
评估与设计应结合进行，仅靠用户最后对产品的一两次评估，是不能全面反映出软件可用性的
评估应在用户的实际工作任务和操作环境下进行，根据用户完成任务的结果，进行客观的分析和评估
要选择有广泛代表性的用户，参加测试的人必须具有代表性
范型
快速评估
可用性测试
实地研究
预测性评估
技术
测试用户的执行情况
基于模型和理论，预测界面的有效性
方法的选择
评估方法的组合取决于项目待评估的具体特性
启发式评估vs.用户测试
步骤
确定(Determine)评估需要完成的总体目标
发掘(Explorer)需要回答的具体问题
选择(Choose)用于回答具体问题的评估范型和技术
标识(Identify)必须解决的实际问题，如测试用户的选择
决定(Decide)如何处理有关道德的问题
评估(Evaluate)解释并表示数据
交互设计过程
基本活动
评估设计
构建设计的交互式版本
开发满足需求的候选设计方案
标识用户需要并建立需求
关键特征
以用户为中心
稳定的可用性标准
迭代
设计过程中的问题
如何选取用户
如何明确需求
如何提出候选设计方
从候选方案中作出选择 -- “设计决策”
交互设计生命周期
传统软件生命周期模型
瀑布模型
提供了按阶段划分的检查瀑布模型查点
当前一阶段完成后，只需要去关注后续阶段
可用于迭代模型
易于理解和实现
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
开发模型是线性的，增加了开发风险
不适应用户需求的变化
早期的错误可能要等到开发后期的测试阶段才能发现
螺旋模型
使用原型及其他方法来尽量降低风险
引入“迭代”思想，找出风险和控制风险
制定计划、风险分析、实施开发、客户评估
快速应用开发
开发速度快，对信息系统的开发特别有效
对大型项目而言，RAD需要足够的人力资源
开发人员和客户必须在很短时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败
RAD只能用于信息系统开发，不适合技术风险很高的情况
原型法
相比RAD，原型法更便于用户参与到开发过程中
更能满足用户需求
适应需求不确定的情况
能较快的实现系统基本结构
开发成本低
为了加速系统开发速度，常常导致系统质量的下降
没有严格的开发文档，维护困难
交互生命周期模型
星型生命周期模型
可用性工程生命周期
交互设计过程管理
LUCID
OVID
人机交互概述
基本概念
人：试图应用计算机特定工作的任何人
计算机：桌面计算机、嵌入式系统等，包括搜索引擎、文字处理器等软件
交互：直接：任务执行过程中始终伴随着反馈与控制对话
交互：间接：批处理与控制环境的智能传感器
定义：有关计算机系统设计、评估、实现以及与之相关现象的学科
研究内容
界面设计的方法和过程
界面实现方法
界面分析和评估技术
开发新型界面和交互技术
构建交互相关的描述模型和预测模型
学习目的
发展历史
人机交互与人软件工程
二者的关注点不同
HCI对SE的促进作用
二者在系统工程中的关系
二者结合的困难
HCI和SE相互区别又相互影响，只有有机结合，才保证在有效的时间和资源下开发出高可用性的软件产品
