本章聚焦于五个层次中的结构层，主要介绍如何完成功能型与内容型产品的设计。本篇笔记共6721字，预计需要11分钟完成阅读。
对于产品的功能呈现，我们可以为不同层级选定合适的概念模型，减少用户的理解成本；合适的错误处理也可以在用户的使用过程中进行引导。对于产品的信息呈现，我们则需要对信息进行组织（结构化地梳理内容），并明确信息本身的属性。
范围层大致确定当前阶段产品会包括的特性；结构层中，我们则希望将分散的需求片段组合为一个网站整体的概念结构，“为用户设计结构化体验”。
结构层做的事情其实是，通过对功能或信息的呈现逻辑进行设计，从而帮助用户“快速上手网站”并得到想要的结果。
- 交互设计=> 思考如何呈现功能，包括路径和响应；
- 信息架构=> 思考如何组织信息，进行呈现、引导。
功能型产品的结构层设计主要受到传统软开行业的交互设计(interaction design) 的方法论影响。
交互设计曾经属于“界面设计”的范畴。阅读中可以不过于纠结如何区分。
内容方面的用户体验构建则主要通过信息架构(information architecture) 完成。很多相关学科都有关于信息架构的研究，重点在于组织管理、分类、顺序排列等内容呈现方式。
交互设计关注影响用户执行和完成任务的元素，信息架构关注向用户表达信息的元素。尽管两者各有侧重，但交互设计和信息架构都强调一个重点：确定呈现给用户的每个元素的模式patterns和顺序sequences。两者的本质都是，理解用户(包括工作方式、行为和思维方式)，然后通过设计良好的产品结构来保障用户体验。
交互设计
在交互设计中主要介绍了三部分内容：①交互设计是什么、为什么要做交互设计；②交互设计的重要工具——概念模型；③交互设计的重要组成——错误处理。
我个人对这一节的理解是，
①这里的交互设计以用户行为作为设计出发点，对功能架构(组织+响应)进行设计的领域；
②通过概念模型的运用，我们可以贴合用户的心智模型进行设计，减少用户的理解成本；
③对interaction的设计中，我们要关注通过响应的方式来为用户提供提示信息，从而引导用户完成正确路径。其中，错误处理就是交互设计的典型代表。
交互设计是什么、为什么要做交互设计
交互设计是什么：
交互设计关注于描述“可能的用户行为”，并定义“系统如何配合与响应”这些用户行为。是帮助软开从用户角度设计系统的新兴学科。
为什么(我们现在)要做交互设计：
在过去计算能力稀缺的背景下，“让软件正常运作”是最重要的事情。因此，(2000年之前的)传统程序员最关注软件的两个方面：软件的功能、软件的实现。
但是，在用户视角看来，单纯重视技术效率、忽视用户体验的软件往往是“复杂、混乱、难以使用的”。
举个例子，如果将“用户使用产品”比作“人和机器跳舞”，只重视技术实现的软件，就像是要求用户来适应自己的舞步、每次移动都缺少提示、对踩到对方不管不顾的舞伴。这对于用户来说是非常糟糕的体验，而想要顺利使用产品，用户就必须通过“计算机基础培训”来了解程序的运作。
随着时代的发展，算力的窘迫得到了缓解，这意味着“交互设计”将从兴奋需求变为基本需求。
概念模型
概念模型conceptual model，就是用户对于“交互组件如何工作”的理解。
互联网是现实世界的倒影，而人们在认知互联网世界时，也常常以熟悉的概念去类比——例如，同样是电子商务网站，在tb中商品信息的容器是“购物车”(推车)，用户进行添加(放入)和移除(拿出)操作；在1688中商品信息的容器是进货单(分类订货单)，用户进行编辑(修改订货)操作。
这里的“购物”与“进货”差异，在产品设计是运用了不同的概念模型，在用户身上就是心智模型不同。
关于“概念模型是什么”，可以参考概念模型与心智模型在交互设计里的应用。书里提到这个方法主要还是为了介绍“交互设计”，作者的本意不在写一个教程or手册。
概念模型的作用包括：
- 设计中，帮助我们在交互设计的过程中保持一致；
- 最终面向用户时，可以降低用户适应网站的难度。
- 根据用户对网站模式的想法挑选概念模型，这样设计出来的网站，其交互行为更符合用户的期望。
如何选择一个合适的概念模型：
- 一个熟悉的概念模型可以辅助用户理解。
- 选择概念模型时，可以参考现实世界的同类型活动；
- 如果其他网站已经让用户形成了熟悉的概念模型，建议沿用；
- 如果要提供一个用户不熟悉的概念模型，那么需要想清楚为什么这么做，并且保证新概念模型可以被用户理解和诠释。
- 概念模型服务于用户体验，避免死板地应用模型。
- 我们不需要明确地告知用户，我们的概念模型是什么。概念模型是帮助我们设计产品的工具，不是我们给用户增加的“培训内容”。
- 运用单个概念模型时，不要照搬现实世界的概念。网络和现实的特点不同，让网站整体看起来和某个实体一模一样反而会让用户感到困惑。
- 概念模型的应用可以是多维度灵活组成的。组件或者系统维度可以选用不同的概念模型，或者只在某一层应用一个概念模型。
总结：围绕选用概念模型的目的，灵活地应用这个方法
错误处理
系统应当如何响应用户的错误行为？如何避免用户继续犯错？——这写问题就是“用户错误”的处理，也是是交互设计的重要内容。
我想在这里强调一个认知(因为本人踩过这个坑TVT结合工作经验，个人感觉这很重要)：
作为PD，我们应该尽量弱化“用户的错误行为”这个概念，尽量减少将一个现象的原因定义为“用户的错误操作”，并通过“报错”来简单粗暴地处理问题。我希望我可以多想想，我们在这里给了用户什么引导、这个error背后是什么限制，即减少从产品的角度去评价用户，而是站在用户的视角去理解ta眼中的产品。
错误处理的方式主要包括：
- 预防：设计用户“不可能犯错”的系统，通过增加限制条件来避免异常的发生。方法的缺点是无法覆盖全部的错误处理；
例如通过强制挂P档的要求，避免汽车在其他档位发动的危险 - 改正：系统帮助用户查找错误，甚至自动纠正错误。缺点是可能反而影响用户的正常使用流程；
例如word、gmail等提供的自动修正功能(以及manychat的编辑提醒) - 恢复：针对做完后才发现的错误，系统为用户提供从错误中恢复的方式。缺点是无法覆盖所有错误；
例如典型的“撤销/undo”功能 - 警告：针对发生后无法恢复的功能，系统为用户提供大量警告，来试图预防其发生。缺点是用户可能会将其视为骚扰，也有可能忽视警告
例如大量的二次确定弹窗。
信息架构
在信息架构中主要介绍了三块内容：①信息架构是什么；②信息架构的设计——结构化内容+结构方法+组织原则；③信息架构的设计单位——语言和元数据。
我个人对这一节的理解是，
①信息架构的本质是通过信息的合理组织来保证用户可以高效率获取并使用信息；
②信息及架构的设计可以“范围从大到小”地分为三层（梳理覆盖面是否完整+确定信息的呈现结构+确定信息的关键属性，后两者即确定信息呈现的组织方式），有序地完成信息点的组织与呈现设计；
③信息最小的节点本身同样需要设计，包括规范化、可拓展性设计等。
由于②和③都是“how to”的内容，下文中将它们合并在一个标题下了。
信息架构是什么、为什么要做信息架构
软件与人之间的信息传达，它的本质和人与人之间一样，，这都是一种“沟通”。为了保证接收方可以理解并使用信息，我们必须要进行信息的选择与组织。信息架构，学术上研究的就是人们认知信息的过程。
尽管“信息架构”在模型中被划分到内容型产品的设计范畴，但不仅仅是以信息为驱动力的产品(例如公司网站)，信息架构对功能型产品(例如手机软件)也非常重要。在产品设计中，信息架构关注呈现给用户的信息是否合理且有意义。通过设计组织分类和导航的结构，信息架构帮助我们设计出有利于用户高效率检索并浏览内容的网站。
除了帮助用户找到信息外，我们有时候还希望通过网站结构来实现对用户的教育、通知或说服。
尽管作者常限定“在以内容为主的网站上”，但我认为这部分内容对当前的功能型产品同样适用且重要——①我认为当前的内容型产品与功能型产品间已经没有那么明显的分界了，②“功能型产品”的功能，同样也是信息。用户需要知道这个“功能”是什么、自己应当如何到达所在页面、它属于什么类目。
如何进行信息架构（信息的结构层）设计
信息架构的设计主要分以下四个部分展开：
Part A-梳理网站的分类体系：通过信息架构方法，构建反映产品战略的内容结构
Part B-节点与节点的排列结构：介绍信息呈现中常用的四种结构
Part C-节点的组织原则：根据用户需求选择截面，进行内容的分组与隐藏非关键属性信息
Part D-节点自身的规范：定义内容概念以及元数据(metadata)
上述的“四个部分”夹杂我个人的理解。我认为这四部分是逐步递进的：A通过梳理信息点的父子关系，我们可以获取一个架构树，再逐层梳理信息，确定整体的完整内容结构，B引入节点的概念来在单个层级或模块内设计，并介绍节点的常见结构类型，C在节点与内容结构的基础上逐层设计呈现，D则是具体与用户沟通时的信息表达方式（语言与元数据）的设计。经过这个流程，范围层所确定的内容特性得以转化为具体呈现给用户的结构
p.s.分类体系是产品内容的结构；分类体系≠导航or页面流程。分类体系内部是对产品内容的容纳以及分组，这部分是产品团队内部的认知，不一定会直接显示在用户面前
Part A-梳理网站的分类体系：通过信息架构方法，构建反映产品战略的内容结构
在范围层我们确定了“我们需要什么特性”，但这些特性像是一个个散落的点。通过梳理一个树状、有层级的网站内容的分类体系，我们可以将这些点“填充到空槽里”，得到一个完整地反映产品目标与用户需求的结构化内容。
信息架构方法主要有从上到下(top-down approach) 或 从下到上(bottom-up approach) 两种：
- 从上到下的架构方法是，从战略层出发，根据产品目标和用户需求，先梳理满足决策目标的广泛分类(主要分类)，再通过逻辑细分出次级分类，从而完成结构设计；
缺点是可能忽略内容的重要细节 - 从下而上的架构方法是，由范围层出发，根据当前确定的内容和功能需求，我们先将网站已有的资料进行初步的分组分类(次级分类)，再将分类后的内容归纳到更高一级的分类，从而构建出整体结构。
缺点是可能受到现有内容的局限；另外未来内容变动可能不够灵活
结合 top-down 和 bottom-up approach，我们可以尽可能完整地构建一个内容结构。
设计过程中需要注意：
- 好的结构的判断标准是边界是否足够清晰，而不是数量。
- 不需要给结构强行增加数量限制；(类似地，在功能结构中，)不要将“完成任务所需要的步骤”或者“用户找到特定页面所需要的点击数”作为网站设计的唯一评判依据。步骤的合理性与步骤间的延续性更重要。
- 需求是会随着时间发生变化的，而网站需要适应和成长。
- 网站的结构最好具有可拓展性。新内容可以作为现有结构的一部分，也可以作为一个完整的新部分加入。
- 必要情况下(如产品目标或用户需求发生变化)，我们需要再次审视网站的组织分类原则。例如，当内容大量增加时，网站可能需要从按日期分类转化为按主题分类。
Part B-节点与节点的排列结构：介绍信息呈现中常用的四种结构
信息架构设计中的基本单位是节点(node)，这里的“节点”是抽象的，它可大可小——设计网站整体时，我们可以将页面甚至模块作为节点；设计页面时，页面内的一个元素甚至一个数字也可以成为节点。
节点的常见结构包括层级结构、矩阵结构、自然结构、线性结构等等。
层级结构，也称树状结构或中心辐射结构，节点间存在父级/子级关系，子级从属于代表更广义类别的父节点，每一个节点都有一个父节点，直到整个结构的父节点(root)。
层级结构是用户最容易理解的概念，也是软件常用的结构。
矩阵结构，节点是两个或者更多的“维度”的交叉点，用户的需求通常可以和一个“轴”联系起来。
矩阵结构的缺点是，由于人脑无法很好地可视化超过三个维度的矩阵，矩阵结构可能不适合作为复杂信息的主要导航工具。
我认为矩阵结构可以理解为，我们取两个属性作为轴，将这两个轴平铺在平面上后，所有的信息就参照这两个轴被纳入一个矩阵；应用场景例如，tb分类区可以通过矩阵满足通过颜色和尺寸浏览的用户（ #TODO 之前找的case内容改版了，暂时没有案例图示）
自然结构，没有一致的模式，结构没有太强烈的分类概念。节点间逐一被链接，用户使用时无法明确感知到自己在结构中的哪个部分，更容易产生自由、探索的感觉。
自然结构的缺点是，用户难以通过同样的路径来寻找同样的内容。
以撒等roguelike游戏应该典型的是层级+自然结构，自然结构带来挑战+层级结构提供确定性并给予反馈，让玩家既感觉刺激，又不会在长线程中感到迷茫和沮丧。
个人有些困惑：
- “随机”在自然结构中是否必要？例如，塞尔达系列的开放世界是否属于自然结构（没有查到关于organic structure 的说明，因此暂时无法确定；我的倾向是，“是”+“不是自然结构”，因为内容虽然非线性但是是确定的）
- 另外如何区分自然结构和线性结构的区别？两者差异是在于随机性还是一维性？B站等内容应用的推荐flow属于自然结构还是线性结构？（个人倾向于“随机性”+“自然结构”，将无法预知无法回溯的特点作为自然结构和线性结构的区分点）
欢迎朋友们来评论区讨论~
线性结构：连贯的节点流程。
线性结构是最基本的信息结构类型，包括小规模的文章、专题，大规模的教学资料。
Part C-节点的组织原则：根据用户需求选择截面，进行内容的分类与非关键属性信息的隐藏
信息架构的设计过程中，我们需要考虑哪些节点需要编成一组管理，哪些节点则应该独立出现。这里作者将管理的规则定义为“组织原则/organizating principle”。
这部分内容主要为个人理解，私货较重、可能存在谬误。
我的理解是，organizating principle不是一个方法的定义，而是通过引入这个概念来辅助表述。学习的重点不在于概念本身。
换句话说，organizating principle它本身不是一条“准则”或者说“设计原则”，而是许多个运用于不同点的“principals”聚合起来的一个概念。
part C 这部分简单来说就是，识别出用户期望的重点信息，并配合结构隐藏非关键信息、帮助用户快速触达需要的信息点。
在理解“组织原则”的设计之前，我们需要先借用下图书馆学的术语“截面/facets”——反映用户需求的属性可以被提取为“截面”。
通过截面的使用，我们可以构建组织原则：
-
what is “截面”、怎么使用截面：
- 截面的本质是属性。截面和普通属性不同的点在于，截面是被选取出来、可以反映/满足用户的需求的属性。
例如，汽车可能有外观、价格、型号、重量等属性，对于普通消费者，“重量”这个属性不重要，截面一般是外观、价格等；但是对于跨境运输的从业人士，“重量”的影响非常大、需要作为截面，反而是汽车本身的能耗、引擎等信息不太重要。 - 设计中，我们需要识别用户期望，并根据识别出的“用户心目中至关重要的信息”进行截面以及信息结构的设计。
- 为什么需要设计截面，而不是支持用户按照任意属性作为截面使用：这个处理方法的问题在于，除非信息特别简单，否则用户反而会因为信息排序过滤的手段太多而无法找到需要的内容。
- 截面的设计基于战略层与范围层的结论——战略告诉我们“用户的需求是什么”，范围告诉我们“什么信息将满足用户的哪些需求”。
- 截面的本质是属性。截面和普通属性不同的点在于，截面是被选取出来、可以反映/满足用户的需求的属性。
-
what is 组织原则、如何设计组织原则：
- “组织原则”的意思就是，节点们是以什么样的方式被组织起来的。
- 分层设计：如上文所述，一个网站或产品，它是由很多个层级的信息组成的。每个层级内部所使用的组织原则可能是不同的，比如新闻网站最上层的类别可能是按类型做划分(政治科技娱乐体育)，但是下一层可能是按热度做排序(高热度消息在前)。
- 组织原则的设计同样取决于战略层。例如新闻网站可能以时间顺序作为它最显著的组织原则，因为用户的需求中最重要的就是信息的实时性，而实时性也可能是网站的立足之本。
- [纯个人理解]组织原则 = 截面的选择 * 结构类型的选择
Part D-最小节点的规范：定义内容概念以及元数据(metadata)
上述介绍的结构组织方法可以“为用户规划好他们在网站中走的路”；为了方便用户理解，我们还要对产品中的语言，也就是“如何命名描述、标签等网站使用的术语”进行设计。
通过产品语言的设计，我们可以
- “使用用户的语言”：在产品中使用企业内部的专业术语会增加用户的理解成本；
- “保持一致性”：语言的不一致会让用户感到困惑
控制产品语言(使用用户语言并保持一致性)的两个常用工具是受控词典(controlled vocabulary) 和 类词词典(thesaurus)。
受控词典是网站使用的一套反映用户语言的标准语言。受控词典的重点不在于词典的形式，而在于“反映用户语言”——我们需要与用户谈话、了解他们的沟通方式，从而建立一个让用户感到自然的命名原则。
受控词典一方面可以保障用户体验，另一方面也可以帮助企业内部沟通的内容一致性。
类词词典比受控词典更为精细——类词词典①不仅列出所使用词汇的清单，②还会提供与其对应的常用词汇作为参考，例如内部专用术语、速写语、俚语、缩写语等，③另外还可能包含词汇间的类型关系，提供更广义、更狭义以及相关词汇的建议。
类词词典通过记录词与词的关系，可以帮助我们对内容概念的范围有更完整的印象，从而帮助我们再次确认结构方法。
受控词典或类词词典对于建立包含 元数据（MetaData） 的系统很有帮助：
- 梳理词典的过程中，我们可以提前梳理出元数据，以便设计一个灵活可拓展的信息架构；
- 词典可以保证概念的统一性，便于后续的数据打通，从而让元数据系统的价值最大化。
好的元数据和类词词典(禁用词、首选词)甚至可以优化搜索结果。
团队角色和流程
在产品设计的过程中，我们应当有意识地进行架构的梳理和设计。
- “由谁来负责”不是关键，是否要专人设计、由谁承担架构设计的责任，这取决于企业与项目的需求。架构设计可以交给某个人来做——可能是全职负责架构问题的人，ta可能被称作交互设计师、信息架构师、用户体验设计师；可能是内容型产品中的内容建设成员；可能是技术导向企业中的技术项目负责人。
- 重点在于，我们需要产品应当有意识地规划架构，从而保证①减少维护工作量，②满足用户需求和产品所有者的需求(战略需求)。
架构的描述形式不局限于文字文档。文字可以简单有效地记录概况；但对于复杂的网站结构，文字的传达效率并不高；
报表、数据库等可以更好地表述复杂结构的细微差异；
信息架构或交互设计的常用载体是示意图——架构图可以视觉化地、高效地呈现结构，让“分支、群组、组件之间的联系”一目了然。
针对架构图的设计，我们有一些设计建议：
1. 内容：架构图的核心意义在于，记录概念关系——信息中的分组与独立关系，或交互中的步骤配合关系。
2. 粒度：架构图最重要的是“讲清楚重要信息”，不需要、也不建议详尽到网站每一页的每一个链接。根据项目复杂度的不同，结构层描述的粒度也有所差别（从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况）。
作者结合自己的经验，提供了描述的工具视觉词典(visual vocabulary)。
简单浏览了一下，看起来是一种自定义的UML规则。