项目例程：为什么它们值得更多关注
我们的追求：发现一个成熟的、整体的实践和项目框架是什么样的；我们在设计业务的未来时需要考虑什么，以及一个成功的项目团队的本质。
在上一篇文章中，我们探讨了构成成熟UX 实践的元素以及它们如何应用于项目团队。我们还研究了一些可以鼓励更好的项目行为、指导团队和为人们设计积极体验的方法。在概述鼓励设计人性化用户体验实践的元素时，我们考虑了当前和未来的状态、学习学院、价值观和信仰、项目团队使用的语言、工具包；软技能，或值得持续练习的人的素质；设计和验证解决方案的空间，从故事中学习；以及易于理解的共享工件 供项目团队成员用于讲述他们共同的故事，独立于他们在项目中的角色。
所有这一切都说明我们寻求发现一个成熟的、整体的实践和项目框架是什么样的；我们在设计业务的未来时需要考虑什么，以及一个成功的项目团队的本质。
在我们继续研究业务中的项目团队的过程中，我们一直在思考以下问题：
- 项目团队是否需要明确的角色才能成功？
- 个人角色如何提高团队绩效？
- 具体的研究方法在多大程度上启发了对真实人物的认识并将这种认识嵌入到团队推理中？
- 我们如何确保团队的工件足够相关以连接不同团队成员的逻辑并克服分裂推理？
- 我们如何确保我们的方法、工具包和语言更好地代表了关于真实人物的隐藏知识？
- 我们如何消除恐惧、识别偏见并克服限制团队绩效的错误假设？
我们一直在观察和反思项目团队的行为，并考虑人们是否有时间实际练习特定的例程。这远远超出了快速实施新例程的范围。采用错误的例行程序可能会严重损害团队士气，并最终对他们的工作质量产生负面影响。因此，在我们进入我们选择的方法或工具包之前，我们如何帮助项目团队识别有用的例程并以结构化的方式实践它们——让他们有更好的机会为有意义的项目做出贡献？
所以，让我们回到过去。
戏剧课程
我们如何帮助项目团队识别有用的例程并以结构化的方式实践它们——让他们有更好的机会为有意义的项目做出贡献？
1980 年代，当丹在澳大利亚上中学时，他的学校决定将戏剧作为课程中的一门科目。这对所有的学生来说都是新鲜的。在排练一起演出所需的技能时，学生们必须在课堂上不断练习不同的套路——既要提高表演能力，又要在观众面前获得自信。以个人和团体形式练习这些例程，涉及不同的表达形式，包括声音、动作、哑剧、热身和剧本朗读等等。
这些惯例使学生能够提高他们成为更好的表演者所需的各种技能，包括观察、领导、倾听、联系、框架、玩耍和讲故事。它还允许学生探索他们个性的不同部分，并在其他日常课堂或操场互动之外敞开心扉。
他们的戏剧老师在带头方面非常有效，向他们展示了跳入未知领域以获得信心是可以的——尽管有些人会感到恐惧。他还非常擅长在排练期间将例程连接在一起，这导致了在年底进行学生作品所必需的改进。
项目需要例程
在项目中，我们将例程定义为任务或活动的组合，这些任务或活动随着时间的推移培养更好的习惯和行为，从而为人们设计和开发更有意义的体验。
在项目中，我们将例程定义为任务或活动的组合，这些任务或活动随着时间的推移培养更好的习惯和行为，从而为人们设计和开发更有意义的体验。因此，对于项目：
- 今天存在的套路是什么？
- 哪些套路更值得关注和练习？
当今盛行的日常实践
我们已经确定了某些有用的项目例程，并观察到团队很少严格地实践它们——并且通常在项目规划或召集项目团队时没有考虑它们。大多数情况下，项目团队成员会陷入一个实施例程中，几乎没有时间或注意力去关注我们将讨论的其他例程。
我们将与您分享我们的项目例程草案清单，我们非常想知道您在项目中观察到的其他例程。我们也愿意重新考虑我们对“常规”一词的使用，因为我们试图确定正确的语言来传达这些想法。我们并不完全确定例行公事是描述我们正在谈论的内容的最佳词。重要的是要注意——本着整体和关联思维的精神——这些例程不需要单独进步；有些在并行流中效果最好。其中一些例程尚不存在于任何项目中。
类似于Dan 在澳大利亚的戏剧老师，这些例程的所有者和促进者是必要的，以确保我们将它们运用到我们的项目中，我们在迭代设计时练习它们，并且人们有必要的时间来提高与他们的技能相关的技能角色。
现在，让我们进入例程。
探索行动方案
在探索行动方案时，该团队试验并引入了社会、技术和业务系统的变化……此例程侧重于确定或调整实现、促进或提供新解决方案的创新方法。
在探索行动方案时，该团队试验并引入了当今世界上存在的社会、技术和业务系统的变化。此例程侧重于确定或调整实现、促进或提供新解决方案的创新方法。
- 实施——在这个例程中，一个团队低着头，试图把解决方案拿出来，没有太多时间做任何其他例程。计划的时间很少。
- 实验——一个团队在讨论目标、问题、改进和结果以及评估哪些选项可以聚合为未来的积极结果时，会使用多种选项并使用用户故事。（稍后会详细介绍。）
- 探索外部世界——一个团队离开舒适的项目室，出去观察客户的世界。这有助于他们将目光从单一的、独立的功能转向整体设计解决方案，并将功能映射到使用环境——无论是已知的还是未知的。
定义我们的意图
在定义他们的意图时，团队成员花时间与彼此及其利益相关者互动并分享现有知识。他们制定计划并就项目的重点达成一致，探索它将如何决定项目成果的质量。
- 计划——一个团队花时间提前计划，而不仅仅是花时间在实施上。
- 焦点——团队决定他们需要改进设计的哪些特定元素，从而在讨论和批评期间关注。团队故意消除其他价值较低的例程，以使项目团队集中精力。
在判断之前生成实验
在进行实验时，团队通过创建大量草图或粗略原型来设想客户面临的情况和挑战的变化。
在进行实验时，团队通过创建大量草图或粗略原型来设想客户面临的情况和挑战的变化。实验的最佳例程使团队能够在不审查任何人的想像力的情况下做到这一点。
- 草图——一个团队在白板上工作或使用纸和铅笔来帮助他们快速迭代想法，而无需将它们提交给代码。这有助于他们确定哪些设计解决方案值得进一步投入时间。
- 设想——这个例程几乎与实现相反。一个团队花时间考虑替代的未来，并在没有批评或操作、技术或其他现实限制的情况下探索它们。在这一点上，创新可能会发生——尽管它不是设想所独有的。
分享对某个情况的观察
在分享观察结果时，团队会聚在一起阅读有关人类行为的故事，并将其记录在团队的集体记忆中。此例程使团队能够确定值得整个团队进一步分析的令人惊讶或深刻难忘的情况。
- 讲故事——一个团队与其他团队成员分享他们在用户研究期间收集的故事，解释故事，理解他们的观察，并确定哪些工件会给他们的观察和洞察带来生命。
- 分享假设——一个团队列出他们的假设——讨论他们的来源和支持他们的证据——然后挑战或接受假设或假设集。这有助于团队通过确定哪些功能值得团队花费更多时间、重点和注意力以及哪些功能需要更多研究或进一步设计迭代来确定某些功能的优先级。
解释每个人的观察
在解释观察结果时，团队必须弄清楚他们知道什么和不知道什么。
在解释观察结果时，团队必须弄清楚他们知道什么和不知道什么。
- 解构——一个团队一起查看可用数据，并通过应用不同的镜头来理解它，然后确定它的含义。
- 聚合——在解构和理解数据以确定它可能意味着什么之后，团队聚合分组——例如，特性和特性集、路线图、设计原则或下一个版本的目标。聚合有助于团队评估他们所学到的知识，并决定他们是否必须迭代项目团队的工件。
- 加入点——一个团队从他们的各种工件中加入观察和见解。例如，人物角色可能会影响设计屏幕或影响客户旅程中的交互并可能影响整体产品的问题是什么。这有助于项目团队成员超越自己职能的观点，探索故事中可以帮助产品或服务取得更大成功的其他部分。
确定先前的假设
在确定假设时，团队会从他们的工作中停下来反思他们收集的证据、他们采取的方法、项目产生的实验以及团队自己的推理，以识别他们的偏见并敞开心扉接受外部批评。
在确定假设时，团队会从他们的工作中停下来反思他们收集的证据、他们采取的方法、项目产生的实验以及团队自己的推理，以识别他们的偏见并敞开心扉接受外部批评。
- 走墙——一个团队在墙上展示其项目工件，并对其进行集体反思，以了解它们如何相互关联，并确定在接下来的几周内是否存在任何值得进一步关注的问题或机会。例如，他们可能会描述一个与角色相关的故事，浏览旅程地图的一层，或者列出他们的假设，这些假设值得通过用户研究进一步调查。
- 反思——团队有时间和空间稍微超越项目细节，反思团队学到了什么以及他们如何改进他们一起工作和实践的方式。
- 评估假设——团队再次有机会列出他们的假设或假设集，并讨论他们的来源以及支持或挑战他们的可用证据。这样做使团队能够确定要关注的功能并设置优先级。
- 批评——团队批评设计并捕获结构化反馈，以在未来的迭代中改进设计。团队可以利用从批评中学到的东西来发现需要进一步用户研究的未知数。
这些只是我们在项目中观察到的一些例程。您在项目工作中注意到了哪些例程？是否有一些我们错过了并值得更多关注？
UX 香港 2015
我们于2011 年创立了UX Hong Kong，将所有产品和服务设计学科——包括研究、营销、设计、技术和商业——结合在一起，并为那些对为人们设计卓越体验和帮助有兴趣和热情的人们提供一个聚会场所。企业为所有人创造更美好的世界。UX Hong Kong 现在已经进入第五个年头了，我们为2015 年制定了一个很棒的计划。