交互设计的需求获取
交互设计的基本目标主要分为三方面的要求：效用（是否能够满足用户组的需求或期望）、可用性和体验。
系统的概念模型包括设计模型、用户模型和系统映像三个部分。最重要的是正确设计用户模型，而设计模型和系统映像都是为其服务的。而用户模型的设计又依赖于用户建模，这与需求获取息息相关。
需求获取
下图描绘出了交互设计的主要流程：
交互设计的主要流程
可以看出，需求获取是项目设计的第一个阶段，无论取代或更新已有系统，还是开发新产品，需求的建立都是非常重要的。需求是对目标产品的一种陈述，它指定了产品应做什么，或者应如何工作。需求应当是具体、明确和无歧义的。
需求设计应当充分考虑产品特性和用户特性两方面。二者不是一成不变的，而是在不同的情境下截然不同的，因此又一次体现出了需求的重要性。
产品特性指产品在功能、物理条件和使用环境上存在差异。例如智能冰箱应当提示与食物储存相关的信息，移动设备运行的系统应当尽可能小等。
用户特性指普适性的心理学原理和个体间的差异。个体间的差异如体验水平、年龄、文化和健康之间的差异。
体验水平的差异
体验水平的差异在于用户对计算机操控和理解程度的差异。一般来说，程序员只适合创造适合专家的页面，因为程序员本身对计算机掌握程度较高；市场人员可能要求只适合新手的交互；然而数目最多、最稳定和最重要的用户群是中间用户。
新手用户的特点是敏感，容易在遇到困难时产生挫折感。因此，设计的目标主要有两方面：一方面是提供富有针对性和贴心的帮助信息，减少挫折感的产生；另一方面是提供高效的学习流程，当用户习得后隐藏帮助信息，尽量缩短用户的学习阶段。
专家用户的特点是不会受到复杂性增加的干扰，且对于更新、更强大的功能高度欣赏。专家用户对缺少经验的用户有着异乎寻常的影响。因此在设计时可以增加页面的复杂度，提供快速访问的工具集和热键等。
中间用户可以使用参考资料，并且能够区分经常使用和很少使用的功能。中间用户不一定使用高级功能，但是高级功能的存在可以让永久的中间用户放心。在设计时，应当使用工具提示（如悬停显示气泡）和在线帮助，将常用的功能放在界面的中心位置等。
年龄差异
- 老年人：应当考虑老年人视力等因素，尽量采取大型的组件，不要在界面上放置过多元素。此外，设计必须清楚、简单并且容许出错，可以使用冗余来支持信息访问。
- 儿童：让儿童参与到其中十分重要。可以使用多种输入模式，并采取文本、图形和声音等冗余显示。
除此之外，还有健康和文化之间的差异。
用户建模
既然用户之间存在这么大的差异，我们在设计时是不可能完全考虑所有用户的。因此，需要结合用户的研究数据抽象出一些人物角色。人物角色不是真实的人，而是基于观察到的那些具有代表性的真实的人的行为和动机，抽象出来的综合人物原型。同一个人物可能对应现实中的多个用户（一对多）；同一个用户可以扮演系统中的任意个不同的人物角色（多对一）。例如，一款文字处理软件可能有写作者、编辑者和排版者的人物角色。
人物角色构造问题自查表
人物角色的构造可以基于如下的问题：
- 谁将使用系统？
- 这些用户属于哪些类型的人群？
- 是什么因素决定他们将怎样使用系统？
- 他们与软件的关系有什么特征？
- 他们通常需要软件提供什么支持？
- 他们对软件会有怎样的行为？他们对软件的行为有什么期望？
此时，可以形成最基础的人物角色。我们需要为人物角色起一个合适的名字，列出其特点，并撰写剧本。我们应当按一定格式，来组织每个人物角色。总之，人物角色应当尽可能真实，好像就是现实世界中存在的人一样。
人物角色和剧本构建时的易错点
主要的问题可能有：
- 人物信息构造不完整，缺少照片。
- 人物的名字不真实，像是随便起的。
- 人物的期望不正确，不符合实际。人物的期望一般不是明确的需求。
- 剧本应该尽可能真实饱满，而不是写成技术文档。
构建人物角色时需要注意，那些与软件用户界面设计有关的角色特征；要关注使角色之间彼此相区别的特征；要留心焦点角色(最常见、最典型的角色)。
建模的主要过程是：拼凑、组织、挖掘细节和求精。这一过程不断循环往复，精益求精。
人物角色主要可以解决三个设计中的误区：弹性用户、自参考设计（设计者过度参考自身）和边缘情况设计（把边缘情况看重）。
弹性用户
所谓弹性用户是一个通用的用户，对不同的人意味着不同的东西。为"弹性用户"设计的情况发生在产品决策是由不同的利益相关者做出的，他们可能会根据自己的便利来定义"用户"。
需求获取
设计最初就需要进行需求获取，然后才能进行需求定义。一方面，有用的信息应当通过观察人们在工作环境中的活动来获得，因此可以通过观察来获取需求。一般来说，观察存在两种方式，直接观察和间接观察。直接观察要求观察者直接陪同他们工作来获得信息，应该尽可能不打扰被观察者的日常活动；间接观察可以使用视频或者录音来获得信息。
另一方面，可以通过场景来获取需求。场景是表示任务和工作结构的“非正式的叙述性描述”，它以叙述的方式描述人的行为或任务，设计者便可从中发掘出任务的上下文环境和用户的需求。场景的形式多样，可以是一个小故事、一段剧本等。
例：图书馆目录服务系统的潜在用户场景
“我要查找 George Jeffries 写的书，但不记得书名，只知道它是在 1995 年前出版的。我在目录系统中输入口令。我不明白为什么要输入口令，但不这么做我就无法进入图书馆系统，使用目录服务。系统确认了口令之后，显示了一些检索选项，如根据作者或日期检索，但不能结合两者进行检索。我选择了基于作者的检索，因为根据日期的检索通常会返回过多的书目。约 30 秒后，系统返回了结果，说没有找到George Jeffries 写的书，也列出了一些最接近的匹配书目。在浏览了这个清单后，我发现把作者的名字弄错了，应该是 Gregory 而不是 George。于是。我选择了想要的书目，系统即显示了它的位置。”
以上的场景说明了：
- 正确输入作者姓名的重要性
- 用户对输入口令感到反感
- 应提供更灵活的检索方法
- 在匹配不成功时，应给出相近的检索结果
之后，可以根据人物角色和场景剧本来进行需求定义。
需求定义
创建问题和前景综述
- 问题综述：应该简明地反映需要改变的情况（一般来说是负面的）。
- 前景综述：问题综述的倒置，简述应用该产品带来的改善。
构建情境场景剧本
- 头脑风暴：允许设计师以开放和灵活的方式想象来构建场景剧本
- 确定人物角色的期望：一个人的心理模型通常是根深蒂固的，因此需据此确定人物角色在使用产品体验方面可能有的一般期待和愿望。
- 构建剧本：应当关注人物角色的活动及其心理模型和动机，将注意力集中在设计的产品中怎样能够最好地帮助你的人物角色达到目标。应当做到广而浅，专注于高层次的从用户角度描述的行动，即与用户目标相关。
与关键情景场景剧本的区别
后面我们会在设计环节提到关键情景场景剧本，与现在需求阶段的情景场景剧本是不同的。这里的情景场景剧本更侧重于情景，只需说明白在哪些环节用户需要用到我们的系统即可，不包括具体的交互细节。而关键情景场景剧本则是更加详细的描述，包括具体的交互细节。
确立需求
根据情景场景剧本，确定数据需求（与对象相关的宾语或形容词）、功能需求（系统对象必须进行的操作，最终形成界面控件）以及其他需求。
需求验证
原型法
原型：在某一方面和真正产品比较接近、方便人们能对这一方面的各种技术方案进行不断评估和改进的一种接近于实际产品的模型。
概念模型和心智模型
概念模型：对系统如何组织和操作的高级描述。
心智模型：用户对系统的感知和认识。
制作原型之前要首先关注用户的心智模型。理想情况下，用户的心智模型应该与设计师的概念模型相同。
隐喻是一种设计的方法，通常是基于物理世界的类比，可以让用户更好理解底层的概念模型，并使计算机领域及其应用程序更容易被更多不同的用户访问。
原型分为低保真模型（草图、故事板、绿野仙踪法）和高保真模型。前者可以简单快速开发出来，但是与最终产品不太相似；后者与最终产品更为接近，但制作时间长，难以修改，且会有风险：用户会认为原型就是系统，开发人员可能认为已找到了一个用户满意的设计。因此，低保真模型是大多数项目的首选。
原型还可以分为水平原型和垂直原型。水平原型减少功能的深度并获得界面的表层，而垂直原型减少功能的数量而对项目的某些功能进行完整实现。
一个草图的例子
一个故事版的例子
原型的重要性在于：
- 评估和反馈：是交互设计的核心；
- 帮助用户明确需求：用户往往不能准确描述自己的需要 ，但在看到或尝试某些事物后，就能立即知道自己一定不需要什么；
- 直观：与文档相比，涉众能够更容易地看到、持有和与原型进行交互；
- 有效沟通：团队成员能够有效沟通；
- 备选：设计师可以利用原型在备选方案中进行选择。
任务分析
任务分析是记录人们如何完成任务的一种方式，对用户体验至关重要。层次化任务分析
任务分析是一个迭代过程。其分解的终止点有两种情况：
- 任务包含了复杂机械响应的地方，如鼠标移动等；
- 涉及内部决断（即用户自主决策）的地方，如“选择感兴趣的商品”等。但如果决断和查找文档等外部动作相关，则分解应当继续。
在具体绘图时，对于每个节点，内部写出任务的内容（一般为动宾短语），右下角写出任务的编号。从树根走向叶结点，编号以
层次化任务分析真题