人机交互学习-5 交互式系统的需求-Toy模板网

这篇具有很好参考价值的文章主要介绍了人机交互学习-5 交互式系统的需求。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

需求是什么

需求

关于目标产品的一种陈述，它指定了产品应做什么，或者应如何工作
应该是具体、明确和无歧义的

需求活动

搜集数据
解释数据
提取需求

产品特性

注：了解

功能不同
智能冰箱：应能够提示黄油已用完
字处理器：系统应支持多种格式
物理条件不同
移动设备运行的系统应尽可能小，屏幕显示限制
使用环境不同
物理环境：如操作环境中的采光、噪音和尘土状况
社会环境：是否要共享数据，同步还是异步？
组织环境：用户支持的质量、响应速度如何？提供培训资源或设施？
技术环境：产品应能运行于何种平台上？应与何种技术兼容？

用户特性

心理学原理部分，假设每个人都有相似的能力和局限性，合理的心理学原理可以适用于大多数人。
交互产品设计人员应该意识到个性的差异：
用户并不是完全相同的
在设计中尽可能地体现这些差异
用户差异
体验水平
年龄
文化
健康

体验水平差异

背景

程序员只创造适合专家的界面
市场人员要求只适合新手的交互
数目最多、最稳定和最重要的用户群是中间用户
中间用户往往被忽略

设计目标

让新手快速和无痛苦地成为中间用户
避免为想成为专家的用户设置障碍
让中间用户感到愉快，因为他们的技能将稳定地处于中间层

新手用户

特点
敏感，且很容易在开始有挫折感

设计要求

不能将新手状态视为目标
让学习过程快速且富有针对性
确保程序充分反映了用户关于任务的心智模型
无论什么样的帮助，都不应该在界面中固定
具有向导功能的对话框帮助较好，不要使用在线帮助作为学习指导
菜单项应该是解释性的

专家用户

特点

对缺少经验的用户有着异乎寻常的影响，“专家说不好就不好”
欣赏更新的且更强大功能
不会受到复杂性增加的干扰

设计要求
对经常使用的工具集，要能快速访问

中间用户

特点

需要工具
知道如何使用参考资料
能够区分经常使用和很少使用的功能
高级功能的存在让永久的中间用户放心

设计要求

工具提示是适合中间用户最好的习惯用法
在线帮助是永久中间用户的极佳工具
常用功能中的工具放在用户界面的前端和中心位置
提供一些额外的高级特性

年龄差异

在谈到交互技术时，老年人和儿童有特殊需求。

老年人

65岁以上的老年人中多数有某种残疾
技术应能提供对残缺部位的支持，如听觉、言语和灵活性
设计必须清楚、简单并且容许出错
利用冗余来支持信息访问

儿童

在为儿童设计交互式系统时让他们参加很重要
允许多种输入模式的界面对于孩子们更适用
通过文本、图形和声音呈现信息的冗余显示

文化差异

在不同的文化中符号有不同的意思
不能假设每个人都以同样的方式解释符号
勾（√）和叉（X）分别表示肯定和否定
姿势的理解存在差别
点头vs.摇头
颜色的使用
红色和绿色在不同的国家意味着不同的事物
通过冗余阐明特定颜色的指定意义

健康差异

每个国家至少有10%的人口有残疾
视觉损伤
GUI应用的增加降低了视觉损伤用户应用的可能性
辅以声音的应用和触觉的应用
听觉损伤
较视觉残疾对与图形界面交互的影响要小，界面中多媒体的增加和声音的应用带来了交互困难
给听觉内容加文字描述
姿势识别可作为信息输出方式
身体损伤
如在控制和应用手的移动方面存在差别
语音输入和输出对那些没有言语障碍的人是一种选择
用姿势和眼球移动的跟踪进行控制
语音损伤
提供合成语音和基于文本的通信
语音合成必须快速地反映自然会话的步调
诵读困难
提供拼写更正功能
一致性的导航结构和清晰的标识提示

用户建模

注：important！！！必出

人物角色

Personas

不是真实的人
是基于观察到的那些真实人的行为和动机，并且在整个设计过程中代表真实的人
是在人口统计学调查收集到的实际用户的行为数据的基础上形成的综合原型
概念简单，但使用起来相当复杂，拼凑出几个用户档案是不行的

人物角色的作用

解决产品开发过程中出现的3个设计问题：

弹性用户
为弹性用户设计赋予了开发者根据自己的意愿编码，而仍然能够为“用户”服务的许可
如设计医院产品时，考虑设计能够满足所有护士的产品
自参考设计
设计者或者程序员将其自己的目标、动机、技巧及心智模型投射到产品的设计中
边缘情况设计
必须考虑边缘情况，但它们又不应该成为设计的关注点
问：A会经常进行这种操作吗？

人物角色的构造

错误观点

A：专业开发人员知道什么可行，什么对用户最合适
B：用户最了解他们需要什么，应当让他们指导设计工作

人物角色

与某个系统有关的用户假定的一组公共需要、兴趣、期望、行为模式和责任
这些属性可能是若干用户共有
同一个用户也可以扮演系统的任意个不同角色
举例：频繁使用文字处理软件的用户
写作者的角色
编辑者的角色
排版者的角色

