设计是过程，而非方法论（下）
开发概念模型
“ 概念模型 …[表达]预期用户任务域的概念：用户操纵的数据，将数据划分为大块的方式以及用户对数据执行的操纵的性质。它抽象地解释了[产品]的功能，以及人们使用该产品需要注意的概念。”-杰夫·约翰逊（Jeff Johnson）
概念建模是一项初步的设计活动，可帮助产品团队从用户的角度查看产品的概念，工作流，功能和语言……。
一旦了解了目标用户的当前任务和工作流程，就必须在进行构思和详细设计之前进行概念建模。概念建模是一项初步的设计活动，可帮助您的产品团队从用户的角度查看产品的概念，工作流，功能和语言，并设想，定义和设计更简单，更一致且更易于用户理解的产品。
在概念建模期间，请回答有关您正在设计的产品的以下问题：
· 产品的用户界面必须向用户揭示产品任务域中的哪些概念？这些概念如何告知您产品的工作流程？
· 有针对您产品的新概念吗？您是否需要为他们设计新的创新工作流程？
· 您的产品应使用哪种语言来传达这些概念？
· 您的产品必须满足组织的哪些业务目标？产品的工作流程如何支持这些目标？
· 您的产品必须提供什么功能？不同类型的功能之间的关系如何影响产品的工作流程？
· 产品的用户界面应向用户呈现哪些任务和任务序列？您将如何以任务场景的形式描述这些？您的产品应在哪里以什么顺序展示它们？它们如何相互关联？
· 哪些设计模式是您产品领域的特征？这个网域有标准的工作流程吗？
· 您的产品必须提供哪些设置？此功能应在产品的工作流程中的什么位置？这些设置的适当默认值是多少？
· 用户需要使用产品来创建，查看和编辑哪些数据？用户还需要对数据执行哪些其他操作？这些任务是否需要单独的工作流程？
· 产品还必须兼容其他数据源吗？您的产品应提供哪些形式的数据输出？产品数据的来源和输出如何影响其工作流程？
· 产品是否应提供功能以提供快捷方式来支持用户的关键任务？这是否有必要为同一功能提供不同的工作流程？
开发概念模型
在概念建模期间，您可以帮助您的团队对目标用户的任务心理模型形成共识。
概念建模通常是一个协作过程，涉及多学科产品团队中的各个人员。在概念建模期间，您可以帮助您的团队对目标用户的任务心理模型，产品功能的计划范围以及产品领域的主要工作流程和任务方案形成共识。然后，基于此理解，您可以开发以下内容：
· 一个高级概念模型-创建一个图表，清楚地说明产品用户界面的总体结构-显示其关键组件和内容区域-并代表您希望用户感知的主要工作流程。
· 任务方案或情节提要- 为产品的任务域编写所有基本任务的高级叙述性描述-或绘制直观地表示它们的情节提要。这些是目标用户必须能够使用您的产品执行的任务。
· 对象/动作分析-分析产品必须向用户呈现的任务域对象（包括数据元素和工具）以及用户可以对它们执行的操作。将这些对象组织成两个
· 类型层次结构—按类型组织对象可显示它们之间的相似性和关系，揭示它们的自然分组，确保产品用户界面中对象和操作的表示一致，并可简化产品的交互模型。
· 包含层次结构—根据包含其他对象的对象组织对象，可以为您的产品提供清晰的结构，并为其产品提供自然的分组。
· 产品词典 -为产品提供给用户的对象和操作开发术语词典。这样做有助于确保团队使用术语的一致性。
概念建模的好处
设计人员有义务为设备的工作方式提供适当的概念模型。它不必完全准确，但必须足够准确，以帮助学习操作和处理新情况。” — Don Norman
开发产品领域的高级概念模型并以语言或视觉方式表达其任务是概念建模过程的重要组成部分。
开发产品领域的高级概念模型并以语言或视觉方式表达其任务是概念建模过程的重要组成部分。通过概念模型和任务方案，您可以一起创建高效的工作流和面向任务的功能分组。高效的工作流程可确保用户可以按正常执行任务的顺序成功完成任务，并实现其实际目标。
为产品定义概念模型后，团队正在开发的产品的性质和范围就会变得清晰，开发人员可以开始开发其基础技术，并且您可以在此基础上构建产品的工作流程。
设想产品工作流程的大部分工作发生在概念建模和构思期间，这是产品设计过程的下一个阶段。
通过构思解决关键设计问题
优秀的设计师会不懈地产生许多想法，并开明地考虑替代解决方案。优秀的设计师绝不会害怕接受疯狂，竞争或不舒服的想法。” —卡尔·乌尔里希（Karl Ulrich）
在构思过程中……您的产品团队中的每个人都有机会交流需求和约束并贡献设计想法……。
既然您的产品团队中的每个人都了解目标用户的当前任务流和概念模型，那么您就可以准备设想产品工作流和交互模型，使用户能够更有效地执行使他们实现目标的任务。
在构思过程中（与概念建模一样，这通常是一个高度协作的过程），产品团队中的每个人都有机会交流需求和约束并提出设计想法。构想涉及迅速生成许多不同的可能的工作流程和用户界面设计解决方案，并通过在画架或白板上或笔记本中绘制设计草图来捕获它们。
为了在构思过程中促进构思的产生，请与您的产品团队或UX设计团队一起探讨以下问题：
· 我们应该如何揭示产品任务域特有的概念？这些概念是否有适当的隐喻？
· 我们是否需要针对产品任务域特有的新功能设计创新的交互模型？还是可以借鉴其他任务领域的交互模型？
· 另一类产品（例如手机，消费电子设备，游戏或汽车）的哪些设计元素可能适用于此产品领域？
· 创新的交互模型将提供什么好处？这些好处是否足以保证与相同域中的其他产品或不同域中的其他产品的相似功能产生不一致？
· 我们产品的用户界面应如何最好地体现其提供的功能？我们可以采用现有的设计模式吗？
· 对于哪些功能，我们应该采用标准设计模式而不是创新的交互模型？
· 哪些用户界面元素或交互模型最能帮助用户更改我们产品提供的某些设置？
· 我们如何帮助用户学习我们的产品？
· 我们如何才能使产品的用户界面在内部和外部与其他产品更加一致？
一旦您的产品团队提出了许多好主意，就可以向他们提出以下问题，以帮助他们改善主意：
· 我们如何完善我们的想法？
· 我们可以结合我们的任何想法吗？
· 某些想法有什么共同点？
· 某些创意有什么区别？
· 我们如何简化一个特定的想法？
· 一个特定的想法基于什么假设？
· 我们如何使一个想法更好地满足特定要求？
评估每个提出的设计解决方案的利弊，反复完善团队的最佳创意，然后决定要详细设计和开发的解决方案。
注意：我通常不喜欢集思广益等形式化构想过程。虽然他们都具有非常大的团队或与许多利益相关项目时，有时是有益的，他们 不是通常所必需的具有建设性的人际关系动力学和其一起工作的方式是真正的协作紧密的产品团队。也就是说，下次我发现自己需要这种过程时，我想尝试Mike Myles的协作并行设计方法，他UXmatters文章“ 使用协作并行设计过程 ”中对此进行了描述。似乎是一种非常平衡的方法，既可以激发团队成员的创造力，又可以确保协作，同时避免受到过度控制或约束。实际上，在某些方面，它反映了我与产品团队合作时遵循的非正式构思过程。
当与一个由高度协作的产品小组组成的小组进行构想时，他们既不受批评的束缚，也不受批评的威胁，实际上，我更喜欢接收并提供有关构想的即时反馈。
在这种情况下，我发现听取每个想法的利弊在很大程度上激发了创造性思维，从而导致我们利用早期的设计思想来设计甚至更多可能的设计解决方案，从而提出更好的解决方案来解决参与者的问题我们已经在前面讨论的解决方案中找到了答案，最后最终提出了更高级的设计思想。
从构思开始，您将继续进行详细的设计活动，其中包括针对产品主要工作流程的基本设计解决方案，以及针对其主要用户界面的一些常见交互模型和布局，而这些解决方案已经为您的团队所接受。在进行详细设计时，您将创建一个连贯的产品设计解决方案，其中融合了团队成员的所有最佳创意。
进行详细设计
“几乎在所有情况下，都应该迭代设计用户界面，因为从一开始就设计没有可用性问题的用户界面实际上是不可能的。……迭代设计专门基于从先前迭代中学到的经验进行完善。” — Jakob Nielsen
良好的交互设计是一个反复的过程，从构思到草图绘制一直到整个设计阶段逐步详述。
良好的交互设计是一个反复的过程，从构思到草图绘制一直到整个设计阶段逐步详述。一旦您的产品团队在构想过程中就一些基本设计方法达成共识后，您将在详细设计过程中对其进行发展和阐述，通过优化工作流程和交互模型并创建可有效传达它们的设计工件来不断完善交互设计解决方案。
在详细设计期间，您将确定产品的所有工作流程，并解决产品提出的所有交互设计挑战，从而设计出一个整体设计解决方案，以满足您的产品团队在需求定义期间定义的所有需求。在整个详细设计中，您将与产品开发团队紧密合作，以确保您的设计充分利用技术机会并遵守所有技术限制。
创建设计工件时，您可能会选择创建流程图，以说明产品用户界面的总体结构及其主要工作流程。您可能会创建线框，以定义产品的关键组件和内容区域并显示其主要工作流程。您可以注释流程图或线框以开始捕获设计细节。
您可以在整个交互设计规范中为整个产品或特定功能提供全面详细的规范，以描述您产品的用户界面，工作流，交互模型和行为，包括显示其屏幕的低保真或高保真模型。（由于上一专栏文章“ 指定行为：使用示例菜单行为规范 ”已经详细讨论了如何进行交互设计交流，因此在这里我不会深入探讨该主题。）
另外，您可以开发具有低保真度或高保真度交互性的交互式原型，并展示产品的行为方式。但是，在开发原型时，您仍然需要在某种程度上描述您的用户界面，编写规格说明以填充尚未在原型中实现的细节，以确保您的开发团队不会对您的意图做出任何错误的假设。
使用方案是交流您的交互设计解决方案的另一种方法，使用场景描述了用户可以遵循的分步过程，以使用您的产品完成其任务，并合并代表这些交互的屏幕图像。
一旦完成了设计工件的初稿，就可以在设计评审会议上向UX团队介绍您的设计，以便团队的其他成员可以提供反馈。理想情况下，您的UX团队应该通过进行专家审查和/或可用性测试来彻底评估您的设计解决方案。您将迭代地优化设计，将您从同行那里收到的反馈信息以及通过可用性测试的信息整合到您的设计工件中。
产品团队的关键成员（代表每个学科，包括产品管理，市场营销，产品开发，质量保证和文档）应彻底检查您的设计工件，并提供有关设计解决方案的详细设计反馈（也许在Wiki上）。一些关键的团队成员可能会选择让其他学科的成员审查您的设计工件并提供反馈，然后为您汇编他们团队的反馈。一定要鼓励他们将设计工件中缺少的任何信息引起您的注意。
评估他们的反馈后，请将您同意的所有更改都纳入设计工件中。然后邀请产品团队的关键成员参加审核会议，以便您可以讨论有关设计解决方案或设计工件的所有未解决问题。您的设计工件必须充分满足产品开发人员的需求，产品开发人员将按照它们来构建产品，质量工程师将使用它们来创建他们的测试计划，用户帮助专业人员将使用它们来创建用户帮助或文档计划。并编写帮助或用户指南。
响应所有这些反馈，您将进一步完善您的设计解决方案。一旦您和您的产品团队对您已经设计出最佳的设计解决方案（在产品开发项目的约束范围内）感到满意，所有利益相关者都会批准您的设计工件以进行实施。
开发支援
在开发支持阶段，交互设计师继续参与项目可确保产品团队在整个产品开发过程中始终专注于用户的需求。
在开发支持阶段，交互设计师继续参与项目可确保产品团队在整个产品开发过程中始终专注于用户的需求。
提供开发支持
设计优化的迭代过程应在整个产品开发过程中继续进行-因为开发人员发现他们需要其他设计详细信息或其他状态或错误消息。您应该可以回答开发人员对指定的设计解决方案可能遇到的任何问题，解决开发过程中出现的任何设计问题，并根据需要澄清或修改您的设计工件。这可以确保根据设计规范和其他设计工件，在设计产品时就构建产品。另外，使您的设计工件与正在开发的产品保持同步，从而使质量保证工程师和用户协助专业人员可以在设计和工作中依靠您的设计工件。
如果您的产品团队发现为当前版本定义目标过于雄心勃勃，或者设计解决方案的特定元素被证明比最初预期的要难实施，那么开发项目的范围可能会改变。在这种情况下，您将需要修改设计解决方案和工件，以反映项目范围的缩小。
在开发支持期间，您还应该指导用户帮助专业人员和产品团队中的其他内容开发人员使用产品的词典。市场营销和用户协助应始终使用相同的术语描述您的产品。
在产品开发过程中，随着产品功能的不断增强，您的UX团队可能会进行其他可用性测试。在此阶段，如果测试显示出令人震惊的可用性问题或诸如仅需简单修复的术语问题之类的可用性问题，则您将需要对设计解决方案和工件进行另一轮修订。但是，您在产品开发生命周期的后期发现的大多数可用性问题只有在后续产品发布后才能得到解决。
开发支持阶段最终将使您的产品团队交付满足用户需求且易于学习和使用的高质量产品。
结论
在本专栏中，我描述了一种有效的，以用户为中心的产品设计过程，该过程包括以下步骤：
1. 了解您的用户
2. 为用户建模
3. 分析用户的任务
4. 制定和定义明确的产品要求
5. 开发概念模型
6. 通过构思解决关键设计问题
7. 做详细设计
8. 提供发展支持