《UX设计之道》—4.项目

本篇内容

• 项目目标
• 项目方法

---

目标与方法 了解用于导航的指北星

好项目的关键要素之一是让团队开始时就有一个清晰的项目目标和一个易于理解的方法。

你在一个项目启动会议中，第一次和一个完整团队在一起。项目经理交给你一些材料让你对项目有个大概的整体了解。到会议结束时，理想状况下，你应该有了 如下信息。

• 为何该项目对公司很重要？
• 利益相关方如何判断项目是否成功？
• 项目将遵循哪种方法论？
• 有哪些重要日期或里程碑式的关键点，如得到业务利益相关方的确认？

项目目标是关于项目可度量目标的陈述。

4.1 具体化项目目标

目标是你在项目整个过程中都将使用的重要聚焦镜。它们应该源于客户公司的整体商业策略，因此项目目标应当符合公司的战略举措。

一个清晰的目标会在整个项目中产生共鸣。它可以在以下几点帮助你。

• 在从业务利益相关方搜集想法时提出合适问题。
• 和用户一起对研究进行规划，并聚焦对结果的分析。
• 细化从利益相关方和用户那里搜集到的想法，并将其转化成整理过的项目需求列表。
• 根据对公司的价值来排列项目需求的优先级。
• 创建有效的交互设计。
• 一旦开发开始，管理需求变更请求。
• 在部署活动（如在站点或应用发布前和发布中，对用户进行培训和交流）中集中精力。
• 当项目启动时，确定是否符合客户公司需求。

当你开始一个新项目时，你可能有来自项目资助方的项目目的（直接对项目成功负责的业务利益相关方），也有来自业务利益相关方和客户的项目相关要求，但它们相对模糊些。你需要将这些清晰化为具体的语句，以当作衡量项目成功的标准。

坚实的目标有如下特征。

• 易于理解。避免内部术语。
• 清晰。避免含混语句在你排列需求的优先级时使用直白的语言。
• 可度量。 进行具体的说明，让其成为可评价成功的度量指标。

你将听到很多可以被认为是目标的陈述。分析下面列出的一些模糊示例有助于使目标具体化并保证团队成员之间的沟通更有效。

• 业务口号 “我们的目标是成为X行业的市场领导者” 。

  这是整个公司的目标，但这对特定项目来说太宽泛了。公司需要同时实施多种举措来让其实现，任何单个站点或应用会有助于这个目标但不可能承担全部负担——除非整个公司就是这一个站点或应用，并且完成得非常非常成功。

• 业务口号“我们的目标是让我们的客户群欢呼”。

  这个好一些，因为站点或应用可以带来这种影响，但还是有些模糊。为何欢呼重要？这样的欢呼如何转化以满足商业需求？你如何判断你成功了？

• 业务口号“我们的目标是增加网站流量”。

  现在，我们正找到目标。这个很容易衡量，但它还是有点集中在中间步骤。设想你已经产生了更多流量，但如果人们在访问时并没用执行你所希望的操作，则没有什么用。

模糊目标让你了解客户的期望和远期目的，你可以从其中提出更多具体的项目目标，如下所示。

• 增加在线销售额10%。
• 通过在线广告增加收入20%。
• 客户数据库中的当前和潜在客户数增加到20000以上。
• 给我们的主要用户提供高质量高参考性（highly referenced）的内容（注意，这要求花些工夫确定如何度量“高质量”和“高参考性” ，而这样的构造元素是存在的）。

上面这些都可被度量并受你项目的影响。它们也可很好映射到你提供的设计和功能上。

如果有多个目标，一定要和你的商业资助方和项目团队一起确定一个优先顺序列表。设计时，有时会发现目标之间存在冲突，此时团队需要知道什么东西优先。最终的目标优先顺序列表应该来自项目资助方，但你可以是讨论的关键参与者。下面我们谈谈如何进行。

4.1.1 用户体验设计师如何发挥作用？

