UX Spec: [Screen/Flow Name]【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-StudiosStatus: In DesignAuthor: [user ux-designer]Last Updated: [todays date]Journey Phase(s): [from context]Template: UX SpecPurpose Player Need[To be designed]Player Context on Arrival[To be designed]Navigation Position[To be designed]Entry Exit Points[To be designed]Layout SpecificationInformation HierarchyLayout ZonesComponent InventoryASCII Wireframe[To be designed]States Variants[To be designed]Interaction Map[To be designed]Events Fired[To be designed]Transitions Animations[To be designed]Data Requirements[To be designed]Accessibility[To be designed]Localization Considerations[To be designed]Acceptance Criteria[To be designed]Open Questions[To be designed]### 5.2 HUD 设计骨架 markdown # HUD Design **Status**: In Design **Author**: [user ux-designer] **Last Updated**: [todays date] **Template**: HUD Design ## HUD Philosophy [To be designed] ## Information Architecture ### Full Information Inventory ### Categorization [To be designed] ## Layout Zones [To be designed] ## HUD Elements [To be designed] ## Dynamic Behaviors [To be designed] ## Platform Input Variants [To be designed] ## Accessibility [To be designed] ## Open Questions [To be designed]5.3 交互模式库骨架# Interaction Pattern Library **Status**: In Design **Author**: [user ux-designer] **Last Updated**: [todays date] **Template**: Interaction Pattern Library ## Overview [To be designed] ## Pattern Catalog [To be designed] ## Patterns [Individual pattern entries added here as they are defined] ## Gaps Patterns Needed [To be designed] ## Open Questions [To be designed]写完骨架后更新production/session-state/active.mdTask: Designing [screen/flow name] UX specCurrent section: Starting (skeleton created)File: design/ux/[filename].md这一骨架先行策略与 docs/COLLABORATIVE-DESIGN-PRINCIPLE.md 中的增量写作协议完全一致——完整设计文档若在会话内累积 8 个章节 × 2~3 轮修订会产生 30k~50k token 的对话量而边批准边写盘把已完成章节持久化到文件能让实时上下文保持在 3k~5k token。决策进文件上下文可压缩这是整套方法论能支撑长会话的工程基石。6. 逐节协作写作循环Phase 4骨架就位后按顺序逐节推进。每个章节都遵循同一循环Context - Questions - Options - Decision - Draft - Approval - WriteContext上下文说明本章节需要包含什么并抛出 Phase 2 采集到的相关约束。Questions提问问清起草本节所需的信息。受限选择题用AskUserQuestion开放式探索用对话文本。Options选项存在设计取舍时给出 2–4 个方案并附利弊用AskUserQuestion捕获决策。Decision决策用户选定方案或给出自定义方向。Draft草稿在对话中写出章节内容供审阅显式标记临时性假设。Approval批准Does this capture it? Any changes before I write it to the file?Write写入用Edit把[To be designed]占位符替换为已批准内容并确认。每写完一节更新production/session-state/active.md。正是这种逐节写盘让第 11 节描述的中断恢复成为可能。6.1 Section APurpose Player Need目的与玩家需求这是整个规格的地基Every other decision flows from it其他所有决策都由它派生。要问的问题What player goal does this screen serve? What is the player trying to DO here?What would go wrong if this screen didnt exist or was hard to use?补全这句话The player arrives at this screen wanting to ___.本节要与 Phase 2 采集的玩家旅程交叉引用——写明的目的必须与旅程阶段和情绪状态一致。ux-spec.md 模板 对本节给出了更强的写法要求从玩家视角写需求而不是从开发者视角。坏例子Displays the players current items and equipment.显示玩家当前物品与装备好例子Lets the player understand what theyre carrying and quickly decide what to take into the next encounter, without breaking their mental model of the game world. 模板还要求区分三个层面玩家目标一句话具体到能写验收标准、游戏目标系统需要从这次交互中获得什么、以及一段落的人类真实需求描述。6.2 Section BPlayer Context on Arrival到达时的玩家上下文问题清单玩家在游戏的什么时候第一次遇到此屏幕到达前他们刚在做什么设计应假设的情绪状态是什么冷静、紧张、好奇、时间压力玩家是自愿到达此屏幕还是被游戏强制送来的如果玩家旅程文档存在主动提议对照旅程阶段进行映射。模板 ux-spec.md 用一张六问表格把到达上下文量化刚在做什么、情绪状态、正在承受的认知负荷、已掌握的信息、最可能想做的事、最可能害怕的事如错过东西、做出不可逆错误、丢失位置感并据此写出本屏幕的情感设计目标——例如Confident and in control自信且掌控全局。6.3 Section B2Navigation Position导航位置用一段话描述此屏幕在导航层级中的位置而不是完整流程图。问题从主菜单、暂停、游戏内还是另一个屏幕进入是顶层目的地始终可达还是上下文相关目的地仅在特定状态可达玩家能否从游戏中的多个位置到达此屏幕呈现格式This screen lives at: [root] → [parent] → [this screen] 并附任何替代入口路径。模板用缩进树展示层级并要求声明模态行为Modal / Non-modal / Overlay / Overlay-live——若是模态必须记录关闭方式Back/B、Escape、点击外部、还是必须完成。6.4 Section B3Entry Exit Points入口与出口枚举玩家到达和离开此屏幕的每一种方式到达方式有哪些每个触发器按钮、游戏事件、其他屏幕重定向等玩家如何退出退出时发生什么返回按钮、确认动作、超时、游戏事件是否存在单向出口——退出后无法返回除非重新开始呈现为两张表Entry SourceTriggerPlayer carries this context[screen/event][how][state/data they arrive with]Exit DestinationTriggerNotes[screen/event][how][any irreversible state changes]模板强调入口表与出口表就是本屏幕与导航系统之间的契约未定义就位的行为会在实现期变成 bug——玩家卡死、游戏状态不一致。Empty cells are a sign that design work is unfinished.空格是设计未完成的信号。6.5 Section CLayout Specification布局规格这是最大、交互最密集的章节按四个子节推进子节 1 — Information Hierarchy信息层级先请用户列出此屏幕必须传达的每条信息再排序What is the single most important thing a player needs to see first? What is second? What can be discovered rather than immediately visible? 进入分区前先批准层级。子节 2 — Layout Zones布局分区基于信息层级提出粗略屏幕分区页头、内容区、操作栏、侧栏等给出 2–3 种分区方案并附理由参考游戏概念中的平台与输入上下文然后问Do any of these match your mental image, or shall we build a custom arrangement?子节 3 — Component Inventory组件清单为每个分区列出其包含的 UI 组件每个组件记录组件类型按钮、列表、卡片、数值显示、输入框等、显示内容、是否可交互、是否使用模式库中的现有模式按模式名引用、是否引入新模式标记为稍后加入模式库。子节 4 — ASCII WireframeASCII 线框图主动提议基于分区与组件清单生成 ASCII 线框图用AskUserQuestion询问Want an ASCII wireframe as part of this spec? 选项为Yes, include one或No, Ill attach a separate file。如果生成先在对话中产出并征求反馈再写入文件。模板对此给出了可直接复用的 ASCII 线框约定┌ ┐ └ ┘ │ ─用于边框、╔ ╗ ╚ ╝ ║ ═用于强调/模态边框、[ ]表示交互元素、{ }表示内容区、...表示可滚动内容、●表示打开时的聚焦元素。分区定义表含名称、描述、近似尺寸、是否可滚动、溢出行为五列组件清单表则是实现任务清单的来源——each row becomes a component to build or reuse每行都会变成一个要构建或复用的组件。6.6 Section DStates Variants状态与变体引导用户超越幸福路径逐个提问玩家第一次看到、尚无数据时是什么样空状态出错时——错误、失败动作、缺失资源时发生什么错误状态此屏幕是否有加载等待如有显示什么加载状态是否存在改变屏幕内容的玩家进度状态锁定内容、付费内容、教程模式覆盖层此屏幕在不同平台上是否表现不同平台变体收集后以表格形式呈现供批准State / VariantTriggerWhat ChangesDefaultNormal load—EmptyNo data available[content area description][etc.][trigger][changes]模板用一张七列状态表把状态矩阵即 QA 测试矩阵的理念落地——每个状态都要写清触发条件、视觉变化、行为变化与备注例如空状态不要显示禁用按钮直接移除Drop 确认必须用模态而非内联开关物品丢弃后不可恢复错误状态记录日志但不要向玩家暴露技术细节。6.7 Section EInteraction Map交互映射对布局规格中识别的每个交互组件定义动作点击、轻触、按下、按住、滚动、拖拽触发它的平台输入鼠标点击、手柄 A 键、键盘回车即时反馈视觉、音频、触觉结果导航目标、状态改变、数据写入使用 Phase 2h 从technical-preferences.md加载的输入方式不要重复询问。开始前先声明Mapping interactions for: [Input Methods from tech-prefs]. Covering [Gamepad Support] gamepad support. 逐个组件推进而非一次问完对于导航动作验证目标是否与已有 UX 规格匹配否则记为规格依赖。模板用三张表展开导航输入表方向键/D-pad、Tab/R1、鼠标悬停、点击、触屏轻触各列输入、平台、动作、视觉响应、音频提示、备注、动作输入表含上下文要求、动画、时长、音频例如Esc/B/Back 关闭屏幕并返回200ms 滑出关闭前提交所有变更——背包不是草稿、状态特定行为表加载态、确认弹窗打开态、错误态各自的输入限制。6.8 Section E2Events Fired事件触发对交互映射中的每个玩家动作记录游戏或分析系统应触发的事件——或显式注明无事件。问题每个动作是应触发分析事件、游戏状态变更还是两者都要是否有不应触发事件的动作——这是否是刻意选择与交互映射并列呈现Player ActionEvent FiredPayload / Data[action][EventName] or none[data passed with event]标记任何修改持久游戏状态存档、进度、经济的动作——这些需要架构团队明确关注。模板在 ux-spec.md 第 9 节补充了接收者系统列并给出请求/确认的事件模式范例UI 发EquipItemRequested装备系统校验后发EquipmentChangedUI 监听后者刷新显示——UI 永远不直接写系统状态。6.9 Section E3Transitions Animations转场与动画指定屏幕如何进入、退出以及如何响应状态变化。问题屏幕如何出现淡入、从右滑入、瞬时弹出、从按钮缩放如何关闭淡出、滑回、硬切是否有需要动画的屏内状态转场加载转圈、成功状态、错误闪烁是否有会引起晕动症的动画——游戏是否有减少动态选项最低要求屏幕进入转场、屏幕退出转场、以及若屏幕有多个状态至少一个状态变更动画。模板给出八行转场表触发、方向/类型、时长ms、缓动、是否可打断、是否被减少动态跳过——例如屏幕进入从右滑入 250ms ease-out cubic进入完成后才允许交互减少动态时 0ms 瞬时出现。6.10 Section FData Requirements数据需求交叉引用 Phase 2 收集的 GDD UI Requirements。对屏幕显示的每条信息问数据来自哪里哪个系统拥有它此屏幕需要写回数据还是只读是否有时间敏感或实时数据血条、冷却计时器架构红线任何 UI 需要拥有或管理游戏状态的情况都要标记为架构问题。UX 规格定义 UI 需要什么不规定数据如何送达——那是架构决策。呈现为表格DataSource SystemRead / WriteNotes[item][system]Read—[item][system]Write[concern if any]模板用五列表格数据元素、来源系统、更新频率、拥有者、格式、空值处理并写死一条规则This screen must never write directly to any system listed above.此屏幕绝不直接写入上述任何系统。这在架构层面隔离了 UI 与游戏状态——UI 读数据、发事件系统更新自己的数据并通知 UI。6.11 Section GAccessibility无障碍交叉引用design/accessibility-requirements.md如存在走一遍 ux-designer 的标准清单纯键盘导航路径覆盖所有交互元素手柄导航顺序如适用文本对比度与最小可读字号不依赖颜色单独传达信息非文本元素的屏幕阅读器考虑任何需要减少动态替代方案的动效用AskUserQuestion澄清无障碍层级问题Has the accessibility tier been committed to for this project?Yes, read from requirements docNot yet — lets flag it as a questionSkip accessibility section for now6.12 Section HLocalization Considerations本地化考虑记录影响翻译后文本行为的约束。问题此屏幕上哪些文本元素最长布局能容纳的最大字符数是多少是否有文本长度对布局关键的要素——例如必须保持单行的按钮标签是否有需要区域格式化的数字、日期或货币元素关键规则标记任何在 40% 文本膨胀英译德/法常见下会破坏布局的元素标为本地化工程师的 HIGH PRIORITY。模板进一步给出四条通则全部文本至少容忍英文基线 40% 膨胀、阿拉伯/希伯来文需镜像布局、中日韩文本可能短 20-30% 需验证布局不显空、不得在图片中使用文本以及一张五列表格文本元素、英文基线长度、最大字符数、膨胀预算、RTL 行为、溢出行为、风险等级——例如Equip5 字符在德文 Ausrüsten9 字符下膨胀 180%需规划 90% 最小字号再截断。6.13 Section IAcceptance Criteria验收标准写至少5 条具体、可测试的标准QA 测试员无需阅读任何其他设计文档即可验证。这些是/story-done的通过/失败条件。用复选框格式每条必须可由人工测试员验证- [ ] Screen opens within [X]ms from [trigger] - [ ] [Element] displays correctly at [minimum] and [maximum] values - [ ] [Navigation action] correctly routes to [destination screen] - [ ] Error state appears when [condition] and shows [specific message or icon] - [ ] Keyboard/gamepad navigation reaches all interactive elements in logical order - [ ] [Accessibility requirement] is met — e.g., all interactive elements have focus indicators最低要求1 条性能标准加载/打开时间、1 条导航标准至少验证一个入口或出口路径、1 条错误/空状态标准、1 条无障碍标准按承诺层级、1 条针对此屏幕核心用途的标准。完成后确认Do these criteria cover what would actually make this screen done for your QA process?7. HUD 设计模式先哲学后布局HUD 设计与 UX 规格模式的顺序不同——从哲学开始信息架构完成前不碰布局。7.1 HUD PhilosophyHUD 哲学让用户用 1–2 句话描述游戏与屏上信息的关系。提供框架示例Nearly HUD-free——氛围要求无遮挡沉浸例Hollow Knight、FirewatchMinimal but present——只显示关键信息其余全部上下文化例Dark SoulsInformation-dense——所有决策相关信息常显例Diablo IV、StarCraft IIAdaptive——HUD 密度响应战斗状态、探索模式与菜单例God of War该哲学成为后续每个 HUD 决策的设计约束若某个提议元素与既定哲学冲突必须主动指出冲突。7.2 Information Architecture信息架构布局前必须完成不可跳过。第 1 步 — 完整信息清单从 Phase 2 收集的所有 GDD UI Requirements 中抽取全部信息呈现完整列表These are all the things your game systems say they need to communicate to the player on screen.第 2 步 — 分类让用户逐项分类类别描述Must Show始终可见玩家核心决策需要Contextual仅在相关时可见战斗中、靠近可交互物等On Demand玩家必须主动请求开关、按住按钮Hidden通过世界/音频传达永不上屏文本用AskUserQuestion每次推进 3–4 项不要一次全问。这是 HUD 中后果最严重的设计决策不能急。冲突检查如果哲学是几乎无 HUD但 Must Show 列表越来越长显式指出冲突The current Must Show list has [N] items. That may conflict with the HUD-free philosophy. Options: reduce the Must Show list, revise the philosophy, or define a hybrid approach where HUD is absent in exploration and present in combat.7.3 后续章节Layout Zones布局分区只有信息架构批准后才做。依据哪些是 Must Show驱动永久分区决策、玩家注意力自然落点动作游戏居中、策略游戏角落、平台与宽高比目标。给出 2–3 种方案并附理由。HUD ElementsHUD 元素每个元素写明名称与类别、显示内容、视觉形式条、数字、图标、计数器、地图、更新行为实时、事件驱动、玩家查询、上下文触发条件、动画行为低值时是否脉冲淡入砸入。逐元素推进必要时引用模式库。Dynamic Behaviors / Platform Variants / Accessibility与 UX 规格对应章节同构见 6.6–6.11HUD 特别强调什么导致 HUD 在游戏中途改变密度移动端/主机是否需要不同的元素尺寸或位置模板 hud-design.md 为 HUD 模式补充了大量可落地的量化工具布局分区表含中心 40% 屏幕区域是玩家主焦点区保持尽可能干净的硬规则、各平台安全区边距表PC 窗口 0%、PC 全屏 3%、主机电视 10%、Steam Deck 5%、移动竖屏顶部 15%、移动横屏左右各 15%、Visual Budget视觉预算最大同时活动元素 8 个、探索模式 HUD 占比 ≤12%、战斗模式 ≤22%、中心区占比 ≤5%、HUD 文字最小对比度 4.5:1、背景面板最大不透明度 65%、通知队列规则战斗感知队列、500ms 内同类型合并、关键通知永不入队、字幕规格默认开启、底部居中、每行最多 42 字符、最多 2 行、说话人用冒号前缀而非颜色、背景 70% 黑面板、最小 24px、字幕比语音多保留 300ms以及Tuning Knobs 参数表通知时长 2000ms/500–5000ms、低血量脉冲 1Hz/0.5–2Hz、探索 HUD 淡出延迟 10s/3–30s、小地图范围 80/40–200 世界单位等并明确每个新增 HUD 元素必须声明它影响哪条预算、新总额是多少、压缩哪个现有元素。8. 交互模式库模式目录驱动、增量添加模式库写作是加法式、目录驱动的不是线性流程。8.1 Phase 1盘点现有模式Globdesign/ux/*.md排除interaction-patterns.md读取每个规格的 Component Inventory 与 Interaction Map 章节抽取所有使用中的交互模式。呈现抽取列表Based on existing UX specs, these patterns are already in use in the game:然后问Are there patterns you know exist but arent in existing specs yet? List any additional ones now.8.2 Phase 2为每个模式建立正式条目对每个模式现有或新增按以下模板记录### [Pattern Name] **Category**: Navigation / Input / Feedback / Data Display / Modal / Overlay / [other] **Used In**: [list of screens] **Description**: [One paragraph explaining what this pattern is and when to use it] **Specification**: - [Component behavior] - [Input mapping] - [Visual/audio feedback] - [Accessibility requirements for this pattern] **When to Use**: [Conditions where this pattern is appropriate] **When NOT to Use**: [Conditions where another pattern is more appropriate] **Reference**: [Screenshot path or ASCII example, if available]【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考