Abstract：李卫东老师的 Web 信息架构课，李老师是一位教学严谨且非常负责的好老师。这门课非常系统地讲解了information Architechture以及以之为基点的互联网产品设计，让我受益良多 ~
Part1 原理篇
Chapter1 Web信息架构（Information Architechture）
洞察 + 灵性
APP用户体验存在的问题（易用性，舒适度）
- 查找信息困难
- 信息超载
- 信息异质
- 搜索问题
- 成本问题
信息架构（Information Architechture）
- 易理解性：使信息易于理解 ——>使用通俗易懂的语言
- 化繁为简：将复杂的信息简单地传达给用户 ——>寻找合适的方法来组织信息
类比
- 构造——建筑——城镇
- 页面——APP/Web——互联网
速度分层（依据变化速度来分层的思维方法）
产品架构的三个层次
- 业务架构：产品概念设计 应用模式
- 信息架构：产品详细设计 设计文档
- 技术架构：产品实现设计 程序代码
产品构成的三个要素
- 视觉传达
- 信息架构
- 技术平台
信息架构 —（可视化）—> 界面设计
隐藏层——>表现层
广义IA与狭义IA
互联网整体的信息架构
- Web 信息架构设计的层级
- 互联网整体的 IA：互联网中各站点互联互通
- 企业级 IA
- 网站 IA：网站结构，导航，标签
- 页面中的 IA（页面结构设计）
- 智能终端的 IA
Chapter2 信息架构有哪些内容
组织系统，导航系统，标识系统，搜索系统
组织系统
深度与广度的平衡
层级式 & 辐射式
导航系统
层级之间如何链接
标识系统
Labeling Systems
- 为内容确定名称、描述等一系列标识方案
搜索系统
WEB信息框架的完整结构
- 静态框架
- 数据对象模型：数据对象是什么
- 数据显示模型：如何显示数据；组织系统，导航系统，标识系统，搜索系统
- 动态框架
- 数据处理模型：如何动态处理数据
Chapter3 如何设计信息架构
微信之前版本的搜索功能的导航系统设计得不科学（用关键词搜索公众号，关注后想再继续看那个公众号列表）
IA设计需要具备的知识基础
Who Design IA：系统分析师，系统设计师
IA 需要的知识能力
- 知识：社会学，商业战略，人类工程学，认知科学，HCI，页面设计
- 能力：抽象理解能力，组织协调能力
IA 设计的理念、系统和模式
- 理念
- 复杂系统：
- 用户：受众，任务，需求，信息搜索行为，体验
- 情境：用户使用场景
- 内容：内容对象、数量、类型，现存架构
- 无形的工作：信息架构，操作界面
- 知识网络
- 信息搜寻行为
信息架构的用户思维
IA 设计原则
- 简洁性：信息内容化繁为简
- 习惯性：符合用户操作习惯（eg. 上下左右滑动）
- 可理解性：用户永远不会出错
- 高效性：减少用户操作量
- 引导性：让用户能确定自己当前所在的位置
UCD（User Centered Design）
- 以用户为中心
- 你永远无法满足所有人
- 用户永远是对的，但也不能完全听信用户的言语，用户说的需求不一定是真需求
- 妥善管理用户的需求变化
- 把握用户需求的优先级
确定需求优先级的方法：MoSCow
- 必须有（Must Have）
- 应该有（Should Have）
- 可以有（Could Have）
- 这次不会有（Wont have this time）：当现有产品已经可以打败绝大多数对手，就没必要把能想到的好 功能全部推出，否则容易“黔驴技穷”，所以需要有所保留，持续不断给用户新鲜感
以用户为中心的难点
- 用户目标与我的目标不一致：鱼和熊掌可以兼得，但不是马上
- 用户的关注点与我的关注点不一样
- 用户和用户不一样
Web信息架构的建构
- 情境分析+用户分析：应用模式
- ——>数据对象建模：数据内容结构，用例图
- ——>数据显示建模：四大系统
- ——>数据处理建模：功能逻辑模型，活动图，序列图
区分：
- 页面层次结构图
- 功能结构图
Chapter4 面向对象的方法——用户建模分析
当你面对的应用很复杂，深入了解面向对象的思想，可以提升你的抽象能力和分类能力，用这种方法描绘的网站结构图也更容易被开发团队所理解。——张小龙
面向对象的方法
面向对象的用例视图
- 详细的用例归约相当于详细的产品设计文档
获取需求——>建立用户用例图
活字印刷，面向对象
可维护性：要改只需改特定的字
- 可复用性：每个字都可以重复使用
- 可扩展性
- 灵活性：可灵活排列
设计产品要考虑面对需求的易变性的程序设计的可拓展性、可复用性
面向对象分析（OOA）理论概述
面向对象分析（OOA，ObjectedOriented Analysis）
- 作用：需求分析
- 关键概念：
- 问题域：应用领域
- 系统边界：能做什么不能做什么的分界线
- 参与者：与系统进行交互的任何事物
- 系统分析面临的主要问题
- 问题域与系统责任
- 交流
- 需求的不断变化
- 复用的要求
- OOA方法的主要原则
- 抽象，封装，继承，分类，聚合，关联
- 消息通讯，粒度控制，行为分析
面向对象分析建模原理
需求分析阶段 + 系统分析阶段
1.需求分析阶段
- 用例模型：描述功能需求；包括：业务用例，业务场景，系统用例，用例归约
2.系统分析阶段
- 根据用例创建分析模型：
- 使用UML图描述；采用分析类，是高层次的系统视图
- 包括：静态视图（描述事物的静态结构，包括类图、包图），动态视图（描述事物的动态行为，包括序列图、状态图、协作图、活动图等）
建模之用例图（UserCaseDiagram）
- 包括的要素：参与者，用例，关联，系统边界
- 参与者：以某种方式参与用例的执行过程；触发
- 分类：发起参与者；参加参与者（分为主要参与者+次要参与者）
- 用例：外部可见的系统功能单元；定义连贯的行为；包含它做必需的所有行为（执行用例的主线次序，标准行为的不同变形，一般行为下的所有异常情况和预期反应）
- 识别用例：从参与者开始分析
- Q：
- 参与者希望系统提供什么功能
- 系统是否存储和检索信息，如果是，由哪个参与者触发
- 当系统改变状态时，是否通知参与者
- 是否存在影响系统的外部事件
- 哪个参与者通知系统这些事件
- 用例粒度：功能单元的大小和数量
- 用例间关系：包含关系，扩展关系，泛化关系
- 包含关系：将包含用例的事件流插入到基本用例中（必然发生）
- 扩展关系：（可能发生）
- Q：
1 | - **泛化关系（继承）**：将多个用例的共性抽象为**父用例**，而其他用例作为泛化关系中的子用例；eg1.文字阅后即焚、音频阅后即焚、视频阅后即焚三个子用例的共同父用例是阅后即焚；eg2.验证登录是父用例，其子用例有账户密码验证、人脸识别验证、指纹识别、声纹识别 ... |
- 系统边界：系统之间的界限
- 系统的组合递归进化性，系统模块化（划分）
用例模型设计实例
1.准备工作：
- 了解问题领域（需求）
- 确定参与者：业主，业务提出者，业务管理者，业务执行者，第三方，用户
- 发现业务参与者
2.需求分析：
- 获取业务用例
- 建立业务模型
3.系统分析：
- 建立系统用例：从业务用例扩展而来
- 用例归约：
- 简要说明：简要介绍用例的作用和目的
- 事件流：基本流（用例正常运行时的场景） + 备选流（描述异常或偶然情况）
- 基本路径
- 可选路径
- 用例场景：
- 特殊需求：描述与该用例相关的非功能性需求
- 前置条件：执行用例前系统必须所处的状态
- 后置条件：执行用例前系统可能所处的状态
业务用例实例：
系统用例实例：
用例说明实例：
面向对象分析——静态视图类图
静态视图是在用例图的基础上设计！
类图：
- 描述类、接口、协作和它们之间关系的集合体
- 静态结构，展示类与类之间的关系
- 类图七元素：类、接口、协作、依赖关系、泛化关系、关联关系、实现关系
- 在类图基础上，可使用状态图、协作图、组件图、配置图等进一步描述系统特性
对象图：
- 类图的实例
类图与对象图的区别：
类图的组成：
1.类：
- 包括：物理实体，逻辑事物，商业事物，应用事物，行为事物，纯粹概念性的事物 etc.
- 描述类：名称，属性，操作（设计依据：用例图），职责，约束，注释
2.接口：
- 含义：在没有给出对象的实现和状态的情况下对对象行为的描述
3.类之间的关系：
依赖关系：
- 类之间的使用关系；指两个或多个模型元素之间语义上的关系，被依赖元素的变化会要求或指示依赖元素的改变
- 用虚线箭头表示，箭头上可加关键词指明依赖的种类
- 依赖种类：use，Access …
泛化关系：类间“一般——特殊关系”，父类与子类
关联关系：二元关联，三元关联
- 重数：表示有多少个对象与对方对象相连接，如“0..1”表示0或1
- 有序关联与导航
- 使用箭头
- 聚合关系：关联关系的一种强化，需满足：
- 表示整体和部分的关系（所属）
- 部分可被多个整体同时共享
- 整体消失，部分实例依然存在
- 如班级——学生
- 组合关系：是进一步强化的聚合关系
- 必须同时存在，且整体不能共享部分的实例，比如活人<——跳动的心脏
- 关联的约束：各种模型元素的一种语义条件或限制，一条约束只能应用于同一类元素
- 用一对花括号括起来，eg.{ordered}，括号里为约束内容
- 对泛化的约束：complete；disjoint；incomplete；overlapping
- 关联的约束：implicit（概念性关联，但在模型精化时不再关联）；ordered（信息显示有序）；changeable（关系是可变、可修改的）；addonly（可在任意时刻增加新的链接）；frozen（冻结已创建的对象，不能再修改）；xor（或约束，当前时刻只有一个当前关联实例）
建立静态模型：
- 分析类：分析类是业务需求向系统设计转化过程中最重要的元素；分析类代表“系统中具备职责和行为的事物”；包括边界类、控制类、实体类
- 边界类：用于对系统外部环境与其内部运作之间的交互进行建模的类；包括：用户窗口、通信协议、打印机接口、传感器、终端等
- 控制类：对一个或几个用例所特有的控制行为进行建模；控制对象通常控制其他对象，因此他们的行为具有协调性质
- 实体类：对必须存储的信息和相关行为建模的类；源于业务模型中的业务实体
- 包图
面向对象分析：动态视图
- 描述事物的动态行为，在静态视图的基础上
- 序列图、协作图、状态图、活动图
- 序列图：描述系统中各个对象按照时间顺序的交互过程
- 构成：对象，生命线，激活，消息
- 注意：边界类发送消息到控制类，控制类发送信息到实体类，然后实体类返回消息到控制类，控制类返回消息到边界类
- 图中的序号是对消息的编号
- 协作图：描述控制类内部的实现逻辑
- 构成：对象，消息，链
- 强调对象之间的关系
- 图中的序号是对消息的编号
- 状态图：通过建立类对象的生存周期模型来描述对象随时间变化的动态行为，描述事件如何引起对象的状态变迁
- 构成：状态，触发事件
- 状态转换：两状态之间的关系
- 状态转换的组成：源状态；事件触发；监护条件（guard Condition）；动作；目标状态
- 状态内部构成：进入/退出动作；活动（在一个状态内执行的处理过程）；内部转换（响应）；子状态（状态间的包含关系）
- 活动图：即流程图，描述工作流
- 要素：活动，活动之间的转移，判断，保证条件，同步条
- 活动图——泳道：
- 活动图——对象流：可显示对象的角色、状态、属性值的改变
- 分叉与分支的区别：分叉——子路径是都需要做的，分支——可选路径、选了一个就不选另一个
静态模型设计实例
1.提取业务对象
2.对象的属性设计
3.基本操作设计
4.关系设计
- 关联关系设计
业务对象模型：一定要模块化设计
Chapter5 信息架构之内容分析
概述
内容分析的任务——建立组织体系
五帽架法则：按不同标准对同一集合进行分类（类别、时间、位置、层次、名称字母顺序）
内容模型化：
- 模型化：分析整理内容间的语义关系，本质是建立叙词表
- 语义关系：等价，等级 ，相关
-
叙词表 refer：http://cdc.tencent.com/2011/06/13/%E5%8F%99%E8%AF%8D%E8%A1%A8/
Chapter6 情景分析
目标设定
目标设定：明确产品能为用户提供什么价值
项目蓝图：项目的长远设计
现状分析
修改方案：
- 启发式评估
- 可用性测试
- 日志分析
- 标杆分析：竞品分析
Chapter7 网站结构设计
网站结构设计的任务：
- 用户动线设计
- 网站内信息的分类整理：层级型，分面分类型
- 目录主页，列表页面，详细页面等页面形式的定义
- 内容量（页面数量）的确定
网站结构模式：
- 层级型
- 分面分类型：根据信息的各个侧面的性质来识别和分类信息；适合用户根据自身的观点来检索信息
- web 型：各种信息通过超链接平等连接
- 辐射型
- 直线型
- 综合型：融合多种模式
视觉辞典：
- 连接节点
Chapter8 界面设计
页面类型：
- 门户页面
- 列表页面：文本，缩略图，缩略图+文本
- 内容页面
- 功能页面
设计流程：
- 交互流程设计
- 风格定位：色彩
- 功能 icon 设计
- 界面视觉的整体优化
Chapter8 导航系统设计
文字导航条 vs 图片导航条
浏览器导航压力测试方法：随机进入任一页面，测试能否进入其他任何页面
设计原则：
- 强化信息层次：使用户对内容组织方式越来越熟悉
- 便捷性，直接可达性
- 避免信息冗余
分类 & 索引：满足不同需求
Chapter9 标签系统设计
标签：网站内的索引文本
标签设计注意事项：
- 避免专用、网络流行语、情景式表达
- 注重词语粒度：粒度太大容易模糊用户的行为导向（比如美女定义“漂亮”没有任何意义，关键是如何漂亮，可以使用“细眉”、“大眼”…）
- 避免使用动词：名词和形容词更合适，因为动作描述过于精准反而不利于内容组织
