本篇内容

理解现状
从利益相关方搜集想法

在创建方案前了解要解决的问题

在项目的早期阶段，你很可能有一组相当模糊的需求。这可能是来自利益相关方的想法、用户抱怨或用户要求。为了让这些成为你项目的有用并可跟踪的组成部分，你需要将这些想法凝聚成需求。

需求是定义站点或应用需要做什么的陈述。理想情况下，商业需求做如下几种事情。

提供对必须解决的需求的洞察。
表达并具体化由不同利益相关方提出的需求。
为设计提供方向，不需要太具体的完成步骤。
成为用于排列优先顺序和跟踪的独立工作单元。

清晰详细的需求是项目的关键组成部分。获得项目需求的提炼列表涉及如下步骤。

1.理解网站或其竞争对手的现状。
2.从利益相关方以及当前或潜在用户那里搜集需求和想法。
3.将想法提炼成需求。
4.根据项目目标排列需求的优先顺序。

提炼成需求

5.1 理解现状

在一头扎进你正在设计的网站和应用时，通过了解网站（如果你正在重新设计一个已有网站）的现状或透彻了解关键竞争对手（如果你正设计新的网站或应用），让自己脚踏实地非常重要。

你可以通过利益相关方访谈（后面有几页对此进行了详细介绍）了解到很多现状。你也可以亲自去了解，这可以成为利益相关方访谈和用户研究的坚实基础。一种获得背景信息并产生可成为需求的想法的很好方式是启发式分析（heuristic analysis）。

启发式（heuristic）这个词意味着经验准则或最佳实践。启发式分析表示利用一组可用性设计准则（经验式）来检查产品，通常由UX设计师来开展。用户友好型网站将符合你在分析中使用到的全部或大多数启发准则。

百度百科——启发式分析

5.1.1 启发式分析

启发式分析（heuristic analysis）是种你可用于评估已有设计的可用性方法，它基于用户体验领域的最佳实践。你可将其用于分析重新设计当前网站项目或用于分析竞争网站，以发现提供比其他公司更佳用户体验的机会。成果是一份描述站点优势和劣势的文档，包括改进建议。

系统状态的可见性。系统应该总是以及时恰当的反馈让用户知道当前在干什么。

为何要开展启发式分析？

进行这种分析是一种相对快速、不那么昂贵的获得设计反馈的方式。启发式分析可以获得关于设计质量的一般了解，并帮助识别潜在的设计问题。

我该如何做？

1.搜集产品和项目的背景知识。确保你了解站点的目标、需要支持的主要用户群列表、用户工作时所处的环境、对用户具备的专业知识的大致了解。
2.选择采用的启发准则。有很多可供参考的启发准则。除了Jakob Nielsen的列表，很多UX设计师参考Bruce Tognazzini的设计准则列表。
1. 浏览网站的重点区域，标出那些遵循启发准则较好或较差的地方。每次浏览应当产生如下信息: (1)总体观察。一个总结发现的短句。最好给其加上编号，这样以便你在解释报告时，可以快速引用。(2)一个简单描述。一到两个自然段，用于描述发现的上下文，例如，是在哪个过程的哪个点上发现了这个问题。(3)影晌级别。给观察到的问题评出高中低的级别，或者是站点中做得比较好的可供分享的正面发现。总之，高影响级别问题是那些你认为会导致很多用户执行任务失败或导致永久丢失信息的问题（例如，导致用户丢失正在编辑文档的问题）。中等影响级别问题会导致挫折和错误，但不是不可逆转。低影响级别问题是可能会导致一些混乱的小问题，但通常不会导致时间浪费或挫折。(4)建议。这是你分享的下－步骤或想法，可当作你遇到问题的补救措施。

如

观察：搜索功能似乎没有返回所有可能的结果
关注程度：高

产生混合结果的搜索功能的示例测试。用一个新发表文章中的关键字进行检索，结果返回的结果主题较少，有时无返回结果。也发现主要返回结果中只有返回到新故事的链接，没有视频。

建议：
1.  保证新内容在添加之前已经索引好并可被检索，或在发布后短时间内就可被检索。
2.  考虑将返回的结果内容按相关性组织在 一起，例如，具有类似分类或类似标签的设计准则列表故事，这样用户探索时有更多的线索可以遵循。
3.  考虑可以按类别展示搜索结果的万能搜索。
4. 利用搜索项日志来搞清常见搜索项。这也可以深入了解用户在哪些条目上碰到了困难。

4.给项目团队和主要利益相关方展示你的发现。给他们介绍你的观察和建议。讨论为何你给出这样的评级。

启发式分析如何帮助需求搜集？

一旦你完成启发式分析，你将深入了解网站（或其竞争对手）的现状，以及获得一份有助于需求搜集的想法列表。在需求收集活动中，你也将获得如何组织一些需要覆盖的主题的想法，这会带领我们进入到过程的下一步。

5.2 从利益相关方搜集想法

