文件用途：回答老板的原话——「每个模块里面感觉都有很多逻辑，我对里面的按钮、每个模块的设计还是很模糊，不能把整个产品串起来，不知道该实现什么，也不知道每个模块对应有哪些数据需要体现。一般这种软件设计，他们是怎么把这些东西捋清楚的？怎么保证既能满足功能需求，又能在 UI 上体现出来？」 这份文件里，唯一需要动手的东西是 E 部分。 A–D 是让老板听得懂别人在说什么（词汇、书、标准），E 是可以直接打印出来、一个模块一张、填完就开发的东西。 核实说明：书名、作者、出版方、标准状态与链接均已用 web 搜索 / 抓取官方页面核实（见文末「核实状态」）。全文不写 ISBN。凡是没核实到的，直接写「未核实」，不猜。
---
| 老板的原话 | 真正的问题 | 专业名字 | 我们该用的工具 | 产出物长什么样 |
|---|---|---|---|---|
| 「不能把整个产品串起来」 | 我们缺一张产品里到底有哪几个「东西」的清单。不是页面清单，是对象清单 | Object-Oriented UX（OOUX）／Information Architecture（信息架构） | 对象地图（Object Map） + 页面互链表 | 一张表：10 个对象 × 各自属性 × 出现在哪几个模块 |
| 「不知道每个模块对应有哪些数据需要体现」 | 我们缺一张字段台账：每个模块上每个数字/文字从哪来、谁写、空了怎么办 | Information Design ／ Data Dictionary（数据字典） | 数据字典 + CRUD 矩阵 | 一张表：模块 × 字段 × 来源 × 读写 × 空态 |
| 「不知道要实现什么」 | 我们缺需求编号，所以「这个按钮为谁存在」没处挂 | Requirements Engineering（需求工程） | 需求可追溯矩阵（Traceability Matrix） | 一张表：需求编号 → 模块 → 字段 → 元素 ID → 验收 |
| 「按钮、每个模块的设计还是很模糊」 | 每个模块没有回答固定的问题，所以每次都要重新想一遍 | Interaction Design ／ 设计 QA | 每个模块 12 问清单（本文件 E 部分） | 一个模块一张表，填完即开发 |
| 「既能满足功能需求，又能在 UI 上体现出来」 | 需求到界面之间少了一条可检查的链 | Requirements → Design → Verification 链路 | 上面三张表串成一条链 | 见 F 部分：一条链，5 个环节，每个环节可查 |
一句话结论：行业里的大公司不是靠"想得清楚"，是靠三张表 + 一张问题清单。三张表 = 对象地图、数据字典、可追溯矩阵；一张清单 = 每个模块固定的 12 个问题。这三张表我们已经有了一张半（Launchpad-界面元素数据字典.md 有 501 行元素，属于数据字典的雏形；其余两张没有），12 问清单完全没有。
---
| 术语 | 一句话定义 | 它回答的问题 | 我们产品里对应什么 | 出处 |
|---|---|---|---|---|
| Information Architecture（IA，信息架构） | 内容的组织、命名、结构、导航方式 | 「一个东西放在哪、叫什么、怎么找到」 | 5 个页面 + 1 落地页的划分、顶部导航、项目页左右双栏、锚点导航（P146–P152）、页面互链（P44） | Rosenfeld / Morville / Arango《Information Architecture: for the Web and Beyond》；NN/g 有专文区分 IA 与导航 |
| Information Design（信息设计） | 把数据/信息呈现得让人读得懂、比较得了、不出错 | 「这个数字怎么显示才对」 | 数值格式（$14.4M、+12.6%、$0.001）、五条语义渐变（P25）、FDV/毕业线/押金进度条、表格列序 | Tidwell《Designing Interfaces》；Wroblewski《Web Form Design》 |
| Interaction Design（IxD，交互设计） | 用户与系统之间动作与反馈的设计 | 「点了会发生什么，出错怎么办」 | 「连接」按钮（P157）、「签名并发币」（P386）、Buy/Sell 面板（R3）、claim 流程、四态（空/加载/错/无权限） | Cooper《About Face》 |
| Requirements Engineering（RE，需求工程） | 把想要的东西写成可验证、可追溯的要求 | 「这条需求怎么算做到了」 | 我们目前基本没有（这是最大的缺口）：没有需求编号、没有验收标准 | ISO/IEC/IEEE 29148-2018；IEEE 1016-2009 |
| UX Content Strategy（内容策略） | 界面上的每一句话谁负责、什么时候写、写什么规则 | 「这句文案谁定、空的时候显示什么」 | 空态文案（P208「还没有季度报告 · 第一期窗口…开启」）、免责声明（P15 待定）、按钮文字（红线②：UI 里只写按钮文字） | NN/g 内容清单与内容审计（Content Inventory & Audit）方法 |
不是选一个，是按顺序用四个：
为什么这个顺序不能反：先做第 4 步会出现「每个模块都填得很漂亮，但模块之间接不上」；先做第 1 步才能保证第 4 步填出来的东西能连成产品。
「串不起来」的根因几乎总是同一个：脑子里装的是页面，不是对象。页面有 6 个，对象有 10 个，对象跨页面流动——把对象列出来，产品就自动串上了。
| # | 对象 | 主要属性（字段） | 出现在哪些模块 | 谁创建 | 生命周期状态 |
|---|---|---|---|---|---|
| 1 | 项目 Project | 名称、代币代号、cover、logo、社交链接、描述、画廊 | 首页横幅(P73–P84)／首页卡(P117–P132)／项目页 C1(P160–P174)／验证页头(P444)／落地页精选(P483–P499) | 项目方 | 草稿→验证中→发售中→毕业/失败→财报季（P33） |
| 2 | 代币 Token | 固定供应 10 亿、18 位小数、发售量%、建池预留%、合约地址 | 向导①③(P309–P320, P330–P340)／项目页 C1-R1(P227–P233)／持仓页 | 项目方（自己钱包发，平台不代发） | 未发→已发→建池→LP 销毁（P65–P67） |
| 3 | 验证凭证 Proof | 层级 L1/L2/L3、数据源、证明时间、证明哈希、覆盖月数、完整性 | 向导②⑥(P321–P329, P361–P372)／项目页 L2(P153–P159)＋验证通栏(P285–P297)／验证页(P444–P470) | 项目方发起，系统生成 | 待接入→已验证→复核中→降级→过期（P34–P42、P39–P41） |
| 4 | 发售 Sale | 模式（CCA/曲线）、时长 72h、清算价下限、毕业线、单地址限额、已募金额、批次 | 向导③(P330–P340)／项目页 R4(P248–P259)／首页横幅数据条(P79) | 项目方设定 + 系统计算 | 创建→进行中→达标/未达标→毕业/失败（P68–P69） |
| 5 | 里程碑 Milestone | 名称、衡量指标+数据源、目标值、解锁比例%、时间窗、当前状态 | 向导⑤(P343–P360)／项目页 C5(P186–P201)／持仓页模块6(P431–P433) | 项目方填，系统判 | 未达→进行中→达成→窗口过期→锁死（P61–P62、P399 待拍板） |
| 6 | 季度报告 Report | 季度、营收、走势、报告期、复验结果 | 项目页 C6(P202–P208)／持仓页季度验证(P427–P428) | 项目方提交，系统核验 | 未开始→已发→已复验→断连（P37） |
| 7 | 押金 Deposit | 金额、构成（现金+等值 VFY）、已退比例、达标条件、罚没去向 | 向导⑦(P384–P385)／持仓页模块6(P434–P437) | 系统计算 | 待缴→已缴→分批退还→罚没（P58–P60） |
| 8 | 持仓 Position | 数量、成本、现值、claim 状态 | 持仓页(P400–P423)／项目页 R3 面板 | 系统读链 | 拍卖中→已毕业→可 claim→已 claim |
| 9 | 经营指标 Traction | MRR、MAU、下载量、订阅、commits | 首页榜卡数据行(P107)／项目页 C3-C4(P176–P185) | zkTLS 证明 | 未验证→已验证→复核中 |
| 10 | 放款批次 Tranche | 30%/30%/40%、前置条件、时间窗、提现费 0.5% | 项目页 C5(P186–P201)／持仓页(P431–P433) | 系统 | 冻结→可提→已提（P70–P71、P62） |
用法：老板只要看这张表，就能回答「我们这个产品到底有哪几样东西」。之后每个模块 12 问里的第 5 问（字段），答案就是「这个模块要显示上面哪几个对象的哪几个属性」。这一条就把「模块 ↔ 数据」接上了。
---
统一列四件事：解决什么问题 / 什么时候用 / 产出物长什么样 / 我们适不适用。
推荐等级：★★★ = 现在立刻做；★★ = 有它更好，第二轮做；★ = 现在别碰。
| 方法 | 解决什么问题 | 什么时候用 | 产出物长什么样 | 我们适不适用 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 需求可追溯矩阵 Traceability Matrix ★★★ | 需求从哪来、被哪个模块实现、由哪条测试覆盖，三者对不上就说明漏了 | 需求一超过 20 条就必须有，否则必漏 | 一行一条需求：`需求号 \ | 需求一句话 \ | 优先级 \ | 实现模块 \ | 涉及元素 ID \ | 验收方式 \ | 状态` | 极其适用。我们现在一条需求编号都没有（见 F 部分给了编号方案）。出处：ISO/IEC/IEEE 29148-2018 定义了「好的需求」应具备的属性与可追溯性；IIBA BABOK 把可追溯性列为需求生命周期管理的核心任务 |
| 用户故事 + 验收标准 User Story + Acceptance Criteria ★★★ | 把「一句话需求」变成「可验证的完成条件」 | 每个模块动手前写一句 | 作为<角色>，我想<做某事>，以便<得到好处> + Given…When…Then… | 非常适用。 12 问清单的第 12 问就是它。出处：Bill Wake 的 INVEST 原则（业内通行，原文为 2003 年博客，本轮未逐字核实） | ||||||
| Gherkin / BDD（Given-When-Then） ★★ | 把验收标准写成任何人（包括非技术）都能读的句式，且可直接变成自动化测试 | 复杂分支多的流程（拍卖清算、里程碑放款、zkTLS 失败分支） | ``Given 项目方已连接 Stripe / When 提交链上证明 / Then 项目页该行显示「✓ 已连接」并列证明时间`` | 适用但不必全员学。 建议只在 5 个最复杂流程上用（拍卖清算、押金、里程碑放款、zkTLS 异常、claim）。官方语法参考：Cucumber Gherkin Reference | ||||||
| Impact Mapping（Gojko Adzic） ★ | 从「为什么做」倒推「要谁改变行为→做什么功能」，防止做了没人用的功能 | 规划阶段、功能取舍打架时 | 一张树状图：Why（目标）→ Who（角色）→ How（行为改变）→ What（功能） | 部分适用。 我们的 Why 已经清楚（"Launch apps on proof, not promises"），不用重做；但拍板「二期功能」时可以用它挡掉拍脑袋需求。出处：impactmapping.org | ||||||
| 用户故事地图 Story Mapping（Jeff Patton） ★★ | 把一堆功能排成「用户从左到右走一遍」的横向骨架 + 纵向优先级 | 页面/步骤多、要决定先做哪一段时 | 横向＝用户旅程步骤；纵向＝每步的功能，按必须/可选分层 | 适合我们的发币向导 7 步和买家旅程。 用它能一眼看出「第⑦步之前缺哪些步骤」。出处：Jeff Patton《User Story Mapping》 | ||||||
| 用户旅程 / 用户流程 User Journey / User Flow ★★★ | 把「人怎么一步步走到这个模块」画出来，避免设计孤立页面 | 有分支、有状态、有回退的流程 | 框 + 箭头 + 每个框标注状态与出口 | 必须做。 我们已经有一批流程图（软件开发与工程设计/流程图/），但缺「访客/买家/项目方三条旅程 × 页面互链」的那张总图 | ||||||
| Definition of Done / 设计 QA 清单 ★★★ | 统一「什么叫做完了」，避免「看起来做完了其实没做」 | 每个模块交付前 | 一组勾选项：四态齐、文案齐、埋点齐、无权限可见性对、截图验收过 | 必须做。 我们的红线⑤已有「截图验收」，把它扩展成清单即可。出处：Scrum Guide 的 Definition of Done（scrum.org） |
| 方法 | 解决什么问题 | 什么时候用 | 产出物长什么样 | 我们适不适用 | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 数据字典 Data Dictionary ★★★ | 每个字段叫什么、什么类型、从哪来、谁写、允许为空吗 | 界面元素一超过 100 个就必须有 | 一行一个字段：`字段名 \ | 中文名 \ | 类型/格式 \ | 示例值 \ | 数据来源 \ | 谁写入 \ | 是否可空 \ | 空态显示` | 我们已有雏形：Launchpad-界面元素数据字典.md 501 行，列为「ID / 页面 / 区块模块 / 元素名 / 示例值 / 数据来源 / 首期 / 状态」。缺 4 列：类型格式、谁写入、是否可空、空态显示。补齐这 4 列就是完整的数据字典。出处：IEEE 1016-2009 规定了软件设计描述（SDD）应包含的信息内容与组织方式，设计实体与其属性清单属于其范畴 |
| CRUD 矩阵 ★★★ | 哪个模块能「增/查/改/删」哪个对象；一眼看出「这个按钮到底该不该在这」 | 角色多、权限多、模块多 | 行＝对象，列＝模块（或角色），格子里写 C/R/U/D 或「—」 | 极其适用，而且能直接解决「按钮模糊」。 例：Deposit 押金对象——向导⑦ 是 C（创建）、持仓页模块6 是 R（读）；任何人都不该有 U/D（押金不能改不能删）→ 所以持仓页不该出现「修改押金」按钮。这一张表就能砍掉一堆多余的按钮 | |||||||
| 内容清单与内容审计 Content Inventory & Audit ★★★ | 现在页面上到底有多少内容、哪些重复、哪些没用、哪些缺 | 页面多、文案乱、要砍东西时 | 清单＝全部内容条目（我们已有 501 行）；审计＝给每条打标签（保留/改写/删除/缺失） | 我们正好缺「审计」这一步。 501 行是清单，但「状态」列只有已定稿/待拍板/有冲突，没有「这条有没有用/是不是重复」。审计一遍能直接查缺补漏。出处：NN/g《Content Inventory and Auditing 101》 | |||||||
| 对象地图 Object Map（OOUX / ORCA 框架） ★★★ | 产品里到底有哪几个「东西」，各自属性和关系是什么 | 一开始就该做；模块开始互相接不上时回来做 | 一组对象卡：对象名 + 属性列表 + 与其他对象的关系 + 每个对象的主按钮 | 最对症的一个。 见 A.3 已给我们的 10 个对象。OOUX 特别擅长「复杂系统里把看不见的结构变可见」。出处：Sophia V. Prater 提出的 OOUX，官方站点 ooux.com 提供 ORCA 框架与认证课程（该书是否有正式出版物：未核实，见文末） | |||||||
| 状态机 State Machine ★★★ | 一个对象有几种状态、状态之间怎么迁移、非法迁移怎么办 | 有生命周期的东西（项目/拍卖/押金/里程碑） | 状态框 + 迁移箭头 + 触发条件 + 守卫条件 | 必须做。 我们 D3/D4/D8 已有三张状态图（P33/P68/P69），但缺「押金状态机」和「里程碑单条状态机」。出处：行业通用做法，我们的 流程图/ 已是雏形 |
| 方法 | 解决什么问题 | 什么时候用 | 产出物长什么样 | 我们适不适用 |
|---|---|---|---|---|
| 目标导向设计 Goal-Directed Design（Alan Cooper） ★★ | 从「用户想达成什么目标」出发设计交互，而不是堆功能 | 交互乱、按钮多而无效时 | 用户目标 → 场景 → 交互框架 → 界面细节（一个自上而下的设计流程） | 思路适用，流程太重。 我们只借它的核心问法：「这个按钮服务谁的目标？」用在 12 问的第 2、3 问。出处：Cooper 等《About Face》 |
| 界面模式库 Design Patterns（Jenifer Tidwell） ★★ | 常见界面问题有现成答案，不用自己发明 | 设计每个具体控件时查 | 模式名 + 何时用 + 为什么有效 + 反例 | 非常适合。 我们有大量「列表 + 筛选 + 卡片 + 表格 + 分步向导 + 数值仪表」的常规问题，直接查模式比自创快。出处：Tidwell / Brewer / Valencia《Designing Interfaces》第 3 版 |
| 原子设计 Atomic Design（Brad Frost） ★ | 把界面拆成原子→分子→组织→模板→页面，让组件可复用 | 组件重复、样式不一致时 | 五层组件清单 + 每层的组件名与变体 | 我们不能直接用它的五层命名（老板要的是「模块」，不是化学比喻），但它的精神已经在用：设计系统 P25–P32 + Lucide 图标库 + 按钮四类分型。出处：Brad Frost《Atomic Design》（在线版 atomicdesign.bradfrost.com） |
| 设计系统 Design Systems（Alla Kholmatova） ★★ | 用「模式 + 规则 + 共享语言」保证一致，而不是一堆组件堆着 | 团队多人做界面时 | 设计原则 + 模式库 + 组件规范 + 命名约定 | 我们已有 80%（产品需求定稿.md 第 9 节 + 演示站 #/design）。缺的是「模块级模式」：例如「三态行」这个模式（✓/⛔/◌）同时出现在连接状态、验证通栏、里程碑——应写成一条模式，而不是三处各画一遍。出处：Alla Kholmatova《Design Systems》（Smashing Magazine） |
| 启发式评估 Heuristic Evaluation（Nielsen 十大启发式） ★★★ | 不找用户，专家先按 10 条原则扫一遍，能拦掉大部分低级问题 | 每个模块画完线稿后、开发前 | 10 条原则 × 每个模块逐条打勾/记问题 | 最划算的一个。 10 条里第 1 条「系统状态可见性」和第 9 条「帮助用户认识、诊断、从错误中恢复」，正好命中我们最大的空白——四态（空/加载/错/无权限）。这一条直接变成 12 问的第 7、9 问。出处：Jakob Nielsen，1994-04-24 发布，2024-01-30 复核（NN/g） |
| 可用性测试 Usability Testing ★★ | 真实用户能不能用起来 | 有可点的原型之后（我们现在有演示站，已经可以测） | 任务脚本 + 5 个用户 + 观察记录 + 问题清单 | 适用，且成本很低。 我们的演示站已上线，可以立刻找 5 个人做「找到某个项目的验证数据」「走完发币向导第⑦步」两个任务。出处：NN/g 可用性测试方法文章 |
| WCAG 可访问性 ★★★ | 色盲/键盘/屏幕阅读器用户能不能用；也是合法的工程纪律 | 从线稿期就该定，不是最后补 | 对照 WCAG 2.2 的成功标准逐条检查 | 我们必须做，且有硬风险：① 五条语义渐变不能是唯一区分手段（WCAG 1.4.1 Use of Color）——mint=涨/pink=跌必须同时有 ↑↓ 符号和数字；② 徽章全靠 emoji（◆◇○⛔）→ 屏幕阅读器读不出来（WCAG 1.1.1 非文本内容）；③ 弹窗/tooltip 需可键盘操作（2.1.1）且可关闭（1.4.13 Content on Hover or Focus）；④ 表单错误必须可识别并给建议（3.3.1、3.3.3）。出处：W3C WCAG 2.2 |
| 模式库：GOV.UK Design System / US Web Design System ★★★ | 政府和公共服务把「错误摘要、表单校验、空态、无权限页、多步流程」都写成了现成规范，免费抄 | 做表单、错误、向导时 | 每条模式：什么时候用 + 怎么用 + 不要怎么做 + 代码 | 极其适用。我们「全是表单和数值」，GOV.UK 的错误摘要（Error summary）和多步向导模式是行业最强；USWDS 的状态提示与表单模式也很完整。注意：只抄模式与规则，不抄视觉（视觉仍按我们已定稿的设计系统） |
| 精益 UX Lean UX ★ | 用假设→最小实验→学习替代大文档，避免做了没人要的功能 | 需求不确定、要快速验证时 | 假设声明 + 最小可行实验 + 学习记录 | 部分适用。 我们的机制设计（拍卖 vs 曲线、押金比例）正是该用它的地方；但界面细节不能靠精益，界面细节靠 12 问清单。出处：Gothelf & Seiden《Lean UX》 |
---
| # | 书名 | 作者 | 出版方 | 一句话：它解决什么问题 | 对应我们哪一步 | 现在值得读吗 |
|---|---|---|---|---|---|---|
| 1 | Information Architecture: for the Web and Beyond（4th ed.） | Louis Rosenfeld、Peter Morville、Jorge Arango | O'Reilly | 内容怎么组织、命名、导航、找得到——IA 的圣经 | A 部分；我们的 6 个页面划分、锚点导航、页面互链 | 值得，且优先级最高。 先读「组织系统/标签系统/导航系统」三章即可 |
| 2 | About Face: The Essentials of Interaction Design（4th ed.） | Alan Cooper、Robert Reimann、David Cronin、Christopher Noessel | Wiley | 交互设计的目标导向方法论，讲透「按钮为什么存在」 | 12 问的第 2、3、8 问 | 方法值得，整本现在不必。 只读「目标导向设计」与「消除蠢笨」相关章节 |
| 3 | Designing Interfaces（3rd ed.） | Jenifer Tidwell、Charles Brewer、Aynne Valencia | O'Reilly | 常见界面问题的现成模式大全（含大量数据展示模式） | 每个具体控件（表格、筛选、分步表单、数值展示） | 值得当工具书。 不用通读，遇到问题查 |
| 4 | Forms that Work: Designing Web Forms for Usability | Caroline Jarrett、Gerry Gaffney | Morgan Kaufmann | 表单为什么让人填错、怎么设计才不出错 | 我们的命门：发币向导 7 步全是表单，押金/里程碑/收入分账都是数值输入 | 最值得现在读的一本。 表单是我们的主界面形态 |
| 5 | Web Form Design: Filling in the Blanks | Luke Wroblewski | Rosenfeld Media | 单字段级别的表单设计决策（标签位置、错误提示、必填标记） | 同上，更细一层 | 值得，和第 4 本二选一或搭配读。 更短更实用 |
| 6 | The Elements of User Experience（2nd ed.） | Jesse James Garrett | New Riders | 把 UX 拆成五层（战略/范围/结构/框架/表现），一张图讲清「需求怎么落到界面」 | F 部分那条链的理论原型 | 值得读第一章那张五层图。 这是老板问的「怎么保证功能需求能在 UI 上体现」的标准答案 |
| 7 | User Story Mapping | Jeff Patton（合著 Peter Economy；序言 Martin Fowler、Alan Cooper、Marty Cagan） | O'Reilly | 把功能铺成用户走一遍的骨架，决定先做哪一段 | 发币向导 7 步的顺序与分期、买家旅程 | 值得，做二期规划前读 |
| 8 | Lean UX: Creating Great Products with Agile Teams（3rd ed.） | Jeff Gothelf、Josh Seiden | O'Reilly | 用假设和小实验代替大文档，快速验证 | 机制类需求（拍卖 vs 曲线、押金比例、限额） | 可选。 我们机制已定，读它是为了二期决策更省事 |
| 9 | Atomic Design | Brad Frost | 自出版（在线版免费） | 界面拆成原子→分子→组织→模板→页面，保证复用与一致 | 我们的设计系统 P25–P32 复用逻辑 | 读在线版的「原子设计的五个层次」一节就够，不必买 |
| 10 | Design Systems: A practical guide to creating design languages for digital products | Alla Kholmatova | Smashing Magazine | 怎么把「模式 + 规则 + 共享语言」沉淀成设计系统，而不是堆组件 | 补齐我们缺的「模块级模式」（三态行、徽章规则、数值格式） | 值得。 我们设计系统已有 80%，这本书补的就是剩下的 20% |
| 11 | Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability（3rd ed.） | Steve Krug | New Riders | 可用性的常识，最短时间建立判断力 | 全站可用性自检；给非技术老板读最合适 | 最值得老板亲自读的一本。 又薄又白话，一天能读完 |
| 12 | Refactoring UI | Adam Wathan、Steve Schoger | 自出版（refactoringui.com） | 让界面「看起来对」的具体技巧（层次、间距、颜色、阴影） | 我们已定稿的视觉部分；主要是给设计同学 | 我们视觉已定稿，暂时不需要。 等二期做新页面时再买 |
| 13 | Object-Oriented UX（OOUX） | Sophia V. Prater（提出者） | 图书出版信息未核实 | 把复杂系统按「对象」而不是「页面」来梳理 | A.3 的对象地图就来自它——我们最需要的那个方法 | 方法值得立刻用；书是否存在需另行确认。 官方站点 ooux.com 目前以 ORCA 框架 + 认证课程形式提供，我在官方站点与检索中未核实到正式出版的图书，因此不列出版方、不写 ISBN。想学就直接用 A.3 那张表 + 官方站点的 ORCA 说明，不必等书 |
纠正一处任务里的说法：《Information Architecture》的作者是 Rosenfeld / Morville / Arango；O'Reilly 是出版方，不是作者。开会引用时别说错。
---
| 标准/规范 | 全名与版本 | 它规定什么 | 状态（核查日） | 官方链接 |
|---|---|---|---|---|
| ISO 9241-210:2019 | Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems | 以人为中心的设计原则与活动（含一致性检查清单 Annex B） | 已发布（第 2 版，2019-07；2025-05-22 复审确认继续有效；33 页；ISO/TC 159/SC 4） | https://www.iso.org/standard/77520.html |
| ISO/IEC/IEEE 29148-2018 | Systems and software engineering — Life cycle processes — Requirements engineering | 「什么是好需求」、需求应具备的属性与特征、需求工程流程 | Active Standard（现行有效；2018-11-30 发布；替代 29148-2011） | https://standards.ieee.org/ieee/29148/6937/ |
| IEEE 1016-2009 | IEEE Standard for Information Technology—Systems Design—Software Design Descriptions | 软件设计描述（SDD）应包含的信息内容与组织方式 | Inactive-Reserved（2009-07-20 发布，2020-03-05 已停止维护，未随 10 年周期修订） | https://standards.ieee.org/ieee/1016/4502/ |
| WCAG 2.2 | Web Content Accessibility Guidelines 2.2 | 可访问性的四条原则与可测试的成功标准（A/AA/AAA） | W3C Recommendation（现行版本页标注 2024-12-12；扩展 WCAG 2.1，符合 2.2 即符合 2.0/2.1） | https://www.w3.org/TR/WCAG22/ ・快速参考 https://www.w3.org/WAI/WCAG22/quickref/ |
| NN/g：10 Usability Heuristics | 10 Usability Heuristics for User Interface Design | 交互设计 10 条通用原则（启发式评估的基准） | 在线文章（Jakob Nielsen，1994-04-24 发布，2024-01-30 复核） | https://www.nngroup.com/articles/ten-usability-heuristics/ |
| NN/g：Content Inventory & Auditing 101 | Content Inventory and Auditing 101 | 内容清单与内容审计怎么做（查缺补漏的方法论） | 在线文章 | https://www.nngroup.com/articles/content-audits/ |
| NN/g：IA 与导航的区别 | The Difference Between Information Architecture (IA) and Navigation | 澄清 IA ≠ 导航，避免混用术语 | 在线文章 | https://www.nngroup.com/articles/ia-vs-navigation/ |
| GOV.UK Design System | Design your service using GOV.UK styles, components and patterns | 模式库：错误摘要、表单校验、多步流程、无权限页等 | 持续维护的官方设计系统 | https://design-system.service.gov.uk/ |
| U.S. Web Design System (USWDS) | The United States Web Design System | 同上，美国政府版；表单与状态模式完整 | 持续维护的官方设计系统 | https://designsystem.digital.gov/ |
| Cucumber Gherkin Reference | Gherkin Reference | Given-When-Then 的官方语法（写验收标准用） | 官方文档 | https://cucumber.io/docs/gherkin/reference/ |
| Scrum Guide：Definition of Done | What is the Definition of Done? | 「做完」的正式定义（做设计 QA 清单的依据） | 官方资源 | https://www.scrum.org/resources/what-definition-done-0 |
| Impact Mapping | Impact Mapping: Making a big impact with software products and projects（Gojko Adzic） | Why→Who→How→What 的影响地图方法 | 官方站点（含样例 PDF） | https://www.impactmapping.org/ |
两个诚实的提示： 1. IEEE 1016-2009 已经停止维护（Inactive-Reserved）。它是理解「设计描述该写什么」的好读物，但不要说「我们要通过 IEEE 1016 认证」。 2. ISO 9241-210 是收费标准（官方定价 CHF 179）。我们不需要买——它的核心就是「先搞清用户和情境→定需求→出设计→按用户反馈迭代」的四步循环，我们照这个循环做就够了。
---
用法：一个模块抄一张。填不满的格子就是缺口；填出来互相矛盾的格子就是口径冲突。两张都要交给老板拍板。
| # | 问题 | 为什么要问 | 填不出来/填不清楚说明什么 |
|---|---|---|---|
| Q1 | 这个模块的编号和名字是什么？在哪个页面？包含哪些元素 ID？ | 给它一个唯一身份，之后需求、验收、bug 全用它当坐标 | 没有编号 → 讨论时只能靠"那个红框的东西"，必乱 |
| Q2 | 它为谁服务？（访客/买家/项目方/平台运营）这些人在什么状态下会看到它？ | 同一个模块对不同角色可能完全不同（我们 P43 已定：访客免钱包可看首页/项目页/验证页） | 说不清角色 → 权限和可见性一定漏 |
| Q3 | 用用户的嘴说一句话：它替用户解决什么问题？ | 这是判断"这个模块该不该存在""这个按钮该不该有"的唯一标准 | 说不出来 → 这个模块大概率可以删 |
| Q4 | 它承接哪一条需求编号？（上游目标编号是什么？） | 打通「需求 → 模块 → 验收」的链，防漏也防多做 | 没编号 → 说明我们根本没有需求台账（这正是我们当前的状况） |
| Q5 | 它要显示哪些字段/数据？逐个列：字段名、示例值、数据来源、谁写入、空了显示什么 | 直接回答老板的「每个模块对应有哪些数据需要体现」 | 写不出「谁写入」→ 开发时一定来问；写不出空态 → 上线后会出现空白面板 |
| Q6 | 进入条件和退出条件是什么？（什么状态看得见，什么状态看不见） | 模块不是所有时候都该出现；状态决定可见性 | 填不出 → 会出现"拍卖还没开始就显示成交表"这类错 |
| Q7 | 四种非正常状态各是什么样：空态 / 加载中 / 出错 / 无权限（每态一句话 + 一个动作） | 这四态是界面完整度的分水岭（Nielsen 第 1 条：系统状态可见性） | 填不出 → 上线后第一周全是"为什么这里是空的" |
| Q8 | 主按钮是什么？点了发生什么（一步步）？次要按钮？危险按钮？ | 老板原话「对里面的按钮还是很模糊」就是这一问 | 说不清"点了发生什么" → 这个按钮就是装饰 |
| Q9 | 成功和失败各给什么反馈？（文案 + 出现在哪 + 停留多久） | Nielsen 第 9 条：帮用户认识、诊断、从错误中恢复 | 只有成功反馈没有失败反馈 → 用户卡住就流失 |
| Q10 | 有什么边界、限额、精度、单位？（数字类必填：最小值/最大值/超限怎么办/小数位/币种/四舍五入规则） | 我们全是数值：10 亿供应、$0.001 下限、2% 限额、5%/10% 押金、30/30/40、0.3% 手续费、±300% 波动阈值 | 不写 → 开发各写各的取整规则，链上链下数字对不上 |
| Q11 | 埋点：记哪些事件？用来看什么？ | 没埋点就无法判断这个模块有没有用，二期只能拍脑袋 | 不填 → 二期砍功能时没人有数据 |
| Q12 | 验收标准：怎么算做完（可勾选）？谁验收？ | Definition of Done；也是可追溯矩阵的最后一环 | 不填 → "做完了"永远靠感觉吵架 |
附：一张可以直接打印的空白表（贴在墙上，一个模块一张） `` 模块编号：__________ 模块名：____________________ 页面：__________ 元素 ID：__________ Q1 包含元素 ID： Q2 为谁 / 在什么状态下看到： Q3 一句话目的（用户的话）： Q4 承接需求编号：________ 上游目标编号：________ Q5 字段清单（每个字段一行：名 / 示例值 / 来源 / 谁写入 / 空态显示） ① ② ③ Q6 进入条件：____________________ 退出条件：____________________ Q7 空态：____________ / 加载中：____________ / 出错：____________ / 无权限：____________ Q8 主按钮：__________ → 点了：____________ 次要：__________ 危险：__________ Q9 成功反馈：____________ 失败反馈：____________ Q10 边界限额：____________________________________ Q11 埋点事件：____________________________________ Q12 验收标准（勾选项）： ☐ 四态齐 ☐ 字段与数据字典一致 ☐ 无权限可见性正确 ☐ 数值精度与单位一致 ☐ 文案已定稿 ☐ 埋点已加 ☐ 截图验收 ☐ 开发/设计/老板三方签字 验收人：__________ 日期：__________ ``
Launchpad-界面元素数据字典.md 里找到对应的一行 ID。 找不到 → 要么这个字段是漏登记的（去补一行），要么这个字段不该显示（删掉）。这一条就是"查缺补漏"的机械动作，501 行字典立刻变成可校验的题库。选这个当例子的原因：它是全产品逻辑最多、数据来源最杂、状态最多的模块之一（zkTLS 证明 + 三态 + 6 个数据源 + 多种权限），也是最能说明「一个模块怎么被问清楚」的样本。 现有资产：元素 IDP153–P159；关联全局P42（D8 连接状态三态枚举）、P34–P41（D5 验证体系）、P43（D1 角色权限）、P44（信息架构）、P36（一次验证时序 ①–⑧）。
| 问题 | 填写内容 |
|---|---|
| Q1 编号 / 名字 / 页面 / 元素 ID | 模块编号：M-PP-L2（项目页 右栏 App 侧，v2 双栏）；模块名：连接状态清单；页面：项目页（W2 v2，右栏靠前位置，见 产品需求定稿.md 第 8 节「右=App 侧（连接状态三态行/Traction 指标/里程碑放款/季度报告/代币用途/画廊）」）；元素 ID：P153–P159；关联全局：P42、P34–P41、P43、P44 |
| Q2 为谁 / 什么状态下看到 | ① 买家 / 访客（未连钱包也能看，依 P43）：在判断「这个项目的收入/流量是不是真的」时看；② 项目方：自己的项目页上看着它决定「我先去连哪个源」。平台运营无前台页面（见角色定义），所以本模块不为运营设计 |
| Q3 一句话目的（用户的话） | 「我要能看穿那个『已验证 ◆』徽章——知道这个项目的数据是从哪个平台的哪张报表里来的、什么时候证的，而不是项目方自己填的。」 |
| Q4 承接需求编号 | 需新建（我们目前没有需求编号，这是查缺补漏的第一个缺口）。建议：R-05 验证可信度必须可下钻到数据源级；上游目标 G-02 Launch apps on proof, not promises；下游接验证页 R-06 |
| Q5 字段清单 | 见下方「Q5 字段表」 |
| Q6 进入 / 退出条件 | 进入：项目创建后（状态 ≥ 草稿）在项目页始终显示，与发售方式无关——因为「未验证」本身也是买家要知道的信息。退出：项目下架/删除时整块移除。可见性：访客与买家只读（看不到「连接」按钮，依 P43）；项目方本人多出「连接」按钮 |
| Q7 四态 | 空态（项目刚建、一个源都没连）：「还没有连接任何数据源 · 连接后可获得验证徽章」+ 主按钮「去连接」（跳向导②）。加载中：逐行骨架屏（不整块 loading——因为 6 行是各自独立读取的）。出错：该行显示 ⛔ 未连接 + 行内提示「上次验证失败，可重试」+「重试」；TLS 1.2 不兼容时切 proxy 模式（P39），不向用户暴露技术细节。无权限：访客/买家视角整个「连接」按钮列不渲染（不是置灰——置灰会让人以为"连上就有权限了"） |
| Q8 主按钮 | 主按钮：行内「连接」按钮（行级小按钮，哑光实心，依 P28）。点了发生什么（按 P36 时序）：① 项目方点「连接」→ ② 跳转浏览器插件 → ③ 打开该数据源官方登录页 → ④ 插件本地对 TLS 会话出证（凭证不出本地）→ ⑤ Vela（TEE）验签 → ⑥ 证明哈希上链 zkVerify → ⑦ 前端读凭证 → ⑧ 该行状态变为 ✓ 已连接 并列「证明于 MM-DD」。次要按钮：无。危险按钮：无。已知缺口（记入待办）：「断开连接」本期未设计——需明确是「不允许断开」还是「放到二期」 |
| Q9 反馈 | 成功：该行原地变 ✓ 已连接 + 证明时间刷新 + 页面顶部徽章按规则升级（◆/◇），并给一次轻提示「已连接 Stripe · 证明已上链」。失败：行内 pink 语义色（卖/跌用色，我们的既有语义）+ 一句原因 + 「重试」。中途放弃（用户跳到插件后没回来）：这是最容易漏的一态——需在回到页面时给一次「上次连接未完成，要重试吗」的确认 |
| Q10 边界 / 限额 / 精度 | ① 本期支持的源上限：6 个（GitHub / App Store / X / Google Analytics / Stripe / Discord，P153）；② 仅 TLS 1.2（P38）；③ transcript ≤ 20KB（P38）；④ notary ≥ 2 实例（P38）；⑤ 收入环比波动 > ±300% → 人工复核（P40），此期间该行需有「复核中」表达（当前字典里没有这一态，是缺口）；⑥ 链上收入免 zkTLS，直接读链（P41）——这类行的状态表达需与 zkTLS 行区分（缺口）；⑦ 时间格式统一 MM-DD（示例「证明于 10-01」） |
| Q11 埋点 | connect_row_click{source}、connect_success{source, 耗时, 层级L1/L2}、connect_fail{source, 失败原因}、connect_abandon{source, 停在第几步}（对应时序 ②–⑦）。用来看：哪个数据源最容易连不上（决定要不要做 proxy 兜底、要不要把某个源下架）、以及连接中途流失率 |
| Q12 验收标准 | ☐ 6 行源名与 P153 完全一致；☐ 三态取值只用 已连接/未连接/待接入（P42），不自创第四种；☐ 「该源供什么指标」文案与 P158 一致；☐ 访客与买家视角看不到「连接」按钮（P43）；☐ 空态/加载/出错/无权限四态都有真实截图；☐ 证明时间格式统一；☐ 复核中态与链上直读态有明确表达；☐ 4 个埋点已加；☐ 设计/开发/老板三方签字。验收人：产品负责人 + 开发负责人 |
Q5 字段表（展开）
| 字段名 | 中文名 | 示例值 | 数据来源 | 谁写入 | 是否可空 | 空态显示 |
|---|---|---|---|---|---|---|
| source_name | 数据源行名 | GitHub / App Store / X / Google Analytics / Stripe / Discord | 平台运营（固定清单） | 平台运营 | 否 | 不适用（固定枚举） |
| connect_status | 连接状态 | ✓ 已连接 / ⛔ 未连接 / ◌ 待接入 | zkTLS 证明 | 系统 | 否 | 默认「未连接」，不得留空 |
| source_metrics | 该源供什么指标 | commits·代码活跃度／下载量·订阅／账号归属·社交／MAU·访问量／收入·MRR／社区规模 | 平台运营 | 平台运营 | 是 | 空则该行不显示指标列 |
| proved_at | 证明时间 | 证明于 10-01 | zkTLS 证明 | 系统 | 是 | 状态=未连接时整格留空，不显示占位符 |
| connect_action | 「连接」按钮 | 连接 | 平台运营 | —（仅项目方视角渲染） | 是 | 访客/买家视角不渲染 |
填完这一张，暴露出的 3 个真实缺口（这就是查缺补漏的产出）： 1. 「复核中」态缺失：P40 规定了「收入环比波动 > ±300% 触发人工复核」，但三态枚举（P42）里没有「复核中」，字典里也没有对应元素 → 需新增一个态或一个标记。 2. 「链上直读」与「zkTLS 证明」在界面上长得一样：P41 规定链上收入免 zkTLS，但界面没有区分这两种可信度来源 → 买家无法分辨，建议加一个来源标识。 3. 「断开连接」没有设计：要么明确不允许，要么排期二期。不明确的话开发会自己发明一个入口。
选它的原因：它最能证明 12 问清单的另一半价值——填表会直接撞出口径冲突。 现有资产：P384（押金金额 $10,000）、P385（押金构成 = 募资额 5%，现金+等值 VFY 各半）、P386（「签名并发币」按钮）、P383/P394（检查清单「☐ 交押金」）；全局P58、P59、P60。
| 问题 | 填写内容 |
|---|---|
| Q1 | M-W3-S7-DEP；步骤⑦ · 押金（嵌在「核对＋交押金」步的下方）；元素 ID：P384–P385（主按钮 P386 属本步但服务整步） |
| Q2 | 项目方，且必须已在第⑦步把前面 ①–⑥ 填完（或明确跳过②⑥） |
| Q3 | 「交押金这一步我要知道交多少、交给谁、什么条件能退回来，才敢点签名。」 |
| Q4 | 需新建。建议 R-21 上币押金：金额可解释、退还条件可见 |
| Q5 | deposit_amount 押金金额 / $10,000 / 系统计算 / 系统 / 否 / —；deposit_breakdown 押金构成 / 押金 = 募资额 5%（现金 + 等值 VFY 各半） / 系统计算 / 系统 / 否 / —；deposit_refund_rule 退还条件 / 季度业绩达标分批退还（达标线待定） / 平台运营 / 平台运营 / 是（当前缺失） |
| Q6 | 进入：第⑦步且里程碑合计 = 100%（P381 未勾选则不可提交）；退出：发币成功跳项目页（拍卖中态，P44） |
| Q7 | 空态：不适用（金额必算得出）。加载中：金额计算中显示占位。出错：钱包拒签 → 保持本步 + 行内提示「签名被取消，未扣款」。无权限：未连钱包 → 主按钮置灰 + 提示「请先连接钱包」（P388 检查项） |
| Q8 | 主按钮：「签名并发币」（P386）。点了：钱包签名 → 收押金（现金 + 等值 VFY 各半）→ 创建拍卖（若选 CCA）→ 跳项目页「拍卖中」态。次要：无。危险：无 |
| Q9 | 成功：跳项目页 + 顶部提示「已发币 · 拍卖已开始」。失败：留本步 + 具体原因（余额不足 / 拒签 / 链上失败）+「重试」 |
| Q10 | 押金比例：募资 5%（P58，与演示站 10% 冲突）；达标线：季度业绩 80%【待定】且须连续 ≥1 年（P59）；罚没去向：风险准备金（P60）；币种：USDC + VFY；精度：未定（金额小数位、VFY 汇率取价时点、四舍五入规则全部未定 → 必须补） |
| Q11 | deposit_view、deposit_sign_click、deposit_sign_success、deposit_sign_fail{reason}、deposit_page_drop（看到金额但没签名就走） |
| Q12 | ☐ 金额与「募资额 × 比例」对得上且口径唯一；☐ 构成文案与 P385 一致；☐ 退还条件有明确文案（当前缺）；☐ 拒签/余额不足/链上失败三态齐；☐ 精度与单位已定义；☐ 与持仓页押金模块（P434–P437）数字口径一致；☐ 截图验收 |
填到这一步撞出来的冲突（7 条口径冲突里的 2 条，被这张表自动翻出来）： 1. 比例冲突：文档 5%（P58）vs 演示站 10% → 直接影响押金金额与合约参数，必须先拍板。 2. 金额的时点问题（新发现）：P384 把押金金额的数据来源标为「系统计算」，但押金 = 募资额 × 5%，而募资额在第⑦步还不知道（拍卖还没开始）。所以第⑦步显示的 $10,000 到底是「预估」还是「锁定」？如果不锁定，签名时扣多少？这是一个 12 问清单才问得出来的问题，任何线稿评审都发现不了。 3. 退还条件缺失：持仓页有「押金释放说明」（P437，平台运营，待拍板），但向导第⑦步没有对应文案 → 项目方在最需要知道的时刻看不到退还规则。
| 我们已有的 | 在 12 问里承担什么 | 还缺什么 |
|---|---|---|
Launchpad-界面元素数据字典.md（501 行，P01–P501） | Q1 的元素 ID 来源 + Q5 的字段底稿（列「元素名/示例值/数据来源」） | 缺 4 列：类型格式、谁写入、是否可空、空态显示；缺「关联需求编号」 |
线稿-v1 ~ 线稿-v5 | Q6/Q7/Q8 的画面依据 | 线稿只画了正常态；四态（空/加载/错/无权限）没有线稿 |
流程图/（软件工程图集 9 图 + 参数总表 + 口径冲突表） | Q6 状态迁移 + Q10 边界限额的全部数字 | 缺对象级的 CRUD 矩阵；缺押金与里程碑单条的状态机 |
产品需求定稿.md 第 8 节页面表 | Q2/Q3 的角色与页面归属 | 缺需求编号体系（Q4 全部为空） |
产品需求定稿.md 第 9 节设计系统 | Q8/Q9 的按钮与反馈规范 | 缺「模块级模式」（三态行、数值格式规则） |
对接后的一个机械动作：把 501 行按「模块」分组（数据字典里的「区块/模块」列已经分好了），一个模块产出一张 12 问表。按现在的分法，首页 7 个模块 + 项目页约 20 个模块 + 向导 7 步 + 持仓页 6 个模块 + 验证页 5 个模块 + 落地页 3 个模块 ≈ 50 张表。不用一次做完，按 F 的顺序做。
| 错误填法 | 为什么错 | 正确填法 |
|---|---|---|
| Q3 写成「展示连接状态清单」 | 这是功能描述，不是用户目的；用它判断不出按钮该不该有 | 「我要看穿『已验证』徽章的数据来源和证明时间」 |
| Q5 只写字段名，不写「谁写入」 | 开发一定会来问「这个字段是我算还是后端给？」 | 每行必填「数据来源 + 谁写入」两列 |
| Q7 只填空态 | 加载/出错/无权限才是真正的 bug 来源 | 四态每态一句话 + 一个动作，缺一不可 |
| Q8 写「按钮点击后调用接口」 | 倒过来了：先说用户看到什么变化，再说接口 | 「点了→跳插件→登录数据源官方后台→本地出证→验签→上链→本行变✓」 |
| Q10 写「金额要合理」 | 不可验证 = 没写 | 「最小 $0.001；小数 4 位；超限自动退款；币种 USDC」 |
| Q12 写「功能正常」 | 不可勾选 = 没写 | 「☐ 四态有截图 ☐ 字段与字典一致 ☐ 埋点已加」 |
---
答案是一条链，五个环节，每个环节都要能互相查到。这条链的原型就是 Jesse James Garrett 在《The Elements of User Experience》里那张五层图（战略 → 范围 → 结构 → 框架 → 表现）。
```
① 目标 G-xx （为什么做——老板的话）
↓ 必须能追溯到
② 需求 R-xx （要做成什么，可验证）
↓ 必须能追溯到
③ 对象 + 字段（数据字典：有什么数据、谁写、空了怎么办）
↓ 必须能追溯到
④ 模块 + 元素 ID（界面元素字典：显示在哪、长什么样、四态）
↓ 必须能追溯到
⑤ 验收标准 AC（怎么算做到：可勾选 + 谁签字）
```
判断链条断没断的三个检查问题（老板可以随时拿来问团队）：
| 检查 | 问法 | 断了的症状 |
|---|---|---|
| 需求 → 界面 | 「这条需求，在界面上哪个元素 ID 体现？」 | 答不出来 → 需求没落地 |
| 界面 → 需求 | 「这个按钮/这块数据，服务哪条需求编号？」 | 答不出来 → 多余的界面 |
| 字段 → 两端 | 「这个数字从哪来？谁写？空了显示什么？」 | 答不出来 → 开发会自己决定，然后出错 |
一条走通的示范链（用我们产品真数据）：
| 环节 | 内容 |
|---|---|
| ① 目标 | G-02 —— Launch apps on proof, not promises（用证据发币，不用承诺） |
| ② 需求 | R-05 —— 买家必须能从项目页下钻到「数据源级」验证证据（谁证的、什么时候证的） |
| ③ 对象 + 字段 | 对象 验证凭证 Proof；字段：source_name、connect_status、proved_at、source_metrics |
| ④ 模块 + 元素 ID | 项目页 L2 · 连接状态清单，元素 P153–P159（状态枚举 P42，来源 P34–P41，权限 P43） |
| ⑤ 验收 | 「访客无需连钱包即可看到 6 行源名与三态；项目方额外可见『连接』按钮；四态有截图；埋点 4 个已加」 |
这条链条一建起来，"功能需求"和"UI 体现"就不再是两件事，而是同一张表的两列。 老板问「怎么保证」，答案是：保证不了靠人记，只能靠这张表对得上。
---
| 阶段 | 做什么 | 用时 | 产出 |
|---|---|---|---|
| 0 | 老板拍板：先做一个页面（建议选项目页，因为它逻辑最密、问题最集中，是"最难的那个"） | 5 分钟 | 决定范围 |
| 1 | 用 A.3 的对象地图过一遍：「这 10 个对象对不对？有没有漏的？」 | 15 分钟 | 一张确认过的对象清单 |
| 2 | 用 B2 的 CRUD 矩阵过一遍对象 × 模块，逐格标 C/R/U/D/— | 20 分钟 | 一页矩阵；多余的按钮会在这里现形 |
| 3 | 给项目页的每个模块各填一张 12 问表（E.1），不会的先写「未定 + 建议」 | 40 分钟 | 20 张表；缺口和冲突会成串冒出来 |
| 4 | 把 12 问表里所有「未定」汇成一张待拍板清单，标出影响面（合约/前端/文案） | 10 分钟 | 待拍板清单（并入 产品需求定稿.md 第 11 节的口径冲突表） |
| 5 | 之后的日常：开发前必须有一张填完的 12 问表；交付前必须过 Q12 的勾选项 | 持续 | 交付质量稳定 |
为什么从项目页开始：项目页一个问题要牵动 10 个对象里的 7 个（项目、代币、凭证、发售、里程碑、报告、持仓），把它的 20 个模块问清楚，等于把整个产品的数据关系都走了一遍。这是投入产出比最高的一刀。
---
已核实（抓到官方页面或官方站点）
| 项 | 核实到的内容 |
|---|---|
| About Face 4th ed. | 书名、四位作者、出版方 Wiley（官方商品页可访问） |
| Designing Interfaces 3rd ed. | 书名、三位作者、出版方 O'Reilly（官方 library 页可访问） |
| Information Architecture: for the Web and Beyond | 书名、作者 Rosenfeld / Morville / Arango、出版方 O'Reilly（任务描述把 O'Reilly 当成了作者，此处更正） |
| Refactoring UI | 作者 Adam Wathan、Steve Schoger，官方站点 refactoringui.com 可访问 |
| Atomic Design | 作者 Brad Frost，官方在线版 atomicdesign.bradfrost.com（GitHub 仓库可访问，站点本轮未逐一抓取） |
| Design Systems | 作者 Alla Kholmatova，出版方 Smashing Magazine（官方商店页可访问） |
| Lean UX 3rd ed. | 书名、作者 Jeff Gothelf & Josh Seiden，出版方 O'Reilly（图书馆编目记录多条一致） |
| User Story Mapping | 书名、作者 Jeff Patton（合著 Peter Economy，序言 Martin Fowler / Alan Cooper / Marty Cagan），出版方 O'Reilly |
| Don't Make Me Think, Revisited | 书名、作者 Steve Krug、第 3 版，出版方 New Riders |
| The Elements of User Experience | 书名、作者 Jesse James Garrett，出版方 New Riders |
| Forms that Work | 书名、作者 Caroline Jarrett & Gerry Gaffney，出版方 Morgan Kaufmann |
| Web Form Design | 书名、作者 Luke Wroblewski，出版方 Rosenfeld Media |
| ISO 9241-210:2019 | 官方页：第 2 版、2019-07、33 页、ISO/TC 159/SC 4、2025-05-22 复审确认 |
| ISO/IEC/IEEE 29148-2018 | 官方页：Active Standard、2018-11-30 发布、替代 29148-2011 |
| IEEE 1016-2009 | 官方页：Inactive-Reserved、2009-07-20 发布、2020-03-05 停止维护 |
| WCAG 2.2 | 官方页：W3C Recommendation，现行版本页标注 2024-12-12 |
| NN/g 10 Usability Heuristics | 官方页：Jakob Nielsen，1994-04-24 发布，2024-01-30 复核 |
| NN/g 内容清单与审计 | 官方文章页可访问（Content Inventory and Auditing 101） |
| NN/g IA 与导航的区别 | 官方文章页可访问 |
| GOV.UK Design System / USWDS | 官方站点可访问 |
| Cucumber Gherkin Reference | 官方文档页可访问 |
| Scrum Definition of Done | scrum.org 官方资源页可访问 |
| Impact Mapping | 官方站点 impactmapping.org 可访问 |
未核实 / 需要另行确认
| 项 | 说明 |
|---|---|
| 《Object-Oriented UX》图书 | 任务书单里列了这本书。我核实了 OOUX 方法与其官方站点 ooux.com（由 Sophia V. Prater 提出，官方提供 ORCA 框架与认证课程），但在官方站点与多轮检索中均未核实到正式出版的图书（无出版方、无出版年）。因此本文件不列作者署名格式以外的出版信息、不写 ISBN。方法本身可用（见 A.3），书请另行确认。 |
| ISBN | 按任务要求，全文不写任何 ISBN（即使检索结果里出现过数字串）。 |
| Bill Wake 的 INVEST 原则原文 | 业内通行的用户故事质量准则，通常归于 2003 年 Bill Wake 的博客文章，本轮未逐字核实原文，故正文只作方法引用、不给链接。 |
| IIBA BABOK 中「需求可追溯性」的具体条款号 | 只在检索结果中看到 IIBA 官方 PDF 的相关字样，未逐页核对条款号，故正文只作体系性引用，不给具体条款。 |
| ISO 9241-210 正文条款 | 它是收费标准，我读了官方摘要页（Annex B 为一致性检查清单），没有读正文，故正文只引用其「四步循环」这一公开摘要层面的内容。 |
| NN/g 可用性测试文章的确切 URL | 只核实到 NN/g 文章总索引页，未锁定具体文章地址，故 D 部分未给该链接。 |
---
文件位置：软件开发与工程设计/调研-信息设计方法论.md ｜ 本轮只创建此文件，未修改任何其他文件。