如果你在项目开始时发现项目目标不清晰，你可以利用你的技能来改进。通过和关键利益相关方举办工作坊，来帮助项目团队理解业务相关的项目背景。这个环节通常持续2-4个小时，目标是说出公司的优势（strengths）、劣势（weaknesses）、机会（opportunities）和威胁（threats）。这被称为SWOT分析，一种常见的用于探讨公司在市场中定位的商业分析方法。你可将其用于公司的竞争分析。

了解优势和劣势

SWOT中的SW是公司中与项目有关的优势和劣势。优势和劣势可包括内部流程和外部看法——并且通常会互相影响。例如，拥有大型研发部门的公司可以访问大量发表的原始研究资源（优势），但是可能没有人帮助普通用户来提高内容可访问性，这样会导致感觉公司 “过于学术化” （劣势）。

识别机会和威胁

OT是SWOT中未来的那一半。考虑那些用来区分公司和竞争者的东西，未来采用哪些举措以开辟一个新的利基市场或强化当前市场？哪些情况会威胁这些计划？

比较竞争对手

什么是公司的主要竞争力？正在开发站点的竞争对手是谁？他们可能各不相同，特别当你面对的是大公司或全新站点时。
是否有站点虽不是直接竞争对手，但代表一种需要参考的有趣模型呢？你可以通过观察其他电子商务网站，看他们是否或如何销售你所销售的东西。

合到一起

SWOT和竞争对手是适合同时探讨的好的主题，因为他们之间相互作用。不了解谁是你的竞争对手，就很难讨论未来威胁，并且一旦你开始探讨未来机会，新的竞争对手通常会自然浮现出来。
一旦你得出关于公司竞争对手和SWOT的整体图景，你的项目目标应该易于定义，以让项目全面符合公司战略，并且它们之间的优先级也应当逐渐变得清晰。具体化项目目标有助于你理解项目将完成什么。

4.2 理解项目方法

• 规划整体策略、 方法和团队架构。
• 定义项目需求。
• 设计交互和视觉概念，并逐步形成详细定义。
• 开发、 测试和完善解决方案。
• 通过通知、 培训和发布会来部署解决方案。
• 扩展项目，提出改进建议。

这些步骤的命名、覆盖程度和文档形式可能存在差别。但各个步骤中的常见活动对多数项目和这里展现的3个模型都适用。

4.2.1 瀑布法

瀑布法将项目中的步骤处理成分开的多个阶段，下一个阶段的开始要在上一个阶段确认后。例如，在需求被利益相关方确认前，设计过程不会开始，利益相关方在定义阶段结束时要在一个或多个需求文档上签字。

纯粹瀑布法的问题是，假定每个阶段都可在无需对上一阶段进行大量修改的情况下完成。因此，如果你在设计阶段发现新需求，这很常见，那么你必须对已经在设计阶段确认过的文档进行修改，这可能会脱离计划和时间表。

4.2.2 敏捷方法

因为变化是持续的，项目团队一直在寻求比瀑布法更灵活的方法。许多方法论更为灵活，一些步骤可以同时进行，例如，网站的版本可以利用敏捷或快速开发方法快速、迭代式的发布。敏捷方法通常更专注于快速协作并减少对详细文档和正式签署的关注。

一个真正的敏捷方法（如，遵循敏捷联盟成员建议的最佳实践）提倡小团队，其成员物理距离都很近，并较少关注团队成员的正式角色定义。这样的工作方式带来了高度的协作，减少了设计、开发和测试阶段之间对大量文档的需求。团队成员可以在一个快速白板会议上提出问题，并和其他团队成员起得出答案，无需详细文档和确认就可以实施。当多次迭代中的一次被发布时， 利益相关方对一个全功能系统进行审查，结果作为下一次规划迭代的输入（迭代是特定网站或应用的草案版本，也可称为冲刺跑（sprints) ）。

如何快速从瀑布法转向敏捷法——精益UX（Lean UX）

