2.5 主要经验与建议
经历了项目的各个阶段，我们知道了哪些实践是可行的，哪些需要改进。这曾是一个不断学习的过程，如今我们依然还在学习。
本章中推荐的大部分UX实践对你和你的公司应该会有所帮助。但有些实践更适合在流程更复杂的大型公司和全球性组织中执行。你可以听取一些我们的建议，试着在你的公司中执行。你将会知道哪些实践经验是有用的，哪些需要根据自己的实际情况做调整。
2.5.1 关于扩大对技术影响力的建议
明确UI需求的优先级 从客户和用户的角度考虑UI需求的优先级。运用用户研究数据和最终用户UI验证结果证明优先级的正确性。
让UI需求变得简单易懂 决策者需要理解UI需求。通过截图表达视觉效果，使用简单易懂的术语。如果你的需求是从可用性测试结果中发现的，还可以播放一段用户界面令用户抓狂的视频，只需要截选亮点即可。
为UI架构团队提出需求 在为UI架构提出需求的过程中，用户体验团队应该处于领导地位，并需要强力表达自己对于需求优先级的意见。UI架构团队是技术团队的一部分，负责搭建应用程序开发团队制作用户界面时使用的技术平台。例如，UI模式就是由UI架构团队开发的。
汇报UI需求执行的进展 经常向管理团队汇报UI需求的执行状况。当改进成果可发布时，向管理层展示成果。
与UI架构团队建立良好的个人关系 在用户体验团队和UI架构团队之间建立稳固的协作模式。如果你与UI架构团队建立了良好的个人关系，他们会更愿意协助你实现那些能够改善用户体验的UI需求。
为每一个真正用户的需求尽力争取实现 你必须争取实现每一个能够提升用户体验的需求。仅仅是把需求放到列表中，指望它能够按照你希望的方式实现，这是行不通的。你必须争取实现每一个需求，而且如果你的目标设计无法实现，你应该提出另一种可行方案。
建立合理的模式库 模式库里的样式数量应该足以让应用程序层面的设计师和开发人员可以选择以满足使用用户界面的用户的任务执行需求。
将UI风格指南融入开发工具 将UI风格指南融入开发工具中有助于显著提高产品质量，提高开发流程的效率，所以有必要让UI模式成为UI架构的一部分。基于模式的工具可以保证设计与开发的一致性和全面性。UI风格指南里的规则应该分为“硬规则”和“软规则”。“硬规则”可以用硬代码写入开发工具。“软规则”有时候只是建议或最佳实践。这些规则在90%的情况下都是可用的，只是有时候可能有些例外。把这些“软规则”融入到开发工具中，如果开发人员在开发过程中违反了某个规则，则系统会给他们发提醒信息。如果这一违规是有意的，开发人员只需要标记上“例外”的标记就可以继续工作了。如果此处并不是个例外，他可以马上解决该问题。UX规则拉近了UI风格指南和开发人员的距离。
规划好UI架构的迭代 落实用户需求以优化UI模式是一项富有挑战性的工作。你必须为开发过程中的迭代预留出足够的时间。通过最终用户测试已实现的模式，并不断改善模式。
邀请开发人员参与可用性测试 开发人员需要接触真正的用户，观察用户在使用软件时的感受。
引入自动化UI测试 自动化UI测试可以空出人力去完成更有成效的工作。自动化测试应该用于回归测试（regression test）。这有助于提高产品质量。3
2.5.2 关于扩大对组织和人员影响力的建议
获得最高管理层的认同 你必须让最高管理层认识到以用户为中心设计的价值，才能够获得足够的资源和预算。如果你无法做到这一点，你或许该考虑另谋高就了。
UCD培训与指导 通过提供培训与指导（例如，现场观察和“如何写出好用例”的培训）使解决方案经理、UX设计师和开发人员顺利地执行UCD流程。组织中的很多人或许还不是很熟悉UCD方法论，而且即使他们以前可能接触过UCD，在项目过程中也可能会有新人不断加入到组织中，所以这种知识的更新必须持续进行。培训必须以实用为目的，佐以大量的例子和实践。它的目标是在动手的过程中学习。
理解解决方案经理和开发人员的需求 理解解决方案经理和开发人员的需求，帮助他们取得成功。让他们参与客户和最终用户操作的现场观察，感受以用户为中心设计的价值。我们曾邀请了一些开发人员和解决方案经理参观对最终用户的现场观察和可用性测试。亲身经历学到的东西总是更透彻，光“说教”是行不通的。解决方案经理一般都有市场研究的背景，但对用户研究仍不甚了解。用户研究有助于解决方案经理获取准确的数据，而且让他们与开发人员沟通起来更容易。
目标一致 解决方案经理、UX设计师和开发人员要实现团队合作、目标一致。让共同目标成为UX设计师、开发人员和解决方案经理个人目标的一部分。
保持曝光率，推销以用户为中心的设计 定期汇报最终用户测试结果。展示节选的视频亮点将最终用户使用产品的感受传达给团队和管理层，并向那些无法亲自参与可用性测试的人提供远程观察支持。
“一个团队”路线 构建跨领域团队，保证掌握所需技能的成员在需要的时候总是在团队中。为了保证团队效率和产出的最大化，这个团队应该包括解决方案经理，UX设计师，开发人员和知识管理部门经理。
让团队“共处一室” 如果条件允许最好让团队在一处办公。不同的团队分布在各地办公并没有什么问题，但是每个团队里掌握所需技能的成员都应该在一个办公地点办公，如果在同一间办公室就更理想了。我们的目标是共同的办公地点，但这不是一夜之间就能改变的。随着每个版本的发布，我们的办公地点越来越集中，而且我们一个团队最多只允许有两个办公地点。虽然这不是最理想的状态，但我们已经朝着正确的方向迈出了一步。
循序渐进 让大型组织走UCD路线的思想转变需要时间，可能需要数年才可以自然过渡，而且过程中总是会有可以改进的地方。
2.5.3 关于影响开发流程的建议
只要一个产品开发流程 确定统一的总体产品开发流程，将以用户为中心的设计顺利地融入流程。确保没有单独的UI流程！
清晰地记录流程 提供清晰的流程描述，明确需要交付的内容。让每一个人都清楚自己在其中的职责是什么。想让流程变得简单易懂，首先要对每个阶段进行纲领性的描述，但如果需要也可以拓展到细节。
明确角色分工 明确不同团队的角色和职责，避免引起“谁来领导用户体验”的争执。
将用例定为交付的必要项 在了解用户的主要目标和任务之前，你不应该开始UI设计。为了获得高品质的用例，你需要与客户和最终用户沟通，回顾现有的应用程序和之前的可用性测试结果，与负责现有产品的客服部门代表面谈，询问用户反映的UI问题有哪些。
排列用例优先级 专注于提高最重要、使用最频繁的用例质量。用例的优先级要有所不同。
提供好用的模板和最佳实践 为需要交付的内容提供模板，并介绍模板使用的最佳实践，让人们更容易接受。好的例子会让学习更容易。
确定产品和版本的待处理需求列表 明确产品和版本的待处理需求，清晰地排列出大需求类别的优先级。排列了优先级的列表也有助于确定用户体验活动优先级。产品待处理需求涵盖了未来2～3年里的高层面需求。而版本待处理项目只涵盖了下一个版本的需求。
尽早统一需求 你必须尽早与团队统一需求。开发人员应该在项目初期就参加进来。这是为了避免解决方案管理部门确定了需求后直接抛给开发部门的情况出现，开发人员从一开始就需要参与概念设计。
为概念设计阶段安排充足的时间 你必须为用户研究和概念项目安排充足的时间。在敏捷开发流程中更是如此。我们决定以6个月为一个发布周期，并为更复杂的概念项目安排3～5个月时间的前导时间。概念项目要与上一版本的开发并行进行。
为迭代做计划 以用户为中心的设计是一个迭代开发方法。你必须安排好迭代开发时间。
运行试点项目 如果你想让某些项目上的改进成为流程中的强制步骤，最好先开展试点项目。多花点时间指导试点项目，以确保良好的效果。成功的项目有助于让管理层和参与项目的人认可项目的价值。然后再让他们作为传播者说服组织中的其他人也采用这一方法。
提供基础设施，便于用户开展活动 给团队提供一个能让他们更快、更方便地接触到最终用户的基础设施。
让开发人员参与用户研究活动 通过参与用户研究，开发人员能够更好地了解用户需求，更看重现场收集的真实数据。开发人员并不用参与每个现场观察，但至少要出席汇总现场观察结果的总结工作坊。
让UX规则成为强制性门槛 定期监测并汇报从开发工具中监测到的UX违规情况。在将产品递交给客户之前必须解决优先级较高的UX违规问题。
评估UX目标完成情况 通过关键绩效指标（KPI）定义UX目标，通过基准可用性测试评估KPI，然后向管理团队汇报基准测试结果。
持续改进流程 没有完美的流程。你必须不断改进流程，不断评估流程与工作。