基于问题

谁将使用系统？
这些用户属于哪些类型的人群？
是什么因素决定他们将怎样使用系统？
他们与软件的关系有什么特征？
他们通常需要软件提供什么支持？
他们对软件会有怎样的行为？对软件的行为有什么期望？

举例

设计运行在笔记本电脑上的一个演示程序包：

销售部的一位同事

公司的销售代表
能快捷方便地创建标准格式的简单幻灯片
能使用带有项目的文字内容或简单图表
图形依靠软件提供的标准图形库

人物角色：日常最低要求演示者

经常使用；快速、方便操作；简单使用；

简洁、标准格式：带有项目符号的列表、条形图、饼图、图形等；标准图形库

注意事项

要注意那些与软件用户界面设计有关的角色特征
要关注使角色之间彼此相区别的特征
要留心焦点角色，最常见、最典型的角色

建模过程

拼凑
采用头脑风暴方法，产生一些零碎概念或模型的片段，先不去考虑他们的细节
组织
将这些片段按照所构造模型的需要进行分组和分类，归并或删除那些冗余重叠的东西
细节
建立和完善相应描述，补充遗漏的数据
求精
对模型进行推敲，以便改进和完善

需求获取、分析和验证

观察

初设时可能不知道问什么问题或由谁来回答这些问题
没有与参与者实际的讨论和观察是不可能得到完整的工作流程画面的
有用的信息可以通过观察人们在工作环境中完成他们的活动来获得
直接观察
直接观察技术借鉴了源自人类学的民族志观察的方法
陪同他们工作而直接获得信息
可能影响被观察者的日常活动
可提问：这是你通常完成任务的方式吗？
间接观察
用视频/录音获得信息
观察者更舒适

场景

场景是表示任务和工作结构的“非正式的叙述性描述”
以叙述的方式描述人的行为或任务，从中可以发掘出任务的上下文环境、用户的需要、需求
形式可以类似于一篇故事、一个小品或者在给定环境下按照时间顺序的一段情节
“讲故事”是人们解释自己做什么或者希望执行某个任务的最自然方式
故事的焦点就是用户希望达到的目标
若场景说明不断提到某个特定形式、行为或者地点，就表明它是这个活动的核心内容
来源
专题讨论或者访谈，目的是解释或讨论有关用户目标的一些问题

实例：
图书馆目录服务系统的潜在用户场景

以上场景说明的问题

正确输入作者姓名的重要性

用户对输入口令感到反感

应提供更灵活的检索方法

在匹配不成功时，应给出相近的检索结果

人物角色+场景剧本→需求

需求定义的5个步骤：

创建问题和前景综述
头脑风暴
确定人物角色的期望
构建情境场景剧本
确立需求

是一个迭代的过程，直到需求变得稳定

创建问题和前景综述

设计问题综述应该简明地反映需要改变的情况，来服务人物角色和提供产品给人物角色的商业组织
前景综述高层次的设计视图和需求是问题综述的倒置
设计新的产品P会帮助用户实现目标G，这让用户能更好地（精确度和效率等）完成X、Y和Z任务，并且不会产生其现在遇到的A、B和C等问题。从而会有力地改善H公司的顾客满意度，并且会增加市场占有率。

头脑风暴

目的：

“说反话”的意图
尽可能地去除成见，允许设计师以开放和灵活的方式想象来构建场景剧本，使用他们的思维从场景剧本中得到需求
将头脑置于“解决问题模式”中

特点：

不受约束且不加以评判
不要花费太多时间，当想法重复或变慢时停止

确定人物角色的期望

一个人的心理模型通常是根深蒂固的
界面表现模型与用户心理模型尽量匹配
对于每一个基本和次要人物角色，需确定：
影响人物角色愿望的态度、经历、渴望，以及其他社会、文化、环境和认知因素
人物角色在使用产品体验方面可能有的一般期待和愿望
人物角色认为什么是数据的基本单元或者元素
理清如下问题：
主体首先提到的是什么？
他们使用哪些动作单词？
他们没有提及对象中的哪些中间步骤、任务或者对象？

构造情境场景剧本

情境场景剧本：

关注人物角色的活动，及其心理模型和动机
将注意力集中在设计的产品中怎样能够最好地帮助你的人物角色达到目标
应该专注于高层次的从用户角度描述的行动，广而浅，不应描述产品或交互的细节

解决的问题：

产品是否会被使用很长一段时间？
人物角色是否经常被打断？
和其一起使用的其他产品是什么？
人物角色需要做哪些基本的行动来实现目标？
使用产品预期的结果是什么？

情境场景剧本实例
第1次迭代：

人物角色Vivien Strong
女，32岁，已婚，女儿Alice
印第安纳波利斯市的一个房地产代理商
目标是平衡工作和家庭生活
紧紧抓住每一个交易机会并且让每一个客户都感觉自己是Vivien的唯一客户

情景场景剧本：

