战略层要解决的是“用户的需求是什么”，范围层告诉我们“什么样的信息将满足用户需求”，而在结构层我们要面对的问题是：“具体识别出用户心目中至关重要的信息 ”。
结构层的定义
在定义好用户需求并排列好优先级别之后，这些需求并没有说明如何将分散的片段组成一个整体，而结构层为产品的创建一个概念结构。在这个部分的决策本身仍然包括大部分的概念性内容。
在传统的软件开发行业，交互设计主要指的是一种“为用户设计结构体验”的方法。而信息架构是在内容建设方面构建用户体验。但是交互设计和信息架构都强调的一个重点是：确定各个将要呈现给用户的元素的模式（patterns）和顺序（sequences）。在这个重点中交互设计关注将影响用户执行和完成任务的元素，信息架构则关注如何将信息表达给用户的元素。并且我们还会接触到产品成型过程中的重要概念概念模型（conceptual model）。
· 交互设计
交互设计关注与描述“可能的用户行为”，同时定义“系统如何配合与相应”这些用户行为。也就是我们经常会接触到的“输出与反馈”。
因为作者是程序员出身，他最关注软件的两个方面是“它做什么”和“它怎么做”，但是在重视技术效率时，往往忽略了什么才是对用户来说最好的系统。
· 概念模型
概念模型（conceptual model）是用户对于“交互组件将怎样工作”，软件是否把某个特性处理成用户所熟悉的某个概念。这里我们需要将概念模型与心智模型（或心理模型，mental model）区分开，心智模型指的是由个人经验及学习，在脑海中对某些事物发展的过程，进行预测写下的剧本。
这里的心智模型指的是用户的心智模型，而概念模型指的是我们最后把产品做成的样子。当产品的概念模型和用户的心智模型不相符，那么这个产品的学习成本是很高的，也很难被用户接受。使用人们熟悉的概念模型，会使用户很快适应一个不熟悉的网站。这也是为什么现在很多产品看起来很像的原因，在用户已经熟悉了某类产品的通用做法，我们继续采用这种做法，会加快用户熟悉产品的速度。
如果你有足够的把握勇于创新，那么要保证自己有一个好的理由说服用户，并且准备好一个通用的备用方案。令用户不太熟悉的概念模型只有在用户能正确理解并诠释它的时候才能起到作用。
在《About Face》中，将概念模型进一步细化为实现模型与呈现模型，其中实现模型指向的是程序员的工作，呈现模型指向设计师的工作。我们不需要把概念模型明确告诉用户，相反我们需要隐藏代码层面的实现模型，让产品展现的内容符合用户的心智模型，不需要告诉用户产品是如何实现这个功能的，只要用户简单快速实现自己的目标即可。
当然也不能为了使二者匹配，将现实生活中的东西生搬硬套到产品的概念模型中。举一个例子，见仁见智，这里谨以一个“双重果粉”的身份说一下使用感受。我们都知道坚果自带程序的拟物效果处理非常细致，从视觉感官上非常享受。但是有些拟物过度的设计会降低易用性，比如图中的秒表就是一个完全拟物的例子。
虽然二者都包含了开始计数、停止、多次计数、清零等功能，但是从使用感受上，却完全不同。第一次看到坚果的页面，从未使用过体育秒表的我是懵的，“好腻害的样纸，但是怎么用这东西…………啊这个居然可以按，666……”由于重视秒表的展现，上部分区域挤压了多次计数结果的展示空间。
再看苹果的页面，页面简单直接，识字的傻子都会用，并且能清楚地知道哪里是可以点击的，还并且能准确地点中想要的操作。当然我知道会买锤子的大家一定都是具有冒险探索精神和不怕累不怕苦的品质的，也知道秒表对大部分人并不是一个高频使用的功能，但是就我个人而言，一旦要着急计个时什么的一定是会选择用苹果的秒表。
· 错误处理
当我们对用户的心智模型猜测不准或者因为一些技术上的限制，我们需要考虑用户犯错时，系统应该怎么做：
1.最好的防止错误的方法，是在用户操作前就将系统设计成不可能犯错的那种。
2.在用户操作时，避免错误的方法是使错误难以发生。系统应该帮助用户找出错误并改正错误，当然也要小心一些令人反感的试图善意修改用户错误的提示。
3.错误发生之后，有效的错误信息和容易自我解释的页面帮助用户纠正。系统应该为用户提供从错误中恢复的方式，同意用户“撤销”操作。并且对于一些不可恢复的错误，提供准确的警告提示。
· 信息架构
信息架构主要体现在信息型产品的结构层，对于目前市面上的大部分产品，内容是躲不开的，因此信息架构也是我们需要重点理解的部分。在以内容为主的网站上，信息架构的主要工作是设计组织分类和导航的结构，让用户可以高效率、有效地浏览网站的内容，使呈现给用户的信息合理并且具有意义。
信息架构与信息检索的概念密切相关，都是为了设计出让用户容易找到信息的系统。下面将信息架构分为结构化内容、结构方法、组织原则、语言和元数据这四部分进行了解。
结构化内容
信息架构要求创建分类体系，涉及的领域包括向来都要考虑的组织管理、分类、顺序排列。我们通过从上到下和从下到上两种方式来建立分类体系。
从上到下（top-down approach）：从战略层所考虑的内容入手，根据产品目标与用户需求直接进行结构设计。先从最广泛的、有可能满足决策目标的内容与功能开始进行分类，然后再依据逻辑细分出次级分类。
缺点是可能导致内容的重要细节被忽略。
从下到上（bottom-up approach）：从范围层所考虑的内容入手，根据内容和功能需求的分析而来。先从已有的资料开始，全部放入最低级别的分类中，再把它们分别归属到高一级的类别，从而逐渐建立出耿恭反映我们产品目标和用户需求的结构。
缺点是可能导致架构过于精确地反映出现有内容，可拓展性不强。
结构质量最重要的标准：不是整个过程一共需要多少步骤，而是用户是否认为每一个步骤都是合理的，以及当前的步骤是否自然地延续了上一个步骤中的任务。貌似很多产品经理都很喜欢把所有步骤放在同一个页面上，在app端也希望在一个页面把所有事情做完。这时候你就可以说理直气壮地告诉TA“大量数据证明，用户会喜欢一个被清晰定义的七步过程，而不是一个令人困惑的、被勉强压缩的三步过程。”
另一个证明结构是否高效的标准是产品的“容纳成长和适应变动”的能力，充分考虑产品的可拓展性，避免了设计师和研发人员每次迭代都是一次大手术，更方便页面的统一性。
结构方法
信息架构的基本单位是节点（node）。节点可以对应任意的信息片段或组合，可以是一个数字，一个控件，一个组件，一个页面，甚至一个功能。节点的抽象性使得我们能明确地设定对产品关注点的详略程度。常见的结构类型有层级结构、矩阵结构、自然结构、线性结构。
层级结构（hierarchical structure）：又称树状结构（tree structure）或中心辐射结构（hub-and spoke structure）。它的节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每一个节点都有子节点，但是每一个节点都有父节点。
这种类型的结构是最常见的，倾向于层级的工作方式。
矩阵结构（matrix structure）：允许用户在节点与节点之间沿着两个或更多的“维度”移动。
这种类型的结构通常用于“带着不同需求的用户”，因为它的每一个“轴”都可以与每一个用户的需求联系在一起。
自然结构（organic structure）：不会遵循任何一致的模式。节点是被逐一连接起来的，同时这种结构没有太强烈的分类概念。
这种类型的结构适合于对探索一系列关系不明确或一直在演变的主题。
线性结构（sequential structure）：连贯的语言流程是最基本的信息结构类型。我们接受的九年义务教育也同属于线性结构。
这种类型的结构常见用于小规模的结构，比如单篇文章或专题。大规模的结构则被用于那些内容顺序对于用户需求非常关键的应用程序，比如教学资料。
组织原则
节点在信息架构中是依据组织原则（organizing principle）来安置的，组织原则是我们决定节点分组或独立的标准，不同的组织原则将被应用在不同的区域和层面。
一般来说，我们在产品最高层级使用的组织原则应该紧密地与“网站目标”和“用户需求”相关，而在结构中较低的层级，内容与功能需求将对所采取的组织原则产品重大影响。任何一种信息收集都有一个固定的概念性结构。实际上，这种概念结构通常不止一个，那也是我们要解决的问题之一——创建一个能与产品目标和用户需求相对应的、正确的结构。
书中还提到了一个知识点截面（facets），这是图书馆学的一个概念。产品的内容可以按照一定的属性进行分类，而这些属性就叫做截面。使用错误的截面可能比没有使用截面更糟糕，解决的办法是将每一个有可能的截面都当做组织原则呈现给用户，让用户自己选择最重要的那个。
语言与元数据
使用“统一规范的语言”、“用户的语言”不论是在内部工作中，还是输出给用户都十分重要。因此，我们需要对命名原则（nomenclature）进行规定，包括描述、标签，和网站使用的其他术语。
把用来强调一致性的工具称为受控词典（controlled vocabulary），是网站使用的一套标准语言。受控词典提供了一个明确的资源以确保大家都能使用用户语言，并且防止企业内部的专用术语侵入网站。如果词汇随意使用不统一的话，我们在工作中沟通的效率会大大降低。程序员也对文档表示疑惑，这说的是一个功能还是三个功能？
除此之外，我们还会创造类词词典（thesaurus）提供常用的、但未纳入该产品标准用语的词汇以供选择，也包括一些词语更广义、更狭义或相关词汇的建议。这在电商类产品中非常重要，有产品但是搜不出来，或者搜出来结果不对就非常尴尬了。好的类词词典能做到高度精准的、并且推荐高度相关的搜索结果。
受控词典与类词词典对建立包含元数据（metadata）的系统特别有用。元数据是“关于信息的信息”，即以一种结构化的方式来描述内容的信息。好的元数据可以帮助用户在产品中更快速地找到信息，在元数据的帮助下，搜索引擎变得更加智能更加聪明。
· 团队角色和流程
在这个层面的文档一定要描述清楚产品的结构——从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况。信息结构或交互设计的主要文档是示意图，也就是架构图（architecture diagram），视觉化呈现结构对于我们来说是表述“分支、群组、组件之间的联系”的一种最高效的方式。
架构图最重要的是记录概念关系：哪些类别需要放一起，而哪些需要保持独立？在交互过程中那些步骤要怎么样互相配合？作者创造的图解结构，从非常简单到非常复杂的示意结构系统，名为视觉词典（visual vocabulary）。
小结
成功的用户体验，就是能事先预知用户的期望并将其纳入设计之中。在实际工作中，信息架构和交互设计的工作范畴非常相近且相关，这部分的内容开始由交互设计师主导完成。在完成过程中切记不要过早地纠结细节，先将主要功能和主要场景走通，并且与需求方实时沟通，摸透需求的本质，只有这样框架层的内容才能继续在结构层搭建起来的框架上继续完成。
《用户体验要素》阅读笔记
一、初识用户体验
二、网站的用户体验
三、用户体验五要素
四、战略层：产品目标和用户需求
五、范围层：功能规格和内容需求
六、结构层：交互设计与信息架构
七、框架层：界面设计、导航设计和信息设计
九、表现层：感知设计
十、用户体验的应用
网友评论