文章目录
1. 前言
本课叫Human-Centric Computing（以人为中心的计算），而非传统的人机交互（HCI，Human-Computer Interaction），HCI 是一门研究人与计算机之间交互方式的学科，主要关注如何设计、评估和改进用户与计算机系统的交互体验。而本课的要求较低一些，是一种更广泛的跨学科领域，强调将人类的需求、能力和体验作为技术设计的核心。
我们将在本课程中尝试以Coursework为实践，尝试让学生能够了解在设计现代计算机系统用户界面是，能够按照一种有条理、系统化的流程来进行规划、开发和测试。
因此Coursework更专注于设计，而不是具体的设计。设计、原型制作和评估过程才是关键。
交互设计与多个领域和实践相关联，如下图所示。
Sharp, Rogers, 和 Preece 在2019年将交互设计定义为：“设计交互式产品以支持人们在日常和工作生活中沟通和互动的方式。”
我们在生活中可能没有太注意身边的交互设计，但是我们一般在多个产品出现的时候我们一般都喜欢用自己顺手的，这里很可能就是我们在多种交互方式中选择了一种自己喜欢的。比如当我们想放大一样东西的时候，我们是想如何放大呢？是直接一个按钮让你按下就能放大，还是你更喜欢两根手指从内向外拉呢？又或者说有一个拟物的放大镜给你让你摆到想放大的物体上呢？这里就有多种交互方式，它们都是为了完成放大这个互动功能而设计的产品。
下图展示了一个交互设计的生命周期（Interaction Design Lifecycle）。它和我们之前学习的软件工程里的过程类似。
这是一个迭代的过程，有四个部分组成。
1.发现需求（Discovering Requirements）：
这是交互设计过程的起始阶段，设计师需要了解用户的需求、目标和期望。这通常涉及用户研究、市场分析和需求收集。
2.设计备选方案（Designing Alternatives）：
在这个阶段，设计师基于收集到的需求信息，探索和创建不同的设计方案。这可能包括草图、线框图、故事板等初步设计。
3.原型制作（Prototyping）：
设计师将选定的设计方案转化为原型，这些原型可以是低保真或高保真的，用于模拟产品的实际使用情况。原型制作有助于在开发完整产品之前测试和验证设计。
4.评估（Evaluating）：
在这个阶段，设计师通过用户测试、专家评审等方式评估原型的有效性、可用性和用户满意度。评估结果将用于改进设计。
经过多次迭代和评估后，设计师将最终确定设计方案，并开发出最终产品（Final product）。这个阶段可能还包括产品的发布和后续的支持。
2. 交互设计（Interaction Design）
2.1 定义
我们前面就提到过，Sharp, Rogers, and Preece (2019)的定义为：“设计交互式产品以支持人们在日常和工作生活中沟通和互动的方式。”（“Designing interactive products to support the way people communicate and interact in their everyday and working lives.”）
Winograd (1997)的定义为：“为人类沟通和互动设计空间。”（ “The design of spaces for human communication and interaction.” ）
2.2 种类
交互有很多种类，例如：
用户界面设计（User Interface Design, UI）：专注于设计用户与产品之间交互的界面。
软件设计（Software Design）：涉及软件的结构和组件的设计。
以用户为中心的设计（User Centered Design）：以用户的需求和体验为核心进行设计。
产品设计（Product Design）：设计实体产品的外观、功能和用户体验。
网页设计（Web Design）：设计网站的布局、外观和用户体验。
用户体验设计（User Experience Design, UX）：关注用户在使用产品过程中的整体体验。
交互系统设计（Interactive System Design）：设计能够与用户进行交互的系统。
交互设计是一个广泛的术语，它涵盖了上述所有方面。这意味着交互设计不仅关注用户界面或用户体验，而是包括了所有与设计交互式产品相关的领域。
交互设计是所有学科、领域和方法的基础，这些学科、领域和方法都涉及到研究和设计以人为中心的计算机系统。
2.3 特点
至此我们可以发现交互本来就是以人或者说用户为核心的，所以交互设计有以下三个特点。
1.用户应参与项目的整个开发过程：
在交互设计中，用户的参与是至关重要的。设计师需要与用户进行持续的沟通和协作。用户的反馈和需求应该被纳入设计过程中，以确保最终的产品能够满足用户的实际需求。
2.需要在项目开始时明确、记录并同意具体的可用性和用户体验目标：
在项目启动之初，就需要确定并记录具体的目标，这些目标涉及产品的可用性（即用户使用产品的难易程度）和用户体验（即用户使用产品时的整体感受）。这些目标应该是清晰、可衡量的，并且需要所有项目参与者的认同。
3.需要通过核心活动进行迭代：
迭代是交互设计过程中的一个关键概念。它意味着设计不是一次性完成的，而是通过不断的测试、评估和改进来逐步完善的。设计师会创建原型，然后通过用户测试来收集反馈，根据这些反馈对设计进行调整，然后再进行测试，如此反复，直到达到既定的可用性和用户体验目标。
2.3.1 用户应参与项目的整个开发过程
那么用户参与进项目有什么好处呢？
好处如下：
1.理解用户目标，从而创造出更好的产品。
2.期望管理：
通过让用户参与，可以建立和管理他们对产品的期望。
现实的期望：确保用户对产品的功能和性能有现实的期望。
无惊喜、无失望：通过透明的沟通，避免用户对产品有不切实际的期望，从而减少失望。
及时的培训：为用户提供必要的培训，帮助他们更好地理解和使用产品。
沟通，但不夸大：与用户进行开放和诚实的沟通，避免过度宣传或夸大产品的功能。
3.所有权：
让用户成为积极的参与者，而不仅仅是被动的接受者。
让用户成为积极的股东：让用户感到他们是产品开发过程的一部分，从而增加他们对产品的投入和认同。
更可能原谅或接受问题：当用户感到自己是产品开发的一部分时，他们更有可能对产品中出现的问题持宽容态度。
对产品的接受度和成功产生重大影响：用户的积极参与可以显著提高他们对产品的接受度，这对产品的成功至关重要。
当然参与的程度和方式也有多种。
1.作为设计团队的成员：
全职：用户作为团队的全职成员，可以提供持续的输入，但可能会失去与更广泛用户群体的联系。
兼职：用户作为团队的兼职成员，可以提供不定时的输入，但这可能导致信息的不连贯，并且对用户来说可能非常有压力。
参与式设计：在设计的早期阶段，让所有利益相关者参与进来，以确保设计过程中考虑到所有用户的需求和观点。
2.面对面的小组或个人活动：
这包括用户访谈、焦点小组讨论、用户测试等，这些活动允许设计师直接与用户互动，收集反馈和见解。
来自成千上万用户的在线贡献：
3.在线反馈交换系统（Online Feedback Exchange, OFE）：通过在线平台收集用户反馈，以便快速、广泛地了解用户的意见。
众包设计想法：通过公开征集设计想法，利用大量用户的创造力和专业知识。
公民科学：鼓励普通公众参与科学研究，这在设计领域可以转化为让用户参与到产品的开发和测试中。
4.产品发布后的用户参与：
客户评论分析：分析用户在产品发布后的评价和评论，以了解用户对产品的满意度和可能存在的问题。这有助于产品的持续改进和迭代。
2.3.2 需要在项目开始时明确、记录并同意具体的可用性和用户体验目标
2.3.2.1 可用性目标（Usability goals）
那什么是可用性目标呢？
可用性目标的例子如下。
1.使用效果（Effectiveness）：
指产品在帮助用户完成任务方面的有效性。一个有效的产品能够让用户成功地完成他们的任务，达到他们使用产品的目的。
2.使用效率（Efficiency）：
指用户使用产品完成任务的速度和容易程度。效率高的产品可以让用户以最少的时间和努力完成任务。
3.使用安全性（Safety）：
指产品在被使用时对用户和环境的安全性。安全的产品不会导致用户受伤或损害他们的数据和设备。
4.具有良好的实用性（Utility）：
指产品提供的功能和特性是否对用户有用。实用性高的产品能够满足用户的实际需求。
5.易学性（Learnability）：
指用户学习和掌握如何使用产品的容易程度。易学的产品让用户能够快速理解如何操作，而不需要复杂的培训或指导。
6.易记性（Memorability）：
指用户在一段时间不使用产品后，重新使用时回忆起如何操作的容易程度。易记的产品让用户在需要时能够迅速回忆起如何使用，而不需要重新学习。
2.3.2.2 用户体验目标（User Experience goals）
那什么是用户体验目标呢？
用户体验目标的例子如下，主要分为积极的或者说是理想的以及消极的或者说是不理想的。
理想的用户体验方面（Desirable aspects）：
令人满意（Satisfying）：用户感到产品或服务达到了他们的期望。
有帮助（Helpful）：用户觉得产品或服务对他们有用。
有趣（Fun）：用户在使用过程中感到愉悦和娱乐。
令人愉快（Enjoyable）：整体体验是积极的。
激励人心（Motivating）：产品或服务能够激发用户的积极性。
引人深思（Provocative）：能够激发用户的思考或讨论。
吸引人（Engaging）：用户被产品或服务深深吸引。
具有挑战性（Challenging）：提供适度的挑战，使用户感到成就感。
令人惊讶（Surprising）：提供意外的乐趣或功能。
令人愉悦（Pleasurable）：使用体验本身就是一种享受。
增强社交性（Enhancing sociability）：促进用户之间的社交互动。
有回报（Rewarding）：用户感到他们的投入得到了回报。
令人兴奋（Exciting）：激发用户的兴趣和热情。
支持创造力（Supporting creativity）：鼓励用户发挥创造力。
情感满足（Emotionally fulfilling）：在情感层面上满足用户。
娱乐性（Entertaining）：提供娱乐价值。
认知刺激（Cognitively stimulating）：激发用户的思维和认知活动。
体验流畅（Experiencing flow）：用户进入一种完全投入的状态，感到时间飞逝。
不理想的用户体验方面（Undesirable aspects）：
无聊（Boring）：用户感到产品或服务缺乏吸引力。
不愉快（Unpleasant）：整体体验是消极的。
令人沮丧（Frustrating）：用户在使用过程中感到挫败。
居高临下（Patronizing）：产品或服务让用户感到被轻视或不被尊重。
让人感到内疚（Making one feel guilty）：使用体验引发用户的内疚感。
让人感到愚蠢（Making one feel stupid）：用户感到自己在使用产品时显得笨拙或无知。
烦人（Annoying）：产品或服务引起用户的不满或烦恼。
过于可爱（Cutesy）：设计过于甜腻或幼稚，可能引起反感。
幼稚（Childish）：设计缺乏成熟度，不适合目标用户群体。
花哨（Gimmicky）：依赖于噱头或小把戏，缺乏实质性价值。
用户体验和可用性相比，用户体验包含可用性的一部分，可用性差就可能导致用户又不理想的用户体验，相反亦然。用户体验除了包含可用性之外，还包括了更多的情感、感官和价值层面的因素。因此可用性目标更客观，它关注的是系统本身的有用性或生产力，即从系统的角度来看，它在多大程度上能够满足用户的需求和完成任务。而用户体验目标更主观，它关注的是用户在使用交互式产品时的个人感受，即从用户的角度来看，他们对产品的体验如何。
可用性和用户体验之间其实没有明确的分界线。它们是相互关联的，共同影响用户对产品的总体感受。有时，可用性和用户体验目标之间可能存在冲突，因此需要在这两个目标之间进行权衡。
历史上，人机交互（HCI）主要关注可用性，即如何使系统易于使用和高效。然而，随着时间的推移，HCI领域已经扩展到更广泛地理解和设计用户体验，以及评估用户体验的各个方面，也就是更偏向人文。
2.4 交互设计的过程
这便是我们前面讲的交互设计的生命周期，它有四个基本活动组成。
1.发现交互产品的需求（Discovering requirements for the interactive product）：
在设计开始之前，需要通过用户研究、市场分析、利益相关者访谈等方式来识别和理解用户的需求。这一步骤是确保设计的产品能够满足用户实际需求的基础。
2.设计满足这些需求的备选方案（Designing alternatives that meet those requirements）：
根据收集到的需求信息，设计师会探索和创造多种设计方案。这些方案可能包括不同的界面布局、交互流程、功能特性等，以满足用户的需求。
3.制作备选设计的原型以便进行沟通和评估（Prototyping the alternative designs so that they can be communicated and assessed）：
设计师会将选定的设计方案转化为原型。原型可以是低保真的草图、线框图，也可以是高保真的交互式模型。原型的目的是让设计师和用户能够直观地看到设计的外观和行为，并对其进行评估和讨论。
4.在整个过程中评估产品及其提供的用户体验（Evaluating the product and the user experience it offers throughout the process）：
在设计过程的每个阶段，都需要对产品和用户体验进行评估。这可能包括用户测试、专家评审、可用性测试等方法。评估的目的是收集反馈，了解设计的优缺点，并根据反馈进行迭代改进。
除了前面说的生命周期图，下图为设计的双重钻石模型（The double diamond of design），这是一个常用于设计流程的框架，它也反映了交互设计的过程。
这个模型将设计过程分为四个主要阶段，每个阶段都聚焦于发现、定义、开发和交付的过程：
1.发现（Discover）：
深入了解问题。在这个阶段，设计师进行广泛的研究，以了解用户的需求、问题和背景。目标是收集尽可能多的信息，以便更好地理解设计挑战。
2.定义（Define）：
确定要关注的问题区域。在收集了足够的信息后，设计师将这些信息整合，以明确问题的核心。这个阶段的输出通常是设计简报（Design Brief），它概述了要解决的问题。
3.开发（Develop）：
探索潜在的解决方案。设计师将创意思维应用于定义的问题，生成多种可能的解决方案。这是一个创造性的过程，鼓励创新和多样化的想法。
4.交付（Deliver）：
实现有效的解决方案。在这个阶段，设计师将选定的解决方案转化为实际的设计，并进行测试和评估，以确保它们能够解决定义的问题，并满足用户的需求。
第一个钻石聚焦于问题的理解和定义，第二个钻石聚焦于解决方案的生成和实现。
与前面的生命周期图类似，这个图也是非线性的，它反映了设计不是线性的直线，而是需要在不同阶段之间来回迭代的。
那我们现在如何从第一步发现问题开始呢？（探索问题空间）
我们不妨先问自己几个问题：
1.当前用户体验是什么？
2.为什么需要改变？
3.这种改变将如何改善情况？
在对问题进行完探索之后，我们需要尝试将问题表达出来，在这一环节需要注意（阐述问题空间）：
1.团队努力。
2.探索不同视角。
3.避免错误的假设和无根据的主张。
除了上面说了这两个模型之外，还有其他的模型。
比如我们现在发现这里的交互设计与之前的软件工程有些类似，因此当然比如敏捷开发中的Scrum架构就是符合前面说的不断迭代。
比如下图展示的是Google的设计冲刺流程。
下图是2017年Rogers和Marshall提出的研究框架。
交互设计是一个专注于发现需求、设计满足这些需求、制作原型以及评估这些原型的过程，它以用户及其目标为核心，并涉及权衡相互冲突的需求。生成多种备选方案并在它们之间进行选择是交互设计的关键。正如诺贝尔化学奖得主莱纳斯·鲍林（Linus Pauling）所说，“获得好主意的最佳方式是先获得很多主意”。
2.5 交互设计中的实践问题
以用户为中心的设计方法遵循三个核心原则：
1.早期关注用户和任务：
在设计的初期阶段就将用户及其任务作为焦点。这涉及到直接研究用户的认知（如何思考）、行为（如何行动）、人体工程学（身体特征）以及态度（情感和偏好）等特征。通过了解用户的需求和能力，设计师可以创建更符合用户实际使用情境的解决方案。
2.实证测量：
通过观察、记录和分析用户对场景、手册、模拟和原型的反应和表现来进行。这种方法依赖于实际数据和用户反馈，而不是假设或猜测。实证测量可以帮助设计师了解用户如何与产品互动，以及他们在使用过程中遇到的问题。
3.迭代设计：
当在用户测试中发现问题时，设计师需要修复这些问题并进行更多的测试。迭代设计是一个循环过程，涉及不断的设计、测试、评估和改进。这种方法允许设计师根据用户反馈逐步优化产品，直到达到满意的用户体验。
2.5.1 早期关注用户和任务
1.用户的任务和目标是发展的驱动力：
设计过程应以用户的任务和目标为核心，确保开发的产品或服务能够满足用户的实际需求和期望。
2.研究用户的行为和使用环境，并设计系统以支持他们：
设计师需要了解用户的行为模式和使用产品的具体环境，然后设计出能够支持这些行为和环境的系统。
3.捕捉并设计用户的特征：
设计师需要识别和理解用户的各种特征，包括他们的能力、限制、偏好等，并确保设计能够适应这些特征。
4.在开发的各个阶段都咨询用户：
从项目的最早阶段到最终阶段，设计师应持续与用户进行沟通和咨询，以确保设计决策与用户的需求和期望保持一致。
5.所有设计决策都是在用户、他们的活动和环境的背景下做出的：
设计决策应基于对用户、他们的活动和使用环境的深入理解。这意味着设计应考虑到用户的具体情况和环境因素，以确保最终产品能够适应用户的现实世界需求。
因此在这一阶段可能会遇到的问题有：
1.不了解用户有哪些。
2.不了解用户的需求有哪些。
2.5.1.1 用户有哪些
1.用户可能并不总是显而易见的：
用户群体可能非常多样化，例如，智能手机应用可能有382种不同的用户类型（根据Zhao等人2016年的研究）。
许多产品旨在供广大人群使用，这时用户可以被泛指为“所有人”。
更有针对性的产品可能与特定的角色或用户群体相关，例如专业软件可能专为医生、律师或工程师设计。
2.利益相关者：
利益相关者是指那些能够影响或可能受到项目成功或失败影响的个人或团体。
利益相关者的范围比直接用户群体更大，可能包括投资者、合作伙伴、供应商、监管机构等。
识别利益相关者有助于确定哪些群体应参与交互设计活动。
2.5.1.2 用户需求有哪些
1.用户通常不知道什么是可能的：
用户可能无法完全理解技术的可能性，因此他们可能无法准确表达他们的需求。这可能导致“未被梦想过”的需求，即用户甚至没有意识到他们需要某些功能或解决方案。
2.相反，应该采取以下措施：
探索问题空间：深入了解问题的本质，包括用户的需求、痛点和期望。
调查用户是谁：了解目标用户群体的特征，包括他们的行为、偏好和限制。
调查用户活动：研究用户在日常生活中的活动和任务，以及他们如何与产品或服务互动。
尝试想法：与潜在用户一起测试想法，看看哪些方面可以改进。
3.关注人们的目标、可用性和用户体验目标：
设计应该集中在帮助用户实现他们的目标上，提高产品的可用性（即产品的易用性），以及提供积极的用户体验。
而不是期望利益相关者明确表达需求：利益相关者可能更关注业务目标或技术限制，而不是用户的实际需求。因此，设计师需要主动探索和理解用户的需求，而不是仅仅依赖利益相关者的输入。
3. 发现需求（Discovering Requirements）
从前面的过程中我们已经知道了要了解用户需求的重要性，或者说我们的一切产品设计从需求出发，市场是否有这样的需求？比如我现在发现人们不喜欢画面的卡顿，为了解决这个卡顿我想的是在平时就做穿插一些卡顿，这样可以让用户习惯卡顿，但是很明显人们的需求是不希望出现卡顿，而不是习惯卡顿，因此不了解用户的需求会导致错误的设计，或者如果一个产品的需求不足，那它的贡献值或者说用户群体就会比较小。
也有可能市场上已经有了这样的产品，我们应该了解用户们对这些产品有哪些痛点，我们应该尝试设计出更好的，符合用户新的需求的产品，而不是做重复的产品。
因此这一环节跟之前学习的软件工程的需求工程类似，我们需要先去尝试了解用户的需求，才能知道团队应该设计什么样的产品。
捕捉需求的意义主要有以下三点：
1.捕捉需求是为了确保设计和开发团队对项目的目标和用户的需求有共同的理解。
2.明确的需求有助于避免误解和重复工作，提高项目的效率和成功率。
3.通过不同的捕捉机制，可以更全面地理解和分析需求，从而设计出更符合用户期望的产品。
因此发现需求的目的如下：
1.探索问题空间以获得洞察：通过研究和分析，深入了解问题的本质，包括用户的需求、期望和痛点。
2.建立将要开发内容的描述：明确将要开发的产品或服务的功能、特性和目标，为设计和开发提供指导。
如何捕捉需求呢？
1.在原型或操作产品中：通过创建原型或初步产品来展示和测试需求，这有助于更直观地理解和验证需求。
2.通过结构化或严格的符号表示：使用正式的文档、图表或其他符号系统来记录和描述需求，确保清晰和一致性。
3.明确记录关键需求是好的：详细记录关键需求有助于保持项目的焦点，并为后续的设计和开发提供明确的指导。
4.不同的捕捉机制强调和淡化不同的方面：不同的方法可能会突出或忽略需求的不同方面，选择合适的方法可以更有效地捕捉和理解需求。
下图是一张我们经常能在很多地方可能看到的关于需求沟通的一个笑话。
客户想要一个秋千，但是不同的人可能有不同的理解，最后不同部分有不同的理解和产物，类似于一百个人心中有一百个哈姆雷特。
3.1 需求的定义
前面说了那么多，那么到底什么是需求呢？
需求是对于预期产品或系统应该做什么、如何表现或执行的具体陈述。（Requreiment is a statement about an intended product that
it is expected to do specifies what or how it will perform。）
需求可以有不同的形式和不同层次的抽象，具体包括：
1.基本需求（Atomic requirements）：
基本需求是不可再分的最小需求单元，它们是具体、明确且独立的。这些需求通常非常详细，可以直接用于设计和开发。
2.用户故事（User stories）：
用户故事是一种以用户为中心的需求表达方式，它们描述了用户使用产品的目的和他们期望获得的价值。用户故事通常遵循这样的格式：“作为[某个角色]，我希望[执行某个动作]，以便[实现某个目标]”。它们有助于团队理解用户的需求和动机，并促进团队与用户的沟通。
3.1.1 基本需求（Atomic requirements）
Robertson和Robertson在2013年提出了基本需求框架（Atomic Requirements Shell），如下图所示。
需求编号（Requirement #）：每个需求的唯一标识符。
需求类型（Requirement Type）：需求的类别或类型。
事件/用例编号（Event/use case #s）：与需求相关的事件或用例列表。
描述（Description）：用一句话概括需求的意图。
理由（Rationale）：需求的合理性说明。
提出者（Originator）：提出该需求的人。
适应性标准（Fit Criterion）：衡量需求的方法，以测试解决方案是否符合原始需求。
客户满意度（Customer Satisfaction）：如果需求成功实施，利益相关者满意程度的衡量。
客户不满（Customer Dissatisfaction）：如果需求未成为最终产品的一部分，利益相关者不满程度的衡量。
优先级（Priority）：客户价值的评级。
支持材料（Supporting Materials）：指向文档的指针，这些文档记录了需求的创建、变更、说明和解释。
冲突（Conflicts）：如果该需求与其他需求存在冲突，其他无法实现的需求。
下面两张图展示了这样框架的两个例子。
3.1.2 用户故事（User stories）
用户故事通常遵循以下格式：“作为[某个角色]，我希望[执行某个动作]，以便[实现某个目标]”。
对于一个旅行组织者应用，一些用户故事示例可能包括：
作为旅行者，我希望保存我最喜欢的航空公司用于所有航班，以便我能够积累航空里程。
作为旅行社，我希望显示我的特别折扣率，以便我可以向我的客户提供有竞争力的费率。
就像我们之前学习软件工程的那样，用户故事在敏捷开发环境中最为常见。
更多的示例如下：
1.作为用户，我希望在运动应用中有一个改进的社交社区功能，类似于Keep应用，以便我可以与其他健身爱好者建立联系，分享我的进展，并从社区中获得动力。
2.作为用户，我希望在应用中有一个个人资料页面，以便我可以自定义我的个人信息并查看我的健身进展。
3.作为用户，我希望加入健身团体或社区，以便我可以与其他健身爱好者建立联系，并从他们那里获得动力。
4.作为用户，我希望有一个排行榜功能，以便我可以与其他用户竞争，并激励自己实现我的健身目标。
5.作为用户，我希望有一个聊天功能，以便我可以实时与其他用户交流，并从他们那里获得动力和支持。
6.作为用户，我希望有一个功能，允许我将我的健身进展分享到社交媒体，以便我可以激励我的朋友，并从他们那里获得鼓励。
3.2 需求的类型
当然需求分成功能性需求（Functional requirements）和非功能性需求（Non-functional requirements）。
3.2.1 功能性需求（Functional requirements）
描述系统应该执行哪些功能。
它们定义了产品必须实现的具体行为或功能。
示例：对于一款电子游戏来说，功能性需求可能包括“它将为不同能力范围的用户提供挑战”。
3.2.2 非功能性需求（Non-functional requirements）
描述产品的特征或约束条件，这些通常与产品的性能、可靠性、可用性、安全性等方面相关。
它们定义了产品应该如何执行其功能，而不是具体执行哪些功能。
示例：对于一款电子游戏来说，非功能性需求可能包括“它可以在多种平台上运行，例如微软Xbox、索尼PlayStation和任天堂Switch游戏系统”。
3.2.3 全面类型
下图展示了一个全面的需求类型分类，由Suzanne和James Robertson在2013年提出。
项目驱动因素（Project Drivers）
1.产品的目的（The Purpose of the Product）：定义产品的目标和预期成果。
2.利益相关者（The Stakeholders）：识别所有对项目有影响或受项目影响的个人或团体。
项目约束（Project Constraints）
3.强制约束（Mandated Constraints）：项目必须遵守的规则或限制。
4.命名规范和术语（Naming Conventions and Terminology）：项目中使用的统一命名和术语。
5.相关事实和假设（Relevant Facts and Assumptions）：项目基于的事实和假设条件。
功能性需求（Functional Requirements）
6.工作范围（The Scope of the Work）：项目的具体工作内容。
7.业务数据模型和数据字典（Business Data Model and Data Dictionary）：描述业务数据结构和定义。
8.产品范围（The Scope of the Product）：产品的功能和特性范围。
9.功能性需求（Functional Requirements）：产品应执行的具体功能。
非功能性需求（Nonfunctional Requirements）
10.外观和感觉需求（Look and Feel Requirements）：产品的用户界面和用户体验。
11.可用性和人性化需求（Usability and Humanity Requirements）：产品的易用性和用户友好性。
12.性能需求（Performance Requirements）：产品的性能标准，如速度和响应时间。
13.操作和环境需求（Operational and Environmental Requirements）：产品的操作条件和环境因素。
14.可维护性和支持需求（Maintainability and Support Requirements）：产品的维护和支持能力。
15.安全需求（Security Requirements）：产品的安全特性和保护措施。
16.文化需求（Cultural Requirements）：产品在不同文化背景下的适应性。
17.合规需求（Compliance Requirements）：产品必须遵守的法律法规。
项目问题（Project Issues）
18.开放问题（Open Issues）：尚未解决的问题。
19.现成解决方案（Off-the-Shelf Solutions）：可以使用的现有解决方案。
20.新问题（New Problems）：项目过程中出现的新问题。
21.任务（Tasks）：项目中的具体任务。
22.迁移到新产品（Migration to the New Product）：从旧产品迁移到新产品的计划。
23.风险（Risks）：项目可能面临的风险。
24.成本（Costs）：项目的成本预算。
25.用户文档和培训（User Documentation and Training）：用户手册和培训计划。
26.等待室（Waiting Room）：暂缓处理的需求或问题。
27.解决方案的想法（Ideas for Solutions）：对问题的潜在解决方案。
下图展示了产品的七个维度的模型，由Gottesdiener和Gorman在2012年提出。
1.用户（User）：
用户与产品的互动。这涉及到用户如何使用产品，以及他们的需求和体验。
2.界面（Interface）：
产品如何连接用户、系统和设备。这包括用户界面（UI）和用户如何与产品进行交互。
3.行为（Action）：
产品为用户提供的能力。这涉及到产品的功能和用户可以执行的操作。
4.数据（Data）：
产品包含数据和有用信息的存储库。这包括产品需要处理、存储和提供的数据。
5.控制（Control）：
产品执行的约束。这涉及到产品如何控制其操作和用户如何控制产品。
6.环境（Environment）：
产品符合物理属性和技术平台。这包括产品在不同环境下的兼容性和性能。
7.质量属性（Quality Attribute）：
产品具有某些属性，这些属性决定了其操作和开发的质量。这可能包括性能、可靠性、可用性、安全性等。
3.2.4 六种最常见的需求类型
1.功能性需求（Functional requirements）：
描述系统应该执行哪些功能。
它们定义了产品必须实现的具体行为或功能。
功能性需求通常关注“系统应该做什么”，即系统需要完成的任务或操作。
例如，对于一个在线购物系统，一个功能性需求可能是“用户能够将商品添加到购物车”。
2.数据需求（Data requirements）：
描述系统需要存储哪些类型的数据。
涉及数据的类型、结构、来源以及数据如何被存储和管理。
数据需求通常关注“需要存储哪些数据”以及“这些数据将如何被存储”（例如，在数据库中）。
例如，对于一个客户关系管理（CRM）系统，数据需求可能包括存储客户的联系信息、购买历史和偏好设置。
3.环境需求（Environment requirements）或使用环境（Context of use）：
物理环境（Physical）：产品将在何种物理条件下运行？例如，是否有灰尘、噪音、振动、光线、热量、湿度等。这些条件可能对产品的硬件和软件有特定的要求，例如在医院环境中，产品可能需要能够抵抗频繁的清洁和消毒。
社会环境（Social）：产品将如何在社会环境中使用？这包括协作和协调、数据共享、分布（distributed）、同步（synchronous）或异步（asynchronous）操作、隐私等。例如，一个团队协作工具可能需要支持实时数据共享和隐私保护。
组织环境（Organizational）：产品将在何种组织环境中使用？这涉及到用户支持、通信结构和基础设施、培训的可用性等。例如，一个企业内部的管理系统可能需要与现有的IT基础设施兼容，并提供员工培训。
技术环境（Technical）：产品将在哪些技术上运行或需要兼容？这包括硬件、软件、网络、操作系统、数据库等技术平台。例如，一个应用程序可能需要在多种操作系统上运行，或者需要与特定的数据库系统兼容。
4.用户特征（Users characteristics）：
国籍、教育背景、对计算机的态度：这些因素可能影响用户与系统的交互方式和他们对技术的接受程度。
系统使用情况（System use）：用户如何使用系统，以及他们的使用频率和熟练程度。
- 新手（Novice）：可能需要更多的提示、限制和清晰的指导来帮助他们理解和使用系统。
- 专家（Expert）：可能需要灵活性、高级功能和快速访问以提高效率。
- 频繁用户（Frequent）：可能需要快捷方式或高级功能来加快他们的工作流程。
- 偶尔/不频繁用户（Casual/infrequent）：可能需要清晰的菜单路径和直观的界面来简化他们的使用体验。
用户画像（User profile）：创建用户画像是一种常见的方法，用于描述目标用户群体的典型特征。用户画像通常包括用户的基本信息、行为习惯、需求和目标等，帮助设计团队更好地理解用户并设计出符合他们需求的产品。
5.可用性目标（Usability goals）：
这些目标关注产品如何被用户有效、高效、安全地使用。可用性目标确保产品易于学习和操作，减少错误，并提供满意的使用体验。
例如，一个软件应用的可用性目标可能包括减少用户完成任务的时间、提高任务完成的准确率、减少用户操作中的错误等。
6.用户体验目标（User experience goals）：
这些目标关注用户在使用产品过程中的整体感受，包括情感、满意度、愉悦度等。用户体验目标旨在创造积极、有意义且令人难忘的体验。
例如，一个网站的用户体验目标可能包括提供吸引人的视觉设计、确保流畅的导航体验、以及创造一种社区感或归属感。
3.3 数据收集方法
收集需求时常用的一些数据收集方法：
1.访谈（Interviews）：
通过与用户、利益相关者或领域专家进行面对面的交谈来获取需求信息。
2.观察（Observations）：
直接观察用户在自然环境中如何使用产品或执行任务，以了解他们的行为和需求。
3.问卷调查（Questionnaires）：
通过分发问卷来收集大量用户的意见和反馈，这可以是纸质的或电子的。
4.研究文档（Studying documentation）：
查阅相关的文档资料，如手册、流程图、政策文件等，以获取需求信息。
文档中通常记录了操作程序和规则，是了解活动涉及的步骤和任务管理规定的好来源。
有助于理解相关法规和获取背景信息。
不需要利益相关者参与，可以独立进行。
5.研究类似产品（Researching similar products）：
研究市场上现有的类似产品，了解它们的功能、用户界面和用户体验。
这有助于激发新的需求想法，了解行业标准和最佳实践。
详细的数据手机和用户研究的方法如下：
1.观察（Observation）：
直接观察：研究人员直接观察用户的行为和交互。
间接观察：通过视频记录、日志等间接方式观察用户行为。
2.访谈（Interviews）：
个人访谈：与单个用户进行深入的一对一交谈。
群体访谈：与一组用户进行讨论，了解他们的观点和需求。
3.日记研究（Diaries）：
用户记录他们使用产品的日常体验和感受，研究人员定期收集这些日记进行分析。
4.调查（Surveys）：
通过问卷调查收集大量用户的意见和反馈。
5.思维大声（Think-aloud evaluation）：
用户在使用产品时大声说出他们的想法，研究人员记录这些口头表达来了解用户的思维过程。
6.工作原型评估（Working prototype evaluation）：
让用户测试一个功能完整的原型，并收集他们的反馈。
7.研究文档（Studying documentation）：
审查相关文档，如用户手册、技术规范等，以获取需求信息。
8.评估其他系统（Evaluating other systems）：
研究和评估市场上的其他类似系统，以了解它们的优势和不足。
9.人种学研究（Ethnographic study）：
在自然环境中观察和研究用户的行为和文化背景。
10.可用性测试（Usability tests）：
通过一系列任务测试产品或原型的可用性，并收集用户的反馈。
3.3.1 探针（probes）
使用探针（probes）与用户互动是一种用户研究方法，旨在通过特定的工具或活动来激发用户的反馈和行为，从而帮助研究人员更深入地了解用户的需求、习惯和体验。
1.多种类型的探针（Many types of probe）：
探针可以采取多种形式，包括问卷、访谈指南、日记、任务卡片、情境模拟等。
每种探针设计都有其特定的目的和应用场景，可以根据研究目标和用户群体的特点来选择。
2.设计用于激发用户行动（Designed to prompt users into action）：
探针通常包含一些开放性问题或任务，鼓励用户分享他们的想法、感受和行为。
例如，研究人员可能会给用户一个任务卡片，要求他们完成特定的任务，并记录他们在这个过程中遇到的问题和需求。
3.供研究人员了解用户（For researchers to learn about users）：
通过分析用户对探针的响应，研究人员可以收集关于用户行为、需求和体验的宝贵信息。
这些信息有助于识别用户的问题、痛点和机会，为设计和改进产品提供依据。
使用探针方法的优势包括：
灵活性：探针可以根据研究目标和用户群体的特点进行定制，适用于各种研究场景。
互动性：探针通过与用户的互动来收集数据，可以激发用户更真实、更深入的反馈。
启发性：探针可以引导用户思考和探索他们的需求和期望，从而产生新的想法和见解。
然而，使用探针方法也需要注意：
设计质量：探针的设计需要精心设计，以确保它们能够有效地激发用户的行为和反馈。
数据分析：探针收集的数据通常是非结构化的，需要进行深入的分析和解释。
用户参与：探针方法需要用户的积极参与，可能需要一定的时间和资源来实施。
3.3.2 情景调查（Contextual Inquiry）
情景调查（Contextual Inquiry）是一种用户研究方法，它既可以作为情境设计（Contextual Design）的一部分，也可以单独使用来收集需求。
这种方法涉及在用户的自然环境中（如家中或工作场所）进行一对一的访谈，以便观察和了解用户的实际行为和工作环境。
情境访谈通常持续1.5到2小时，这段时间足够让研究者深入了解用户的日常工作流程和挑战。
访谈的重点是用户在家庭或工作场所的日常活动中与项目相关的部分。这有助于研究者理解用户的实际需求和使用场景。
在情境访谈中，用户被视为“师傅”，他们向“学徒”（研究者）展示他们的工作流程和技巧。这种模型鼓励用户在执行任务时进行思考和解释，而研究者则通过观察、提问和记录来学习用户的行为和需求。
情景调查的四个主要原则是该方法的核心，它们指导了研究者如何进行现场研究以收集需求。
1.情景（Context）：
研究者前往用户的所在地，无论是家里还是工作场所，直接观察用户在其自然环境中的行为和活动。这种方法确保了观察到的行为和交互是真实的，没有受到实验室环境的影响。
2.伙伴关系（Partnership）：
用户和研究者（或面试官）之间建立一种合作关系。他们共同探索用户的生活、工作流程和挑战。这种伙伴关系鼓励用户分享他们的经验和见解，同时也让研究者能够更深入地理解用户的需求和动机。
3.解释（Interpretation）：
观察到的行为和信息由用户和研究者共同解释。这意味着用户参与到数据分析过程中，他们的解释和观点对于理解观察结果至关重要。这种共同解释有助于确保研究者正确理解用户的行为和需求。
4.焦点（Focus）：
研究有一个明确的焦点，即项目的目标或需求。这有助于确保研究活动集中在对项目最相关的方面，从而提高研究的效率和效果。焦点帮助研究者确定应该关注哪些行为、任务或环境因素。
我们可以使用七个新颖的概念（cool concepts）来引导访谈，这些概念又被分为两组。
生活乐趣概念（Joy of Life Concepts）：
1.成就（Accomplish）：
产品应赋予用户力量，帮助他们完成任务和实现目标。
2.连接（Connection）：
产品应增强真实的人际关系，促进社交互动。
3.身份（Identity）：
产品应支持用户的自我认同感，反映他们的个性和价值观。
4.感觉（Sensation）：
产品应提供愉悦的时刻，增强用户的感官体验。
使用乐趣概念（Joy of Use Concepts）
1.行动中的直接性（Direction in action）
产品应直接满足用户的意图，提供即时的满足感。
2.麻烦因素（The hassle factor）
产品应消除所有故障和不便，减少使用过程中的挫折感。
3.学习差异（The learning delta）
产品应减少学习曲线，让用户更快地掌握使用方法。
访谈的四个部分：
1.概览（Overview）：
在访谈开始时，用户被要求提供一个关于他们工作环境和日常活动的概览。这有助于研究者了解用户的背景和上下文。
2.过渡（Transition）：
从概览到具体任务的过渡，研究者引导用户开始执行与项目相关的具体任务。
3.主要访谈（Main interview）：
这是访谈的核心部分，用户在研究者的观察下执行任务。研究者可能会提出问题，让用户解释他们的行为和决策过程。
4.总结（Wrap-up）：
访谈结束时，研究者可能会询问用户关于他们对产品或服务的总体看法，以及他们认为可以改进的地方。
访谈后的解释环节：
1.创建或整合情境设计模型（Contextual design models）：
访谈结束后，研究者会分析收集到的数据，并创建或整合情境设计模型。这些模型包括工作流程图、用户模型、文化模型等，它们帮助团队理解用户的工作方式和需求。
2.选择最相关的模型：
团队会从研究者建议的10个模型中选择最相关的几个进行深入分析和讨论。这些模型为设计决策提供了基础，并帮助团队理解用户的需求和期望。
3.3.3 创新头脑风暴（Brainstorming for innovation）
创新头脑风暴是一种用户研究方法，下面给出一些策略和建议。
1.邀请来自不同学科背景的参与者，这样可以带来丰富多样的经验。不同专业的人有不同的思维方式和知识储备，能够从多个角度看待问题，从而激发更多创新的想法。
2.不要禁止那些看似愚蠢或不切实际的想法。在头脑风暴过程中，任何想法都值得被提出和讨论。即使有些想法看起来很荒谬，它们也可能会引发其他更实际的创意，或者在后续的讨论中被改进和完善。
3.使用一些催化剂来激发更多的灵感。这里的“催化剂”可以是任何东西，比如展示一些相关的案例、图片、视频，或者提出一些开放性的问题，来帮助参与者打破思维定式，激发新的想法。
4.做好记录，捕捉每一个想法，不要进行筛选或审查。在头脑风暴过程中，所有想法都应该被记录下来，无论它们看起来多么离奇或不成熟。这样可以确保不会错过任何可能有价值的创意。
5.明确目标，聚焦主题。虽然头脑风暴需要开放的思维，但也需要有一个明确的主题或目标，以避免讨论过于发散。通过聚焦，可以更好地集中精力，提高头脑风暴的效率和效果。
6.使用热身活动，让会议变得有趣。在正式开始头脑风暴之前，可以进行一些热身活动，比如简单的游戏、轻松的讨论等，帮助参与者放松身心，激发创造力。同时，保持会议的轻松氛围，让参与者感到愉悦，这样他们更愿意积极参与并提出想法。
3.4 将需求变为现实
通过用户故事（user stories）来增强基本需求的表达。
用户故事包含人物角色（Personas）和场景（Scenarios）和目标（Goals）。
其中人物角色（Personas）是对典型用户的详细描述，而不是基于具体个人。这些角色帮助团队理解目标用户群体的特征、需求和行为模式。人物角色通常包括用户的背景信息、目标、动机、挑战和习惯等，使他们成为设计过程中的参考点。
场景（Scenarios）是描述用户如何与产品或服务交互的非正式叙述性故事。这些故事简单、自然、个人化，并且不可泛化。场景通常包括具体的情境、用户的目标、他们采取的行动以及系统的响应等。场景帮助团队理解用户在真实世界中如何使用产品，以及他们可能遇到的挑战和机会。
目标（Goals）是人物角色采取行动的动机。场景在目标达成时结束。目标帮助设计团队理解人物角色的需求和期望，以及他们使用产品或服务的目的。
3.4.1 人物角色（Personas）
1.捕捉一组用户特征（用户画像）：
人物角色是对用户特征的集合，它们代表了目标用户群体的典型特征。
2.基于用户研究的综合：
人物角色是根据用户研究（如访谈、观察、调查等）从真实用户中综合得出的。
3.典型而非理想化：
人物角色应该是典型的用户代表，而不是理想化或虚构的完美用户。
4.通过姓名、特征、目标和个人背景使其栩栩如生：
人物角色通常包括姓名、个人特征、目标和背景故事，这些细节使其更加真实和具体。
同时人物角色应该与产品的目标用户群体相关，以确保设计决策与用户的实际需求相符。
5.人物角色的两个目标：
帮助设计师做出设计决策：人物角色为设计师提供了一个清晰的用户视角，帮助他们在设计过程中做出更符合用户需求的决策。
提醒团队产品的目标用户是谁：人物角色作为团队的参考点，确保团队始终关注最终用户的需求和体验。
6.开发一组小型人物角色，其中一个主要：
通常建议创建一组有限的人物角色，以便团队能够集中精力理解和满足这些关键用户群体的需求。其中，一个人物角色可能被定义为主要角色，代表最核心的用户群体。
下图展示了几个例子。
3.4.2 场景（Scenario）
人物角色定义了故事的主人公是谁。这个主要角色具有态度、动机、目标和痛点等特征。人物角色是设计过程中创建的虚构用户，代表了目标用户群体的典型特征。通过定义人物角色，设计团队可以更好地理解用户的需求、期望和行为模式。
场景定义了人物角色的故事何时、何地以及如何发生。场景是描述人物角色如何作为一系列事件的行为的叙述。场景提供了人物角色在特定情境下的行为和交互的详细描述。通过场景，设计团队可以更具体地了解用户如何与产品或服务互动，以及他们可能遇到的挑战和机会。
目标定义了人物角色想要或需要实现什么。目标是人物角色采取行动的动机。当目标达成时，场景结束。
目标帮助设计团队理解人物角色的需求和期望，以及他们使用产品或服务的目的。
场景有多种描述方式，包括：
1.文本描述（Textual descriptions）
2.动画（Animations）
3.音频或视频（Audio or video）
4.示例动画场景（Example animation scenarios）
下图便是一个文本描述版本的场景。
3.5 用例（Use cases）
1.关注功能性需求并捕获交互：
用例专注于描述系统必须执行的功能需求，即系统应该做什么。
用例还详细捕获用户与系统之间的交互过程，即用户如何与系统互动以实现这些功能。
2.可用于设计或捕获需求：
用例可以用于设计阶段，指导系统的设计和开发。
用例也用于需求捕获阶段，帮助团队理解和记录用户的需求。
3.用例是交互的逐步描述：
用例通常以逐步的方式详细描述用户与系统之间的交互过程。
与用户故事相比，用户故事更侧重于描述用户期望的结果和目标。
4.两种风格：
基本用例（Essential use cases）：这种风格的用例关注任务的划分，而不包含具体的实现细节。它们提供了用例的高级视图，强调“做什么”而不是“怎么做”。
包含正常和替代流程的用例（Use case with normal and alternative courses）：这种风格的用例提供了更多的细节，包括正常流程和在特定条件下可能采取的替代流程。它们详细描述了用户如何与系统交互以完成特定目标，以及在遇到问题时可能采取的替代行动。
下图展示了一个基础用例的例子。
包含正常和替代流程的有关旅行组织者的用例示例如下。
正常流程如下：
1.产品请求目的地国家名称：
产品（即旅行组织者应用）要求用户提供他们想要访问的国家的名称。
2.用户提供国家名称：
用户输入他们计划访问的国家的名称。
3.产品检查国家是否有效：
产品验证用户提供的国家名称是否有效，确保它是一个真实存在的国家。
4.产品询问用户的国籍：
产品请求用户提供他们的国籍信息。
5.用户提供国籍：
用户输入他们的国籍。
6.产品检查该国家的签证要求：
产品根据用户提供的国籍信息，检查目标国家的签证要求。
7.产品提供签证要求：
产品向用户展示他们所查询国家的签证要求。
8.产品询问用户是否希望在社交媒体上分享签证要求：
产品询问用户是否愿意在社交媒体上分享这些签证信息。
9.用户提供适当的社交媒体信息：
如果用户选择分享，他们需要提供必要的社交媒体账户信息。
替代流程如下：
4.如果国家名称无效（If the country name is invalid）：
4.1: 产品提供错误信息（The product provides an error message）：系统检测到用户输入的国家名称无效或不存在，并向用户显示一条错误消息。
4.2: 产品返回到步骤1（The product returns to step 1）：用户被提示重新输入国家名称，流程返回到初始步骤。
6.如果国籍无效（If the nationality is invalid）：
6.1: 产品提供错误信息（The product provides an error message）：系统检测到用户输入的国籍无效或不存在，并向用户显示一条错误消息。
6.2: 产品返回到步骤4（The product returns to step 4）：用户被提示重新输入国籍，流程返回到询问国籍的步骤。
7.如果没有找到关于签证要求的信息（If no information about visa requirements is found）：
7.1: 产品提供合适的信息（The product provides a suitable message）：系统未能找到签证要求的信息，并向用户显示一条适当的消息，可能是建议用户检查其他来源或联系相关部门。
7.2: 产品返回到步骤1（The product returns to step 1）：用户被提示重新开始流程，流程返回到初始步骤。