《交互设计、界面设计》课件 03 需求获取.ppt

第三章 需求获取 需求获取的内容 需求获取是交互设计过程中的一个重要环节，在执行时应该注重细节，保持客观的态度，不对收集到的信息的重要性过早地做评判。 需求获取阶段要明确的主要内容包括： 谁将加入此项工作 他们使用什么来完成此项工作 工作过程 完成工作需要的信息 工作约束 工作需要的输入 工作需要的输出 3.1 需求获取阶段框架 3.1.1调查工作领域 在人们使用各种产品和界面时，有大量的没有被记录的隐藏着的操作行为信息。很多基于观察的方法被用来发现这些信息，进而改进设计。 在调查某一工作领域时，应考虑此领域的具体交互状况。例如，访问某网站这项工作中，可能遇到怎样的交互问题，需要输入什么数据寻找到相应信息。 尽可能了解用户和产品或界面的各个方面，研究其工作流程，用户如何用它来完成任务。 此阶段应该根据搜集的信息创建需求文档，界定人们要完成的具体任务，及完成这些任务的具体顺序。 3.1.1调查工作领域 搜集相关信息前，先确认与项目相关的人员，即直接和间接地涉及工作流程的人。 利益相关者（或称为当事人） 主要利益相关者：影响产品用户、潜在用户的工作效率 次要的利益相关者：提供输入信息或接受输出信息者 项目负责人：开发团队、产品维修人员 间接者：用户的上级或同事等 3.1.1调查工作领域 竞争对手 在需求获取阶段，不仅要调查利益相关者，还应调查同类的产品和界面设计。例如：设计某个网站，应该调查同类网站。 可以将现有同类产品和界面设计作为已经有的原型，并研究这个原型的优劣之处。 3.1.2 需求获取过程 需求获取的启发式思路 ：5W+H法 What/How：包含什么样的产品或界面交互行为，这些行为怎样被完成。 Where/When ：了解此行为发生在什么地点，了解完成交互行为发生的时间及先后顺序。 Who/Why ：了解哪些人参与了交互行为，为什么他们会参与到这样的交互行为中来。 收集需求时可以从以下一些方面了解人们的行为方式： 物理的视角：发生行为的时间、地点、过程。 功能的视角：从实际发生的状况研究行为。 文化的视角：从人们之间的关系来看交互行为。 与信息有关的视角：完成任务需要信息是什么，信息如何产生、传递。 3.2 收集 收集需求信息时注意的原则是，以用户为中心，尽量减少对用户的影响。 收集方法 观察：直接观察，间接观察，分布式认知。 启发式 ： 直接方法：访谈、专题小组； 间接方法：公司文档，日志和笔记，问卷调查。 3.3 需求描述 收集完信息后，需要分析收集到的信息，并对其进行相应的描述，明确各方面的问题。 需求描述的方法： 任务分析 故事板 用例 主要利益相关者档案 3.3.1 任务分析 任务分析是记录人们如何完成任务的一种方式。通过任务分析来了解通过观察和访谈收集到的数据信息。任务分析以全局的观点来看用户的活动和关注值得注意的行为。 任务分析的两种方式： 任务分解 层化任务分析 任务分解 任务分解是一个对过程的线性描述，首先确认过程并记录，然后列清单或表格对任务步骤进行描述。应尽可能确认单个步骤中的需求、顺序和依赖关系。 任务分解包括以下方面： 行为发生的原因 执行任务的人 完成任务需要的对象和信息 例如：如何组织召开一个团队会议，相应的任务分解过程是怎样的？ “组织召开一个团队会议”任务分解 目标：召开团队会议 计划：完成子任务的顺序和条件 信息：团队成员联系方式，会议时间表，会议设备 对象：日程表，通信录，设备签出表 方法：不同的联系方式：邮件、消息、电话、便条… 子目标：联系参会人、确认时间、安排会议室… 步骤 突发事件 层化任务分析Hierarchical Task Analysis（HTA ） 描述使用者要做些什么来达成目标.在HTA中,上层的任务会被分解成数个子任务,所以HTA可呈现出要达成某个目标和任务,必须执行哪些子任务. 3.3.2 故事板 使用一系列的图片来描述一个具体的过程和工作流程，这和电影中的故事板相似。采用粗略的形式讲述一个故事，研究此流程中的行为动作和对象。 3.3.3 用例（Use Case ） 用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。 从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成： 参与者(Actor) ，参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use Case) ，用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 P83安排会议过程的用