1700423440
替换成下面这句会更好：
1700423441
1700423442
如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面。
1700423443
1700423444
具体（be specific）。尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径。
1700423445
1700423446
对比下面的例子：
1700423447
1700423448
1.最受欢迎的视频要重点标注。
1700423449
1700423450
2.上一周被播放最多的视频要显示在列表的最前端。
1700423451
1700423452
第一句话看上去像是定义了一条明确的需求，但是不需要花费太大精力就能看出它有很多漏洞。什么叫做“最受欢迎”？如果这个视频的评论最多，是否就“最受欢迎”了呢？那么被投票最多的那个视频也算吗？另外如何“重点标注”它们？
1700423453
1700423454
第二句话用具体的细节定义清楚了我们的目标，定义了我们认为什么算“最受欢迎”，并且描述了关于“重点标注”的机制。
1700423455
1700423456
避免主观的语气（avoid subjective language）。这是另外一种使需求“保持明确”和“避免歧义”的途径—因而也避免了误解的可能性。
1700423457
1700423458
这里有一个非常主观的功能规格说明：
1700423459
1700423460
这个网站的风格应该是时尚、闪耀的。
1700423461
1700423462
功能规格必须可验证—就是说，它必须要能证明“这个需求没有被满足”。你如何去验证这种被宣称为“时尚”和“闪耀”的产品品质？我对于时尚的定义也许并不符合你的，而CEO更可能对此有完全不同的看法。
1700423463
1700423464
这并不是说你不能要求你的网站时尚。只是必须找到某种方式来明确说出应该达到的标准：
1700423465
1700423466
这个网站应该符合邮递员Wayne所期望的时尚。
1700423467
1700423468
Wayne通常不会对这个项目说些什么，但是我们的项目发起人很显然会尊重他对于时尚的看法。而且这有可能和我们的用户的期望值是一样的。但是这样的一个需求仍然是很主观的，因为我们依赖的是Wayne的认同，而不是可以更客观界定的一系列的标准。所以，这个功能规格说明最好能像这样：
1700423469
1700423470
网站的外观应该符合企业的品牌指南文档。
1700423471
1700423472
时尚的概念已经完全从这个需求中消失了。相反地，我们得到了一个清晰、毫不含糊的、已有的参考指南。为了确保品牌指南有足够的时尚性，负责市场的副总裁可能需要去了解邮递员Wayne，或者去和她十几岁的女儿交流，甚至她还可能做一些用户调研的工作。这取决于她。但是现在我们可以明确地说出“这个需求是否被满足了”。
1700423473
1700423474
我们也可以量化地定义一些功能，通过这样的手段来避免主观性。正如成功的标准能使战略目标得以量化一样，用量化的标准来定义功能也能有助于知道我们是否满足了需求。比如，要求系统具有“高级别的执行能力”，我们可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。如果最终产品只能支持千位数的用户，我们就知道这条需求没有被满足。
1700423475
1700423476
1700423477
1700423478
1700423480
用户体验要素：以用户为中心的产品设计（原书第2版） 内容需求
1700423481
1700423482
很多时候我们说到的内容指的是文本。但是图像、音频和视频有时候有可能比其文字还要重要。这些不同类型的内容可以结合到一起，相互协作去满足某一个需求。比如说，一个涵盖了运动赛事的内容专题，它可能是一篇附有照片的文章以及视频片段。定义出所有不同类型的内容，可以帮助你确定需要哪些资源来制作这些内容（或它们是否应该被提供）。
1700423483
1700423484
不要混淆某段内容的格式和它的目的。当我和管理层讨论内容需求的时候，所听到的第一件事往往是：“我们应该有FAQ（Frequently Asked Questions：常见问题）。”但是“FAQ”这个词仅仅指的是内容的格式：一个系列简短的问题和回答。一个FAQ给予用户的真正价值，在于它可以随时提供用户普遍需要的信息。其他的内容需求也可以满足同样的目的；但是当关注点是格式时，目的本身就可能被遗忘。多半的结果是，FAQ忽略了这个词汇中“常见”两个字，内容设计者总是用其他一些问题的答案替代了能真正满足FAQ需求的答案。
1700423485
1700423486
内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。这些大小的估计不一定要非常精确—大致相近即可。我们只收集最紧要的关键资料，用于设计适当的工具来管理内容。设计一个只有小缩略图图片的产品，与设计一个提供原始尺寸图片的产品是完全不一样的；事先知道这些内容元素的大小，能让我们在这个设计过程中做出最明智的决策。
1700423487
1700423488
尽可能早地确定某个人来负责每一个内容元素也是非常重要的。一旦某个内容特性被大家所认可，确定其对战略目标是有效的，它都会不可避免地被当成一个好主意—只要是别人来负责建设和维护它。如果我们在没有确定谁将会负责这些内容需求的情况下，过早过多地投入到开发流程中去，那么最后我们得到的很可能就是一个千疮百孔的产品，因为那些在假想阶段人人都喜欢的特性，将在实际执行的时候变得非常沉重。
1700423489
[
上一页 ]
[ :1.70042344e+09 ]
[
下一页 ]