项目中最常犯的错误是，捕捉到一个功能特征并称其为需求，而不先去了解问题和期望产生的背景。
为何需求搜集过程经常缩短呢？搜集想法，并将其提炼成需求，这会花一些时间。很容易低估你为了列出需求并排列优先顺序需要提出的问题数。如果过程没有良好的组织或参与不充分，会导致项目中产生很多变动（chum）。 chum是指因为缺乏交流和参与导致额外会议和工作迭代而产生的浪费。它们和那些更有效率的工作迭代不同，那些迭代尝试努力成为最佳设计和测试验证方案的一部分）。因此如何鼓励一种较均衡的需求过程，既关注商业需求又避免耗时变动呢？下面是一个高效过程中的一些步骤。

1.勾画出角色和职责。保证团队成员在需求搜集时理解他们将要负责的角色。
2.从正确的群体、正确的利益相关方搜集信息，确保在以需求为焦点的访谈和会议中，时间得到最佳利用。
3.创建会议计划，包括会议期间将会讨论的主题以及将会提出的问题。
4.高效开会，捕捉想法并澄清。调查想法并深挖背后的需求。

当会议结束时，不要忘记感谢参与的利益相关方，并且当你开始提炼优先列表时及时告知他们进展。

5.2.1 勾勒职责