精益UX

精益UX（Lean UX）是一种很适合开发一款具有很大不确定性的产品（初创企业产品多数如此）的快速项目方法。它通过去掉每次迭代时花费在不起真正作用的特征上的时间来减少浪费。例如，如果团队还没有证明目标客户愿意购买他们提供的产品，花时间来设计整套的产品目录和分目录就是浪费。

精益UX包括的一些基本原则如下

• 专注验证学习。不能简单地将产品的迭代版本看作产品的可工作版本，迭代版一本可用于用户测试的演示和假设。目标是尽可能快地学习，通过与客户起验证设计决策，并帮助团队将重要的修改合并进来。
• 创建一度量一学习的不断循环。精益过程是尽可能快地优先创建产品的可测试迭代版本，以便对团队给出的用户将会如何和产品交五的假定进行测试。基于研究期间用户的定性反馈来判断成败，基于落实到位的措施来跟踪成功。度量应当来自实际用户行为，例如，网站注册数、产品购买数等。需要注意的是，采用的度量要真正能测试开展迭代的假定。例如，如果人们注册了你的站点，但随后没用采取任何重要行动，你就会马上知道注册后的体验需要更吸引人。
• 在每个迭代中开发最小可行产品（ Minimum Viable Product, MVP）的重要性。在精益过程中，在每次迭代时，专注于测试关于用户行为的假定， 而不是创建一个全功能产品。团队测试假定时无需创建产品的全功能数字版本。特别是在开始阶段，团队可以专注于开发一个最小可行产品，Eric Ries将其定义为“产品的此版本经历完整一轮的最小花费最少耗时的创建一度量 学习循环 ”。

敏捷方法如它设计的那样开始工作，这是一件很优美的事情。然而，在大多数公司以及大多数咨询工作中，团队很少遵循一种纯粹的敏捷方法。部分是因为公司通常拥有分布式团队和远程员工，这就很难维持一种能充分利用纯粹敏捷方法的高度协作。然而，虚拟协作工具和数字草图工具的流行使得分布式敏捷方法的可行性增加，这样团队也可保证清晰交流、随时可得以及有效决策。

4.2.3 改进版方法（ Modified Approaches)

许多项目尝试遵循一种综合瀑布法和敏捷法中要素的方法，带有足够的结构和文档来减少分布式团队和成员变动带来的风险，并以充分的协作和迭代这样灵活的方式应对变化。例如，一个项目可能遵循瀑布模型但阶段之间存在交叉重叠，因此存在团队之间的关键协作点。这潜在允许在每个阶段早期对界面进行修改。这可能也包括一个经过短暂迭代周期的早期发行版（如针对特定群体的Beta版）

图4.6中设计阶段的那个小迭代， 这是你作为用户体验设计师带给团队的最大价值。

4.2.4 方法会对我产生怎样的影响？

• 你应当何时提出何种问题。例如，如果你正在使用一种纯的瀑布方法，你需要投入额外的努力以确保定义阶段捕获的需求包含设计阶段所需的全部信息；
• 预期项目团队成员会如何协作以及协作的紧密程度。例如，敏捷方法要求非常紧密的协作。瀑布方法多数时候是独立工作，伴随每周一到几次的接触；
• 文档所需的详细级别以及正式的程度。在签字时提交的文档比较正式，几乎像法律合同。通常，在瀑布模型中需要更多的正式文挡，在进入下一阶段之前都需要签字。在敏捷方法中也有一些正式文档，例如，在主要决策点搜集信息，如准备整体实施的特定迭代；
• 重要的里程碑，如来自利益相关方的确认以及针对不同群体的发布。方法将决定在项目的不同地方，需要给受众提供些什么，包括签署时来自利益相关方的确认，以及Beta发布时来自潜在用户的反馈。

温习：

• 项目目标的具体化、特征；
• SWOT分析；
• 瀑布法、敏捷法、精益UX；
• 改进版方法

（完）