读书：用户体验要素-以用户为中心的产品设计(2)

读书：用户体验要素-以用户为中心的产品设计(2)

第四章 范围层：功能规格和内容需求

带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略的目标。当你把用户需求和产品目标变成产品应该提供用户什么样的内容和功能时，战略就变成了范围。我们做的某些事是因为其过程具有价值，另一些事情是因为其产品具有价值。定义项目范围则同时在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。过程的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。工作流程+日程安排+里程碑，项目得有尽头。

用文档来定义产品，这件事很麻烦，但是你必须要做。原因：#1、这样你才知道你真正建设什么（如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标），最终产品不再是一个只停留在产品经理头脑里的不定型图像，它变成了一个在企业内部每一个级别的每个人都触手可及的东西，从高层管理人员到入门级工程师，人人都能参与进来。口口相传容易出现信息误解或丢失。每个人都认为别人肩负着设计和开发产品关键环节的责任，但事实这个人并不存在。拥有一系列明确的要求，能让你把责任分配得更清晰，这样可以大大提高协作的效率。#2、这样你才知道你不需要建设什么。许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。项目进行时，关于功能的、各种各样的可能性都会浮现出来－想法出来用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。了解“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。有意识地管理你的要求，当前难以满足的需求，可以为启动下一个版本的基础。

范围层讨论战略层面的抽象问题－“我们为什么要开发这个产品？”转而面对一个新的问题：“我们要开发的是什么？”【功能型产品：功能规格－哪些应该被当成软件产品的功能以及相应的组合、信息型产品：内容－编辑和营销推广的传统领域】，使用feature特性来同时表示软件的功能和所提供的内容。范围层确定的是全部的功能需求或功能规格。一个内容管理系统可以实现自动化流程，能展示和交付内容用户【作者－内容编辑－管理层－文字编辑－律师－用户】，包括使用说明和错误提示等。

定义需求：一些需求适用于整个产品，品牌需求时最常见的一种；某些技术需求是另一种。大部分时候，当人们说到某种需求的时候，他们想的是产品必须拥有的、某种特性的一句简短描述。需求的详略程度常常取决于该项目的具体范围。如果该项目的目标是完成一个复杂的子系统，那么就需要有一个非常详细明确的需求，即使这个项目的范围相对于整个网站来讲非常小。如果大型项目的内容是相似或相同性质的东西，内容只需要一般化就可以了。最用之不竭的需求源泉总是来自用户本身。但更多时候，你的需求将来自与项目有关的同事－那些在企业中总想影响你产品的人。

不管哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。得到需求将分成三个主要类别：最显而易见的是人们讲述的、他们想要的东西－清晰的好想法；口中说出、所期望的特性其实并不是他们的想要的，探讨解决办法和建议，有时候能真正解决问题的、完成不同的需求；第三种类型需求是人们不知道他们是否需要的特性。当你让人们讨论新的需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品－这些通常会在头脑风暴讨论的时候出现，那正是与会者有机会参与和探讨项目的可能性的时候。具有讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。汇集企业各个部门的成员或不同类型的用户代表来进行头脑风暴会议，是一种打开设计者思路、让他们考虑以前从未想到的可能性的、非常有效的工具（听取从自己不熟悉的角度出发来考虑的、对产品的观点，并给予反馈，可以鼓励人们从多角度全方位地思考开发中的产品遇到的问题及解决办法）。

人物角色（personas）通过创建虚拟人物来帮助我们更好地理解用户需求。我们决定功能需求的时候，可以再次使用这些人物角色，虚拟人物放入故事，场景化－一个场景是一个简短的故事，简单描述一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，帮助他顺利完成这个过程的潜在需求。或研究竞争对手……

功能规格说明：文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明不需要包含每一个细节－只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态－只需要记录在创建这个产品时已经确定下来的决议。

记下来：无论这个项目有多么庞大或者多么复杂，有几条规则适用于撰写任何类型的功能规格说明。

• 乐观be positive。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如［这个系统不允许用户购买没有风筝线的风筝］，替换成［如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面］。
• 具体be specific。尽可能详细地解释清楚情况，这是我们能决定一个功能是否被实现的最佳途径。最受欢迎的视频要重点关注 vs 上一周被播放最多的视频要显示在列表的最前端
• 避免主观的语气avoid subjective language。保持明确和避免歧义，功能规格必须可验证－它必须要能证明“这个需求没有被满足”。比较主观［这个网站的风格应该是时尚、闪耀的］－客观［网站的外观应该符合企业的品牌指南文档］。可以量化地定义一些功能，通过这样的手段来避免主观性。

