1700423394
1700423395
最用之不竭的需求源泉总是来自用户本身。但更多的时候，你的需求将来自与项目利益相关的同事—那些在企业中总想影响你的产品的人。
1700423396
1700423397
不管是哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。在第3章列出的用户研究技术都可以用来帮助你更好地了解用户，了解他们希望在你的产品上看到的特性的种类。
1700423398
1700423399
不管你是从企业内部的管理者，还是直接从用户处获得的帮助，来定义的这些需求，这个过程中得到的需求将分成三个主要类别。首先，最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会通过各种途径体现在最终产品上。
1700423400
1700423401
有时候人们口中说出来的、所期望的特性其实并不是他们想要的，当人们在某个过程或某个产品中遭遇到一些困难时，想象有某种解决办法可以缓解这一困难，这对任何人来讲都是很正常的反应。有时这个解决办法是行不通的，或者仅仅是治标不治本的办法。通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。
1700423402
1700423403
在这个阶段能得到的第三种类型的需求是人们不知道他们是否需要的特性。当你让人们讨论新的需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品。这些通常会在头脑风暴讨论的时候出现，那正是与会者有机会参与和探讨项目的可能性的时候。
1700423404
1700423405
具有讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。出于这个原因，汇集企业各个部门的成员或不同类型的用户代表来进行头脑风暴会议，是一种打开设计者思路、让他们考虑以前从未想到的可能性的、非常有效的工具。
1700423406
1700423407
让一个工程师、一个客服人员、一个营销人员坐到一间会议室中谈论同一个产品，这会对大家都有启发意义。听取从自己不熟悉的角度出发来考虑的、对于产品的观点，并给予反馈，可以鼓励人们多角度全方位地思考开发中的产品遇到的问题以及解决办法。
1700423408
1700423409
不管你设计的产品在什么样的设备上使用（或者我们正在设计的就是那个设备）我们的需求序列必须要考虑到硬件需求。这个设备有摄像头吗？有GPS吗？有陀螺感应指针（一种用来测量或保持设备坐标信息的装置）吗？这些因素都将会确立或限制产品功能的可能性。
1700423410
1700423411
通过这种方式讨论出来的功能需求通常是得到如何去除某些障碍的方法。举个例子来讲，假设你有一个用户已经决定要购买了—他们只是没有决定是不是买你的产品，你设计的产品要怎样才能让这个过程（首先是选择你的产品，然后买下它）对他们来讲更容易呢？
1700423412
1700423413
在第3章，我们看到有一种叫作人物角色（personas）的技术，通过创建虚拟人物来帮助我们更好地理解用户需求。在决定功能需求的时候，我们可以再次使用这些人物角色，把我们的虚拟人物放到一个简短的故事之中，我们称之为“场景（scenarios）”。一个场景是一个简短的故事，简单描述了一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。
1700423414
1700423415
我们也期望从竞争对手处得到一些启示。任何一个在做同一件事的企业基本上在试图满足同样的用户需求，同时也在试图完成相似的产品目标。竞争对手是否找到一种特别有效的特性，能完成其中的某个战略目标？他们是如何权衡和调整我们所面对的那些问题的？
1700423416
1700423417
即使不是产品的直接竞争对手也能提供丰富的潜在需求。例如一些游戏平台允许用户创建自己人的社交群组，那么在我们的数字录像软件上采用相似的特性或建立类似的机制，也许就能给我们一定的竞争优势，用来超越直接竞争对手。
1700423418
1700423419
1700423420
1700423421
1700423423
用户体验要素：以用户为中心的产品设计（原书第2版） 功能规格说明
1700423424
1700423425
功能规格说明在某些方面的名声不太好。程序员们痛恨功能规格说明，因为它们非常枯燥，并且会占用大量编码的时间去阅读它们。结果，那些“没有人读的功能规格说明”反过来又强化了“撰写它们是一件浪费时间的工作”的印象—事实上也正是如此！一个应用不当的功能规格说明就这样变成了自我应验的预言。
1700423426
1700423427
对功能规格说明的抱怨之一是它们没有反映实际的产品。“在实施过程中事情会产生变化”，每个人都理解这个—这是技术型工作的正常情况。有时候你考虑好的一些事情会行不通，或不大可能以你想象的那种方式来运作。无论如何，这并不是一个把撰写功能规格说明书当成一件失败的工作而放弃的理由。相反，它强调了一个真正起到了作用的功能规格说明书的重要性。当事情在实施过程中改变的时候，你不应该举起你的双手宣称撰写功能规格说明书是没有价值的，而是应该让撰写的过程变得快速简便，不要把它变成产品开发过程中一个独立的项目。
1700423428
1700423429
换句话说，文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明不需要包含产品的每一个细节—只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态—只需要记录在创建这个产品时已经确定下来的决议。
1700423430
1700423432
记下来
1700423433
1700423434
无论这个项目有多么庞大或多么复杂，有几条规则适用于撰写任何类型的功能规格说明。
1700423435
1700423436
乐观（be positive）。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如，下面这句描述就不太好：
1700423437
1700423438
这个系统不允许用户购买没有风筝线的风筝。
1700423439
1700423440
替换成下面这句会更好：
1700423441
1700423442
如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面。
1700423443
[
上一页 ]
[ :1.700423394e+09 ]
[
下一页 ]