在搜集商业需求的活动中，通常通过项目团队成员访谈关键利益相关方来获取想法。业务利益相关方是指公司里那些在项目成功时会带给其业务相关利益的人，或是有领域知识可以贡献，或两者都有的人。这些人不是全职参与项目，但需要在流程的关键点参与，需求搜集是这样的－个关键点。要记住他们都有自己的日常工作，因此他们的时间很宝贵并且通常很难获得，除非你提前计划。
项目资助方是对项目成功直接负责的业务利益相关方，通常是公司的高层，如主管(director）。他或她不会在整个项目生命周期中每天参与，但很可能积极参与需求搜集并保证业务利益相关方的深度参与。资助方也可能会列席部分或全部会议。项目团队包括被作为资源正式分配到项目的人员。他们作为项目经理、UX设计师、商业分析师、技术负责人、视觉设计师、质量保证负责人等来参与。根据项目大小，这有可能是他们的主要工作。
在项目团队内部，需求搜集阶段的职责经常会很模糊。尽早花时间定义好职责，将确保搜集过程的高效。

下面这些问题将有助于你确定每个团队成员在需求搜集阶段应该承担的职责。

在最有生产力的团队中，谁应该主要负责召集和安排相应的业务利益相关方呢？这可以包括内部和外部利益相关方（如合作伙伴、销售方等）。
谁为业务利益相关方会议组织主题和问题呢？如果时间允许，这是团队的一个很好的协作练习机会。主要主持者应将他们组织好以让会议顺利进行。
谁组织会议？
谁负责记录，以及如何分享会议记录？
谁负责跟进，跟进哪些人？
是否有技术团队的成员出席所有的会议？如果是，此人如何参与（他们是倾听、提供输入还是其他）？

5.2.2 从合适利益相关方那儿搜集信息

访谈利益相关方的主要目的是获得对项目相关想法、需求、知识、挫折的多角度理解，并将其转化为项目需求。
也有很多涉及到不同群体的不成文利益，各方都感觉需要在项目中有代言人，并进入最终解决方案。尽管让人参与并获得他们的认同似乎政治意义大于实践意义，让你和关系网络保持接触，是让他们在项目过程中支持你的关键步骤。它也可以帮你避免在最后一刻进行更改，这可能发生在某个你没有交流过的人在流程的后期突然提出一个问题的情况下。因此让很多人参与进来通常是一个好主意。
另一方面，必须随时记得时间表和预算。让很多人参与会花费时间，无论是从他们的角度或是从你的角度，会议本身就很花时间，这还没考虑通过会议记录标出倾向并去掉冗余的工作。为了效率和对你自己好，排列访谈群体的优先顺序以及从群体中选择关键人充当群体的思想领袖非常重要。
你将涉及哪些利益相关方？下面这些群体通常是想法的好的来源。

那些依赖网站获得创意（开展活动）的群体（例如，那些进行市场营销活动，需要将信息展示到网站上的群体）。
需要直接支持网站或应用后台流程的群体，如提供内容、输入管理数据、立即响应收集到信息的群体。
客户服务一线人员，如电话或在线支持或任何面对面接待客户的人（例如，在零售场所或通过送货）。
销售、产品管理或咨询服务，代表需要展示的产品和服务。
人力资源，用于会见招募对象。
公共关系，用于给投资方和媒体提供信息。
任何需要发展成项目组成部分并会影响到设计的其他关系群体，如和合作伙伴及销售商关系。

当选择需要包含的人时，从项目资助方和熟悉相应群体的项目团队成员那里寻求帮助，让他们帮你选择合适的人。

一旦你弄清了你的利益相关方和会议结构，你就可开始规划会议。要在会议开始起数周就开始规划；将人们召集到一起不是一件容易的事情。

5.2.3 建立会议计划

在你选择合适利益相关方的同时，列出一系列需要覆盖和询问的主题（这也会帮你提炼利益相关方名单）。你应该为会谈的每个群体制订不同的计划，尽管群体之间的部分问题会有重复。
你也要确定会议中期望的细节程度。如果有大量的人你只会谈一次（例如，上面建议的不同部门成员），你希望搜集想法，但你不希望会议上花费过多时间在琐碎的细节上。例如，如果你的一个利益相关方告诉你一个想法 “客户可以在线跟踪订单”，你可能想简单询问一下为何此功能重要遗迹利益相关方是否认为网站很容易做到此事。这样的问题可以帮助识别各个利益相关方期望之间的主要差异，无需整个会议耗在一个问题上。然后你可以和项目团队一起整理出想法细节，并发回给利益相关方，以确认你写下的需求是否代表了他或她的原始想法。

5.2.4 DEMO 销售：需求搜集会议

参与者
内部销售：Jenny Bee, TracyKim, Joseph Arnold 
商机管理：Kevin Abernathy, Cat Parnell 
时长：2小时
目标： 了解当前销售流程， 并识别出网站中能更好地支持此流程的地方和机会。
背景：我们已经观看过购买流程的PPT演示， 里面提供了关于购买决策如何进行的很好背景。 我们也计划和客户服务团队交谈。
问题
销售流程
- 不同产品线的销售流程有何不同？
- 是否存在地区差异？
整体印象
- 你认为当前网站的主要访问者是谁？为什么？他们是怎样的？他们想在同站上完成什么？
- 网站对销售流程和／或销售完成率的贡献如何？
想象未来
- 当你考虑未来的网站时， 我们能做什么以更好地支持销售流程？
- 目前网站上的什么功能特征对销售很关键？
总结
- 是否有什么想法、 建议或关注还没有被提到7
- 你认为有哪些网站在支持销售方面做得特别好？

5.2.5 有效地开会

确保有一份共享词汇表

如果团队在搜集需求时有一份达成共识的常用词汇定义表，则可以避免很多混淆。例如，使用系统的人是被称为用户、顾客还是客户呢？人们是更熟悉交互设计师还是信息架构师的称呼呢？
想避免混乱，在每个会议开始前花些时间说明用到的术语及含义。创建一些帮助解释术语或角色关系的视觉表达会让你获益菲浅。
项目中将会用到的针对交付件的常用词汇表可帮助利益相关方理解流程和预期的输出类型。这让他们相信他们的时间和努力不会投入黑洞。
通常说来，如果你发现定义某个词汇不止一次（特别当你发现每次的定义都有细微不同时），可以考虑为它们制作一份项目词汇表并在项目团队中分享。下面也是一份最好在项目开始时便弄清楚的术语列表示例。

将要交互的角色（例如，求职者VS客户或内容制作者vs编辑）。
将被广泛引用的主要交付件（功能定义、线框图、站点地图）以及关于其差异的简要描述。
不同层次信息之间的差别。
需求和想法之间的差别。

（Xmind可以用起）

倾听想法并深挖需求

利益相关方可能做出似乎是需求的描述。

5.2.6 提炼需求

当会议结束后，将你搜集到的想法整理成功能分类。你将会注意到很多重叠；这是一个好现象，说明一个特定想法有很多利益相关方认同。去掉冗余并尝试将其提炼成能够有效捕捉利益相关方意图的想法列表。
将你搜集到的想法转变为你项目中有用并可跟踪的组成部分，并提炼成需求。想象
从云朵形成雨滴：你将大量和未定义的云朵转化成很多定义良好的雨滴。
你需要将其转化为系统需要完成的特定语句定义。最后产生的需求应该包括以下几方面。

对必须解决的整体需求有深入了解。
整理和提炼来自不同利益相关方的需求。
为设计提供方向，不做如何实现的具体指导。
作为独立工作单元服务于排序和跟踪。

当你开始将想法转化为需求时，确保技术负责人（或其他能够代表项目中开发团队的人）参与并对其提问，以帮助你在排列优先级时估计所需投入。如果有专门的负责质量保证的团队成员，那么此人也可通过一些非常详细的提问来为需求提炼提供帮助。

要将跟踪的想法细化为需求，可以问这样的问题。

跟踪要达到什么样的精度？
跟踪信息中应该包括哪些种类的信息。如，是否需要包含预计送达时间的及时更新？如果利益相关方有很多时间可以投入项目，这些问题可以和提供想法来源的他们一起探讨和细化。如果你无法太多接触利益相关方，你可以让项目团队通过内部讨论来确定细节，然后在让项目资助方来评审需求，以确保你的选择符合业务需要。

要注意在某些案例中，需求之间相互交叠，应该和其他功能分开设定优先级。
当你整理描述时，要注意你考虑的业务需求可能和用户需求冲突。

交叠业务

业务需求和用户需求之间的潜在冲突非常适合在用户研究期间探究。用户研究也允许你扩充为潜在需求的完整列表。记住，业务需求的搜集通常和技术可行性研究及用户需求搜集并行进行。

温习：

理解现状、启发式分析；
勾勒职责、搜集想法、建立会议、提炼需求

（完）

《UX设计之道》—5.业务需求