内容需求：文本+图像+音频+视频，不要混淆某段内容的格式和它的目的。FAQ（常见问题）一系列简短的问题和回答，这个词仅仅指的是内容的格式。一个FAQ的真正价值，在于它可以随时提供用户普遍需要的信息。内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小。

尽可能早地取得某个人来负责每一个内容元素也是非常重要的。内容不仅需要初次上线，还需要日常维护工作（更新频率，在用户期望值和有效资源之间的一个合理的中间值），可能还需要为不同用户呈现不同内容。对于大量内容的项目来说，内容信息都记录在内容清单。虽然繁琐但必要：团队中每个人才能确切知道他们设计用户体验需要做哪些工作，熟悉要做哪些事情。

确定需求优先级：收集潜在需求或想法不是很困难。最棘手的是排列哪些功能包含进现有项目，有时一个战略目标将产生多个需求；另一个方面一个需求也可以实现多个战略目标。需求和战略目标可能多对多，项目范围建立在战略基础上，满足网站目标或用户需求，加上实现这些需求的可行性有多大。有些特性因为技术局限无法实现，有些特性需要很多资源去做，有些特性需要快速上线－很少有功能独立存在，特性冲突不可避免，需要一起权衡得到连贯统一的产品。留意那些看上去有可能需要改变战略的特性建议，它们在制定愿景文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除。有特性不在项目范围，超越限制条件，听起来非常不错，重点审视某些战略目标。解决管理层之间的争论的最好办法是要求制定战略—关注目标，而不是实现手段。对决策者表示认同，是解决特性冲突的关键。战略目标之间的重要程度也可能不同。

第五章 结构层：交互设计与信息架构

在定义好用户需求并排列好优先级后，我们对于最终产品将会包括什么特性已经有了清楚的图像。然而，这些需求并没有说明如何将这些分散的片段组成了一个整体。这就是范围层上面一层：为网站创建一个概念结构。将我们的关注点从抽象的决策与范围问题，转移到更能影响最后的用户体验的具体因素。然而，在抽象和具体之间的分隔线有时会变得模糊不清—虽然我们在此时做出的决定对最终产品将会产生显而易见、真实可触的影响，但是这里所做的决策本身仍然包括大部分的概念性内容。

交互设计为用户设计结构化体验，功能型产品+内容建设主要是通过信息架构来构建用户体验，信息型产品【考虑组织管理、分类、顺序排列、图书管理、新闻学、技术通信等学科】，理解用户的工作方式、行为和思考方式。交互设计和信息架构都强调一个重点：确定各个将要呈现给用户的元素的模式（pattern）和顺序（sequence），交互设计关注于将影响用户执行和完成任务的元素、信息架构则关注如何将信息表达用户的元素。

交互设计关注于描述“可能的用户行为”，同时定义“系统如何配合与响应”这些用户行为。成功的舞蹈是要求每一个参与者能够预测对方的移动，传统的程序员最关注的两个方面：它做什么和它怎么做（关注细节，技术效率更高）。与其针对机器的最佳工作方式来设计系统，不如说按用户的行为方式来设计系统。

概念模型：用户对于“交互组件讲怎样工作”的观点，可以反映系统的一个组件或是整个系统。软件是否把某个特性处理成用户所熟悉的某个概念？规划好概念模型能帮助你做出一致的设计决定。内容元素是一个位置还是对象并不重要：重要的是网站能够将这些内容元素从头到尾一致地表现出来，而不是有时候将元素当成位置，有时候又当成的对象。零售商品和产品目录的概念模型似乎都可以完美地让用户从网上发出订单，一个令人不太熟悉的概念模型只有在用户能正确理解并诠释它的时候才能起到作用－打破传统也没有错，只要有一个好理由说明“为什么这样做”。我们不必将概念模型明确地告诉我们的用户，理想情况下我们不需要告诉用户，用户使用网站靠直觉，网站交互行为与他们隐含的期望完全相符。

错误处理（交互设计会处理每个级别的错误，以确保更高比例的用户能有积极的体验－预防、改正、恢复）：第一个同时是最好的防止错误的方法，是将系统设计成不可能犯错的那种（让大部分用户错误都不要发生，可并不简单）、第二个避免错误的方法是使错误难以发生，系统应该帮助用户找出错误并且改正它们，某些情况下甚至可以系统自动纠错－有效的错误信息和容易自我解释的界面可以在错误发生后帮助用户纠正、第三是错误恢复，撤销功能，对于那些不可能恢复的错误，提供大量的警告就是系统唯一可提供的预防方法，但这种错误只有在用户实际注意到它时才能产生作用。