在早晨做好准备，Vivien使用电话来收发电子邮件。它的屏幕足够大，并且网络连接很快。因为早上她同时要匆忙地为女儿Alice准备带到学校的三明治，这样手机比计算机更方便。

Vivien收到一封Email，来自最新客户Frank，他想在下午去看房子。Vivien在几天前已经输入了他的联系信息，所以她现在只需要在屏幕上执行一个简单的操作，就可以拨打他的电话

在与Frank打电话的过程中，Vivien切换到免提状态，这样她能够在谈话的同时看到屏幕。她查看自己的约会记录，看看哪个时段自己还没有安排。当她创建一个新的约会时，电话自动记录下这是与Frank的约会，因为它知道她是在与谁交流。谈话结束后，她快速地输入准备看的那处房地产的地址

将Alice送到学校之后，Vivien前往房地产办公室收集另一个会面所需的信息。她的电话已经更新了其Outlook约会时间，所以办公室里的其他人知道她下午在哪里

一天过得很快，当她前往即将查看的那处房地产并准备和Frank见面时，已经有点晚了，电话告诉她约会将在15分钟之后。当她打开电话时，电话不仅显示了约会记录，而且将与Frank相关的所有文件，包括电子邮件、备忘录、电话留言、与Frank有关的电话日志，甚至包括Vivien作为电子邮件的附件发送的房地产的微缩图像。Vivien按下呼出键，电话自动连接到Frank。因为它知道Vivien立即就要和Frank见面，她告诉Frank她将在20分钟之内到达

Vivien知道那处房地产的大致位置，但不是很确切。她停在路边，在电话中打开存在约会记录中的地址，电话直接下载了从她当前地址到目的地的微缩地理图像

Vivien按时到达了访谈处，并且开始向Frank介绍这处房地产。她听到从坤包中传出电话铃声，通常当她在约会时会自动将电话转到语音信箱。但Alice可以输入密码跨越这一过程。电话知道是Alice在打电话，并使用了特别的响铃声

Vivien拿起了电话——Alice错过了公交，需要接她。Vivien给她的丈夫打电话看他能否代劳，可是访问的却是其语音信箱，他肯定是不在服务区内。她给自己的丈夫留言，告诉他自己和客户在一起，看他能否去接Alice。5分钟后，电话发出了一个简短的铃音。从音调中，Vivien可以判断出这个短信是丈夫发给她的。她看到了丈夫发出的短消息：“我会去接Alice，好运！”
注意：
没有涉及太具体的界面和技术信息
活动是和Vivien的目标相关的
尽可能去掉多余的任务

确立需求

数据需求
必须在系统中被描绘的对象和信息
可以被看作是与对象相关的宾语或形容词
如账号、人、文档、邮件、歌曲、图片以及它们的属性比如状态、日期等
功能需求
系统对象必须进行的操作
最终会转化为界面控件
其他需求
开发进度、大小等

任务分析

记录人们如何完成任务的一种方式
作用：
可以用来了解通过观察和访谈目前参与工作流程的人收集到的数据
主要用于调查现有情形，而不是展望新系统或设备
分析基本原理，了解人们想要达到什么目标，如何达到这些目标，并由此建立需求
**层次化任务分析（HTA）**是应用最广的任务分析技术：
把任务分解为若干子任务，再把子任务进一步分解为更细致的子任务。之后，把他们组织成一个“执行次序”，说明在实际情形下如何执行各项任务

图书馆目录服务的任务分析：
“借书”的子任务：

访问图书馆目录

根据姓名、书名、主题等检索

记录图书位置

找到书架并取书（假定书在书架上）

到柜台办理借阅手续
以上过程可以有所变化
执行次序：

借书

前往图书馆

检索需要的图书
2.1 访问图书馆目录
2.2 使用检索屏
2.3 输入检索准则
2.4 找出需要的图书
2.5 记录图书位置

找到书架并取书

到柜台办理借阅手续
执行次序0：执行1-3-4；若图书不在期望的书架上，则执行2-3-4。
执行次序2：执行2.1-2.4-2.5；若未查到此书，则执行2.2-2.3-2.4-2.5
HTA的图形描述：（使用方框-线条的图示来表示HTA）

终止规则

任务分析是一个迭代过程
终止点
1）任务包含了复杂机械响应的地方
如鼠标移动
此时分解没有价值
2）涉及内部决断的地方
若决断和查找文档等外部动作相关，则分解
若为纯粹认知性，则终止

任务分析结果的用途

手册和教学
如怎样拆卸、擦净来复枪，怎样安装软件等
“如何做”手册适于培训
需求获取和系统设计
任务分析本身不是需求获取
但有助于需求的完整表达
详细的接口设计
应用于菜单设计

验证

原型的重要性

用户往往不能准确描述自己的需要
用户在看到或尝试某些事物后，就能立即知道自己不需要什么

原型

在某一方面和真正产品比较接近、以便人们能对这一方面的各种技术方案进行不断评估和改进的一种接近于实际产品的模型
如房屋、桥梁的缩微模型
借助于原型，当事人就能与未来的产品交互，从中获得一些实际的使用体验，并发掘新思路文章来源地址https://www.toymoban.com/news/detail-487073.html