今天为大家更新《用户体验要素》的第四章——范围层——确定需求优先级
本小结关键词：确定需求优先级
主要观点：确定需求优先级，评估需求是否能满足战略目标以及实现的可行性
前两节我们讲了如何去定义需求，并如何写好一个功能规格说明文档定，今天我们聊聊如何确定需求优先级。
内容需求
很多时候我们说到的内容指的是文本。但是图像、音频和视频有时候有可能比其文字还要重要。这些不同类型的内容可以结合到一起，相互协作去满足某一个需求。比如说，一个涵盖了运动赛事的内容专题，它可能是一篇附有照片的文章以及视频片段。定义出所有不同类型的内容，可以帮助你确定需要哪些资源来制作这些内容(或它们是否应该被提供)。
不要混淆某段内容的格式和它的目的。当我和管理层讨论内容需求的时候，所听到的第一件事往往是:“我们应该有FAQ ( Frequently Asked Questions:常见问题)。”但是“FAQ”这个词仅仅指的是内容的格式：一个系列简短的问题和回答。一个FAQ给予用户的真正价值，在于它可以随时提供用户普遍需要的信息。其他的内容需求也可以满足同样的目的；但是当关注点是格式时，目的本身就可能被遗忘。多半的结果是，FAQ忽略了这个词汇中“常见”两个字，内容设计者总是用其他一些问题的答案替代了能真正满足FAQ需求的答案。
内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。这些大小的估计不一定要非常精确，大致相近即可。我们只收集最紧要的关键资料，用于设计适当的工具来管理内容。设计一个只有小缩略图图片的产品，与设计一个提供原始尺寸图片的产品是完全不一样的；事先知道这些内容元素的大小，能让我们在这个设计过程中做出最明智的决策。
尽可能早地确定某个人来负责每一个内容元素也是非常重要的。一旦某个内容特性被大家所认可，确定其对战略目标是有效的，它都会不可避免地被当成一个好主意——只要是别人来负责建设和维护它。如果我们在没有确定谁将会负责这些内容需求的情况下，过早过多地投入到开发流程中去，那么最后我们得到的很可能就是一个千疮百孔的产品，因为那些在假想阶段人人都喜欢的特性，将在实际执行的时候变得非常沉重。
而这正是人们在确定需求的时候常常忘记的事情：内容是一件艰苦的工作。也许你可以找一些合作的资源来为网站的初次上线及时地准备好一些内容(或者，更有可能指定某个市场人员来完成这个工作)，但是谁来更新它们呢?内容(嗯，应该说，有效的内容)需要日常维护工作。如果在做内容规划的时候，你认为它们只需要发布一次，之后再也不用更新的话，那么随着时间的推移，这个网站就越来越难以满足用户的需求。
这就是为什么你应该定义每一个内容特性的“更新频率”的原因。更新频率应该来自于你产品的战略目标：从你的网站目标来看，你希望用户多长时间来访问一次?从你的用户需求来看，他们希望多长时间更新一次信息?无论如何，要记住，对于你的用户而言较为理想的更新频率(“我要马上了解每一件事，24小时服务!”)也许对你的企业来说不切合实际。但你必须要确定一个频率，它是介于你的用户期望值和有效资源之间的一个合理的中间值。
如果你的网站是为各种拥有相异需求的用户服务的，搞清楚哪些用户想要哪种内容，能帮助你决定用什么方式来呈现这些内容。“为孩子们准备的信息”与“为他们的父母准备的信息”是两种完全不同的方式；而“为所有人准备的信息”则应该是第三种处理方式。
对于那些已有大量内容的项目而言，很多关于内容的信息都记录在一个内容清单( content inventory)中。整理一个现有网站中所有内容的清单看上去像是一件枯燥无味的事——确实也是如此。但是整理出这个清单(它通常采用一种简单的格式，即使是一个非常庞大的电子表格)是很重要的，其原因和我们必须要搞清楚具体需求一样重要：这样团队中的每个人才能确切地知道他们设计用户体验需要做哪些工作了。
确定需求优先级
收集潜在的需求或想法不是很困难。几乎每一个经常接触产品的人(不管他们是企业内部还是外部的人)都能说出至少一个“这个产品应该增加哪些特性”的某个想法。最棘手的部分是排列出哪些功能应该包含到你现在的这个项目中去。
在战略目标和需求之间，你几乎看不到一对一的简单关联。有时一个需求可以满足多个战略目标。同样，一个战略目标也常常关系到多个不同的需求。
由于项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标(无论是网站目标还是用户需求)。除了这两种目标，我们还要额外确定第三种范围：实现这些需求的可行性有多大?
有些特性可能会因为技术上的局限而无法实现，举例子来说，现在还完全没有办法让用户能闻到网页上的产品，无论他们是如何渴望这个功能。另外一些特性( 尤其是内容方面的)之所以不可行，则是因为它们需要很多资源去做(无论是人力还是财力)这超出了我们的能力范围。而有时候，仅仅是因为时间不够：这个特性需要花费3个月来完成，但是企业的管理层要求在两个月以后上线。
如果是因为时间有限，那你可以把这个特性放到下一个版本或项目里程中。如果是资源有限，则技术或企业的变化有时能减少资源的负担(但是重要的是，并不总是)，从而使某个特性能得以实现(无论如何，不可能的事情仍然不可能实现，这很遗憾)。
很少有功能是独立存在的。甚至产品的内容也必须要依赖其他特性的支持，并告诉用户怎样最好地利用产品所提供的内容。这不可避免地导致了特性之间的冲突。有些特性要和其他的一起权衡，才能得到一个连贯的、统一的产品。举例来说，一些用户也许想要一步提交订单的过程——但是网站所使用的、混乱的老数据库无法适应这个需要。采用多个步骤的流程是更好的办法，也许你也可以重新设计数据库系统?这完全取决于你的战略目标是什么。
留意那些看上去有可能需要改变战略的特性建议，它们在制定愿景文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。但是如果有那么一个特性，尽管它不在项目范围之内，也超越了任何一个的限制条件，但听起来仍然像一个不错的想法，那么此时你可能需要重要审视某些战略目标。不管怎么样，如果你发现自己正在反复审视战略目标，那么你极有可能是太早地进入了需求定义阶段。
如果你的战略计划或愿景文档在战略目标的范围内制定了令一个清晰的优先级别顺序，那么这些优先级别应该是决定是否采纳人们所建议的相关特性的首要因素。有时候，两个不同战略目标之间的重要程度也会出现不是很清楚的情况。这时候，特性最后是否能纳人项目范围之中，往往取决于企业的政治局面。
当管理层谈到战略的时候，他们通常从某种产品特性开始，然后你不得不耐心地把他们引导到后面的战略因素上去。由于管理层常常分不清特性和战略，某些特性总是会占据上风。因此需求的定义过程就变成了与这些管理层进行谈判的过程。
控制谈判的过程会非常困难。解决管理层之间的争论的最好办法是要求“制定战略”。关注战略目标，而不是各种实现这些目标的手段。当你面对的是一个总是把注意力放在某个战略目标特征上的高层决策者，如果你能向他保证他所关注的这个特征可以用另一个方式来满足的话，他就不会感觉自己的意见被忽略了。不过，说起来容易做起来困难。对决策者的需求表示认同，是解决特性冲突的关键。谁说技术人员不需要沟通技巧呢?