信息架构：研究的是人们如何认知信息的过程，对产品而言，信息架构关注的就是呈现给用户的信息是否合理并且具有意义。

• 结构化内容，设计组织分类和导航的结构，让用户可以高效率、有效地浏览网站的内容。信息架构与信息检索密切相关，设计出让用户容易找到信息的系统。许多情况下，网站的结构还必须教育、通知或说服用户。信息架构要求创建分类体系【从上到下－将从战略层所考虑的内容，即根据产品目标与用户需求直接进行结构设计，先从最广泛、有可能满足决策目标的内容与功能开始进行分类，然后再根据逻辑细分出次级分类；从下到上－已有资料放进去最低级别的分类，然后归属到较高级别，逐步构建出能反应我们的产品目标和用户需求的结构】，从上到下易忽略重要细节，从下到上可能导致架构不能容纳未来内容的变动或增加。不一定非要给某个级别或部分结构加上一个特定数目限制，结构质量是最重要的标准，多少步并不严格，而是每个步骤必须是合理的，当前的步骤是否自然延续了上一个步骤的任务。清晰定义的过程而非令人困惑的过程。一个高效结构的优点就是具备“容纳成长和适应变动”的能力－新内容的积累最终将会使你再次审视网站的组织分类原则。一个完整的用户体验，包括网站结构，都是建立在对网站目标和用户需求的理解之上的。
• 结构方法，信息架构的基本单位是节点，节点可以对应任意的信息片段或组合－小到数字，大到图书馆。我们要处理的是节点，而不是页面、文档或组件，使用一种共同语言和共同结构的概念来对付各种不同的问题。节点的抽象性使得我们能明确地设定我们的关注点的详略程度。层级结构－父子级节点，树形结构或中心辐射结构；矩阵结构－允许用户在节点与节点间沿着多纬度移动；自然结构－不会遵循任何一致的模式，节点逐一被连接起来，没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题很合适。但没有给用户提供一个清晰的指示；线性结构：连贯的语言流程。
• 组织原则：节点在信息架构中是依据组织原则来安置的。决定哪些节点要编成一组，哪些节点要保持独立标准。不同组织原则将被应用在不同的区域和网站不同的层面。一般来说，你在产品最高层级使用的组织原则应该紧密地与“网站目标”和“用户需求”相关，而较低层级，内容与功能需求将对你所采取的组织原则产生重大影响。我们的困难不是创建一个结构，而是创建一个能与“我们的目标”和“用户需求”相对应的、正确的结构。战略告诉我们用户的需求是什么，范围则告诉我们什么样的信息将满足那些用户需求。在创建结构时，我们就要具体地识别出用户心目中至关重要的那些信息。成功的用户体验，就是能事先预知用户的期望并将其纳入设计之中。截面（属性）
• 语言和元数据：使用用户的语言并且保持一致性是非常重要的，强调一致性的工具称为受控词典（网站使用的一套标准语言），包括了解你的命名原则：描述、标签，和网站使用的其它术语。受控词典是网站使用的一套标准语言，与用户谈话并了解他们的沟通方式，是开发出一个让用户感到自然的命名原则系统的最有效方式，防止企业内部的专用术语侵入网站的最佳方法。类词词典－提供常见的、未纳入该网站标准用语的词汇以供选择。

元数据：关于信息的信息，即以一种结构化的方式来描述内容的信息。将搜索引擎与类词词典连接起来，再加上元数据，就能让搜索引擎变得更聪明。

• 团队角色和流程：文档一定要描述清楚网站的结构－从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况－根据项目复杂度不同，可以走很大的不同。信息架构或交互设计主要文档是示意图，视觉化地呈现结构，表述“分支、群组、组件之间的联系”－互联网早期这种示意图叫做网站地图，现在用架构图。这种架构图并不一定要写明网站每一页的每个链接，太细只会造成混淆并且屏蔽了团队真正需要的信息。架构图最重要的是记录概念关系：哪些类别需要放在一起，而哪些需要保持独立？在交互过程中那些步骤要怎样互相配合？作者提出“视觉辞典”，一个提供从非常简单（上图）到非常复杂（下图）的示意结构系统。“到底谁在负责信息架构”，用户体验设计师－你是否有一位专家来解决结构问题并不重要，重要的是这些问题能由某个人来负责。不论你是不是做过这方面的规划，你的网站都会有一个结构。一个建立在明确规划的网站，会减少频繁检查维护的工作量，也能为网站的所有者带来可见的结果，同时还能满足他们的用户的需求。