品牌 VI 骨架 v0.3 快照
本页固定保存补入生成过程后的内容。当前工作模型见骨架研究稿。
解决什么问题：明确品牌 VI 从哪些前提出发、需要设计和交付什么，并通过不同案例持续修订组织这些内容的骨架。
当前结论与使用范围
当前版本为 v0.3，补入设计生成过程的研究稿。VI 的工作目标是建立一套让品牌在不同场景中被识别、被理解，并能由团队持续执行的视觉系统。六个工作模块组织需要处理和交付的内容；切入点与生成顺序另行说明设计如何探索和生长。品牌关系与使用条件、验证、运行维护三项关系贯穿工作。模块数量、职责与关系都可以继续改变。
置信度：★★★☆☆（综合推断）。工作模块用于组织设计任务和交付依赖。样本中的成品目录、规范条款与作者说明分别记录；实际设计过程需要另有过程证据。第一轮新增六个品牌样本，支持以下修订，尚未证明通用完整性或市场识别效果。
六个工作模块
| 编号 | 工作模块 | 核心问题 | 应留下的答卷 |
|---|---|---|---|
| VI1 | 品牌定义与设计任务 | 我们是谁，为谁服务，此次设计需要改变什么？ | 设计简报、品牌关系、关键触点、项目范围与专项责任 |
| VI2 | 视觉方向与设计原则 | 品牌应该怎样被感受到，这种感受如何落实？ | 核心概念、方向、原则及各场景的表达模式 |
| VI3 | 识别资产与适用变体 | 哪些资产形成识别，何时选择哪一版？ | 标志、字体、颜色、图形、图像；版本、替代项及适用条件 |
| VI4 | 组合 变化与行为规则 | 在什么条件下如何组合、生成和改变内容？ | 版式、层级、比例、选择分支、内容转换、时间与行为规则 |
| VI5 | 场景应用与生产适配 | 在真实内容、设备、尺寸、材料和现场条件下怎样实现？ | 应用与模板、标准及替代方案、生产适配与确认记录 |
| VI6 | 规范 资产与模板交付 | 别人怎样获得并使用正确版本的文件和规则？ | 规范、源文件、素材、模板、规格、许可范围与交接说明 |
VI1–VI6 是本研究的局部编号；v0.1 快照中的 L1–L6 与之按序对应。它们与项目的建模、设计、实现、运营、演化五阶段分别命名和使用。
flowchart TD
A["品牌定义 用户与使用场景"] --> B["视觉方向与设计原则"]
B --> C["识别资产与适用变体"]
B --> D["组合 变化与行为规则"]
C -->|形式探索提炼原则| B
D -->|生成试验提炼原则| B
C <--> D
C --> E["场景应用与生产适配"]
D --> E
E -->|验证并修正| C
E -->|验证并修正| D
E -->|场景试作修正方向| B
E --> F["规范 资产与模板交付"]
G["品牌关系与使用条件"] -.选择.-> C
G -.选择.-> D
H["贯穿模块的验证与运行维护"] -.检查.-> C
H -.检查.-> E
F -->|新场景与运行反馈| A图表示模块之间需要核对的关系，箭头用于查找影响范围。视觉方向与原则可以先提出，也可以从图形、内容或材料试作中提炼。基础资产与规则共同探索；真实生产条件可以要求更换资产版本、删减信息或改变布局。实际探索顺序另见生成过程，验证与运行维护按下表贯穿各模块。
内容覆盖与生成过程
六模块帮助检查答卷是否覆盖任务；设计生成过程帮助说明主要决定的理由。工作可以从品牌主张、已有识别、字体构造、产品行为、材料或典型场景进入。各入口都需要连接明确的品牌任务，再提出可执行的操作，在真实内容和使用条件中试作。
当前提出的过程是：任务与判断条件 → 具体依据与候选入口 → 操作概念与形式假设 → 场景试作与比较 → 固定项、变量与规则 → 新场景检验 → 规范交付。试作结果可以要求修改入口或概念；字体、色彩、图像等可以由直接构造、共同目标、协调适配或场景条件分别确定。
这是本项目的工作假设。作者明确的生成关系、局部制作先后与未知部分，分别保存在过程案例记录。手册目录继续用于研究覆盖与执行，不承担实际创作顺序的证明。
三项贯穿关系
| 关系 | 要保留什么 | 案例依据 |
|---|---|---|
| 品牌关系与使用条件 | 谁主导，给谁看，品牌已被建立到什么程度，属于自有还是外部场景，何种尺寸、媒介与语言 | 微软第 4、51 页；麦当劳第 4 页；Spotify B 第 6 页 |
| 验证 | 输入是否明确，原则是否能落实，资产是否可读，规则是否支持内容变化，生产后外观是否符合目标，交接是否可执行 | 微软第 13、62–68 页；可口可乐第 49、56 页；Spotify B 第 15 页 |
| 运行维护 | 谁维护资产版本、处理例外与使用权限；谁确认制作；实体物料由谁检查和替换；反馈如何改变设计 | 微软第 51、88–89 页；FedEx 第 11–14 页 |
页码为第一轮样本的物理 PDF 页码，身份和范围见案例检验。这些关系不能只归到某个末端步骤：它们会提前决定可用资产与规则。运行机制的深度随团队、媒介和项目责任确定。
设计交付、制作实施和长期运行分别留责任与产物。设计团队可以交出规范和确认方法，生产团队落实打样、采购与安装，品牌或运营负责人处理版本、例外与维护；实际分工在 VI1 约定，具体角色可以兼任。
设计的五项输入
| 输入 | 要回答的问题 | 留下什么 |
|---|---|---|
| 业务与价值 | 品牌提供什么，用户为什么选择它？ | 定位与价值主张 |
| 用户与场景 | 谁在什么情境下接触品牌，需要看懂什么？ | 用户与关键场景 |
| 品牌关系 | 企业、产品、子品牌、活动、合作方怎样关联？ | 品牌架构与命名关系 |
| 现有认知 | 哪些识别资产要保留，哪些造成混淆？ | 现状、竞争参照、保留与调整目标 |
| 执行条件 | 涉及哪些语言、尺寸、媒介、工艺、预算和团队？ | 约束与范围 |
这些输入可以来自现有战略，也可以在项目早期补齐。品牌战略、命名、包装结构、空间施工、数字产品交互等专项的责任和交付深度，分别写进范围。
需要设计的内容
| 模块 | 内容与规则 |
|---|---|
| 标志系统 | 图形、文字、组合、横竖版、单色、反白、小尺寸版本；安全空间、最小尺寸、背景适配 |
| 品牌关系的视觉表达 | 企业与产品、子品牌、项目、背书、联名与合作方的命名呈现和排列 |
| 色彩系统 | 主色、辅助色、中性色与功能角色；组合、面积关系、屏幕与印刷规格、材料表现 |
| 字体与文字层级 | 中英文、字重、标题、正文、数字、注释、行距、对齐、替代字体、多语言 |
| 辅助图形与图案 | 形状、线条、纹样、容器、裁切、重复、生成方法与变化范围 |
| 摄影与图像语言 | 内容选择、构图、人物与产品呈现、光线、色调、裁切、文字叠加 |
| 插画与图标 | 造型、线宽、细节、透视、颜色、组合与所需资产库 |
| 版式与信息组织 | 网格、边距、对齐、比例、留白、阅读顺序、图文关系、尺寸适配 |
| 动态图形 | 有相关场景时展开标志出现、转场、节奏、字幕、视频包装 |
| 材料与空间表达 | 有相关场景时展开纸张、表面、工艺、标识、导视、环境图形 |
资产及其变体在 VI3 记录；选择、组合、内容转换和行为规则在 VI4 记录；实际媒介、内容与生产实现进入 VI5。动态图形的基础形态、变化规则与实际播放分别关联这些模块。声音、语气、命名、交互等专项，在 VI1 写清接口与范围，再记录它们触发的视觉条件。
每项资产怎样记录
每项资产至少写清识别任务、文件与版本、适用条件、替代项、对应规则和验证依据。颜色代码、尺寸或标准形态需要与目标外观和制作条件一起保存。
每条规则怎样记录
规则采用“条件 → 选择或操作 → 目标 → 验证 → 例外与责任”的记录方式。这是本项目对样本的综合归纳：条件可以是主导品牌、内外环境、内容长度、尺寸或输出媒介；操作可以是选版本、改变强度、裁切、删减信息或显隐内容。
| 样本中的条件 | 样本中的操作 | 研究上需要保留的关系 |
|---|---|---|
| 微软标志用于大尺寸 | 改用无 ink traps 的 display artwork | 尺寸决定资产版本，而非只缩放 |
| 麦当劳进入品牌自有空间 | Archery 表达更加含蓄 | 环境决定表达强度 |
| 可口可乐口味方块用于小尺寸 | 不要求附口味 Disc lock-up | 可读性决定信息取舍 |
| Spotify 实际设备出现颜色偏差 | 逐案测试并选择备用绿色 | 输出条件反馈资产参数 |
| Dropbox 平面要隐藏或揭示内容 | 采用缩放，且不与其他移动合用 | 行为目的决定时间中的操作约束 |
这些是历史样本中的条件规则，用于理解设计关系；各品牌现行规范需另行核对。
从接触任务确定应用范围
| 接触任务 | 常见应用 |
|---|---|
| 发现品牌 | 招牌、广告、社交媒体、活动视觉 |
| 理解品牌 | 网站、介绍、宣传册、产品资料、演示文稿 |
| 选择与交易 | 商品页面、菜单、价格信息、包装、购买界面 |
| 使用与服务 | 产品标识、说明书、服务指引、导视、售后资料 |
| 企业日常协作 | 名片、邮件签名、文档、报告、工牌、内部沟通 |
| 合作与扩张 | 联名、渠道物料、子项目、地域与语言版本 |
应用清单依据业务选择。每个应用记录对象、任务、内容、媒介、尺寸、生产方式、使用频率及执行者，还要注明自有或外部环境、长期或临时用途，以及评估的是单件、系列还是整体体验，进而确定需要交付完整设计、模板还是专项规范。
如何判断答卷交齐
| 检查 | 判断方式 | 留下的依据 |
|---|---|---|
| 有依据 | 主要决定能连接品牌任务与使用场景 | 决策及来源 |
| 有识别 | 多种应用形成共同特征，并与竞争参照区分 | 对照样本与观察记录 |
| 有语法 | 固定要素、变化范围、组合方法清楚 | 规则、正例与错误示例 |
| 能使用 | 真实长短内容、小尺寸、不同背景和目标媒介下有效 | 目标条件的应用与制作记录 |
| 能扩展 | 另一位设计师能依规则完成未展示的新应用 | 扩展试作与问题记录 |
| 能交接 | 文件、模板、规格、许可范围与版本说明齐全 | 资产清单与交接记录 |
最终设计交付分为设计说明、视觉规范、资产与模板、验证与交接记录四包。各模块的验证依据逐步形成后进入交付记录；制作确认、采购安装及后续维护分别按专项责任执行。
第一轮修订
三个方向共抽读微软、FedEx、可口可乐、麦当劳、Spotify、Dropbox 六个品牌。重复文件、同源不同封装及 Spotify 两版都按品牌与样本版本分别记录。
| v0.1 的安排 | v0.2 的修改 | 触发证据 |
|---|---|---|
| 基础识别要素 | 增加适用变体、替代项与选择条件 | 微软 13；FedEx 4、6；可口可乐 40、56 |
| 组合与扩展规则 | 明确选择条件、表达模式、内容转换、时间与行为 | 麦当劳 4–5；Spotify B 6、16；Dropbox 10、16、18–19 |
| 关键场景应用 | 增加生产适配、标准与替代方案，以及对资产和规则的反馈 | FedEx 21、23–24；可口可乐 49 |
| 执行交付与维护 | 聚焦可交接的规范、资产、模板；制作与运行维护另列贯穿职责 | 微软 88–89；FedEx 11–14 |
| 应用之后验证 | 将验证前移并贯穿工作模块 | 微软 13、62；Spotify B 15；可口可乐 56 |
六个工作模块保留为覆盖表；实际工作按条件依赖网往返。本轮暂未增加品牌架构独立层或动态独立层，因为关系与行为同时影响多个模块。未来案例若揭示独立的任务和产物，仍可拆分。
第二轮修订
v0.3 补入切入点、概念转换、场景试作、规则提炼和回返过程，分别记录逻辑依据、实际制作顺序及规范阅读顺序。新增麦当劳、MIT Media Lab、Dropbox、Spotify 与 Fedrigoni 的设计者说明；企业统一、局部字标制作、网站实施与材料样品工具分别保留范围。此前模块内容见v0.2 快照。
初始案例依据
| 样本 | 支持的初始观察 | 局部位置 |
|---|---|---|
| 华为 Visual Identity Guidelines V2.0 | 品牌属性、基础要素及广告、数字、出版、导视等应用相互连接 | PDF 第 3、7、37、87、109、128 页 |
| 奥迪品牌手册 1.0 | 品牌模型进入形象、运营与管理 | PDF 第 15、39、40、56、57 页 |
| Mastercard Foundation 2023 年 6 月版 4.3 | 项目与合作关系先形成视觉层级，再展开要素和应用 | PDF 第 11–18、44、53、69、74 页 |
| NASA Graphics Standards Manual 本地样本 | 统一识别进入出版物、导视、车辆等实际使用条件 | PDF 第 2、3、27、30、45、57 页 |
| IBM Design Language | 设计原则、要素与网格、布局、动画、资产组织共同构成设计体系 | 官方设计语言与布局页面 |
本地样本的完整来源与查阅范围见研究记录。样本范围支持初始分类，完整性和通用性继续接受其他案例检验。
骨架如何变化
抽读先记录案例本身的目录、规则及独特问题，再映射六层。无法映射的内容单独保留；能够硬塞进某层但失去重要关系的内容同样记为挑战。
每个修订必须记录：触发案例、具体页码或官方出处、原有安排、修改后的安排、影响范围与未解决的问题。案例支持某条分类，只表示分类获得一个可核对的实例。
优先检查以下问题：
- 品牌架构是否应独立成层，还是作为贯穿多层的关系？
- 动态、交互、材料与空间是否能充分放入要素和应用？
- 验证是否应贯穿各层，而不只集中于最终交付？
- 已区分的设计交付、制作实施和运行维护，是否足以表达不同规模团队的责任？
- 不同行业的应用差异，是局部模块变化还是骨架变化？
常见误区
- 直接把手册目录当成实际创作顺序。分别记录成品组织、作者过程说明与本项目反推。
- 先套六层再挑支持例子。先忠实记录案例，再同时寻找支持和挑战。
- 将合作伙伴标志指南当作完整企业 VI。先确认文件对象、范围、版本与身份。
- 以应用数量判断完整性。应用覆盖应对应真实接触任务和生产条件。
- 用抽样覆盖证明市场识别效果。覆盖、制作可行性、用户识别分别需要相应依据。
关键洞察
置信度：★★★☆☆（综合推断）。VI 骨架的价值在于保留设计任务、规则、应用和执行之间的依赖；案例中的新问题可以改变它的层次与关系。