Back to Details

html-prototype

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

HTML Prototype

HTML原型

Build a credible model of a product decision. Match the artifact to the user's context instead of applying a recurring house style. The goal is not to make every possible screen. The goal is to make the important visual or behavioral question testable.
构建产品决策的可信模型。根据用户背景生成产物，而非套用重复的固定风格。目标并非制作所有可能的界面，而是让重要的视觉或行为问题可被测试。

Choose the fidelity mode

选择保真模式

Use one of two modes:
  • Mockup: Create a polished, responsive, mostly static artifact when the open question is visual hierarchy, layout, typography, color, or product fit.
  • Prototype: Create a working flow when the open question is navigation, input, state change, feedback, recovery, or transition.
Do not create a separate 
html-mockup
skill. Do not add behavior merely to make a mockup seem more complete. If a user asks for both modes, preserve the same content and structure so changes in fidelity remain easy to compare.
可选择以下两种模式之一：
  • Mockup（静态原型）： 当待解决问题涉及视觉层级、布局、排版、色彩或产品适配时，生成精致、响应式且以静态为主的产物。
  • Prototype（交互式原型）： 当待解决问题涉及导航、输入、状态变更、反馈、恢复或过渡效果时，生成可运行的交互流程。
请勿创建独立的
html-mockup
技能。请勿仅为让mockup看起来更完整而添加额外交互。若用户同时要求两种模式，需保留相同的内容和结构，以便轻松对比不同保真度的差异。

Derive the direction from context

从背景信息中确定设计方向

Inspect the conversation, supplied references, and project before designing. Look for design-system documentation, tokens, existing components, product screenshots, and nearby artifacts.
Authority runs in this order:
  1. The user's explicit visual and functional instructions.
  2. The project's established design language and interaction conventions.
  3. The product, audience, content, and scenario.
  4. Your own design judgment.
Before coding, settle:
  • the user and critical job;
  • the bounded scenario under review;
  • mockup or prototype mode;
  • the source of the visual direction;
  • the relevant state model;
  • the point where the real product would take over.
When no design system exists, create a specific direction from the subject and use case. Do not default to a gradient, a dark dashboard, interchangeable cards, or decorative metrics. A prototype for a field tool, an editorial workflow, and a financial approval should not feel like the same product.
When 
design-artifact
 is available and the visual direction remains open, read and compose it with this skill. Use it to choose the register, palette, type, and composition; keep this skill authoritative for fidelity, state, and interaction completeness.
设计前需查看对话记录、提供的参考资料及项目信息。寻找设计系统文档、设计令牌（tokens）、现有组件、产品截图及相关产物。
优先级顺序如下：
  1. 用户明确提出的视觉与功能要求。
  2. 项目已确立的设计语言和交互规范。
  3. 产品、目标受众、内容及使用场景。
  4. 自身的设计判断。
编码前需确定以下事项：
  • 用户群体及核心任务；
  • 待评审的限定场景；
  • 使用mockup还是Prototype模式；
  • 视觉设计方向的来源；
  • 相关状态模型；
  • 真实产品将接管的节点。
若不存在设计系统，则根据主题和使用场景创建专属设计方向。请勿默认使用渐变、深色仪表盘、可互换卡片或装饰性指标。现场工具、编辑工作流和财务审批的原型不应给人相同的产品感受。
当
design-artifact
技能可用且视觉方向尚未确定时，需结合该技能进行解读和创作。利用它来选择风格基调、调色板、字体及布局；本技能在保真度、状态及交互完整性方面拥有最终决定权。

Scope one credible experience

聚焦可信的体验范围

Choose the smallest flow that can answer the review question. Use realistic, internally consistent names, dates, statuses, quantities, and copy.
  • Make navigation work for the modeled scope.
  • Implement forms with labels, validation, submission feedback, and sensible defaults.
  • Use dialogs only when interruption or confirmation is part of the scenario.
  • Use transitions to clarify continuity or state change, not as decoration.
  • Remove dead buttons. If an action belongs to the real system, explain the boundary instead of pretending it completed.
选择能解答评审问题的最小流程。使用真实且内部一致的名称、日期、状态、数量及文案。
  • 确保导航在建模范围内可用。
  • 表单需包含标签、验证、提交反馈及合理的默认值。
  • 仅当场景需要中断或确认时才使用对话框。
  • 使用过渡效果来明确连续性或状态变化，而非作为装饰。
  • 移除无效按钮。若某操作属于真实系统范畴，需说明边界，而非假装该操作已完成。

Model relevant states

建模相关状态

List the states before building. Include the states that the chosen scenario can actually reach:
  • loading;
  • empty;
  • error;
  • success;
  • disabled;
  • mobile;
  • domain-specific states from the brief.
An asynchronous-looking prototype action should normally show loading, success, and failure or recovery. A collection should normally consider empty state. A gated action should show why it is disabled. Do not force irrelevant states into the main flow just to satisfy a checklist. Make omitted states explicit in the handoff.
构建前需列出所有状态。仅包含所选场景实际可达的状态：
  • 加载中；
  • 空状态；
  • 错误状态；
  • 成功状态；
  • 禁用状态；
  • 移动端状态；
  • 需求中提及的领域特定状态。
看似异步的原型操作通常需展示加载中、成功及失败/恢复状态。列表类组件通常需考虑空状态。受限操作需展示禁用原因。请勿仅为满足检查清单而将无关状态强行加入主流程。在交接时需明确说明未包含的状态。

Make interaction complete

确保交互完整性

  • Use native elements when they provide the right semantics.
  • Support the entire modeled flow with a keyboard.
  • Keep focus visible and place it deliberately after meaningful transitions.
  • Give dialogs an accessible name, contain focus, close on 
    Escape
    , and restore focus to the trigger.
  • Associate form errors with their controls and announce important status changes.
  • Do not hide essential behavior behind hover.
  • Respect 
    prefers-reduced-motion
    while preserving state feedback.
  • Make touch targets usable and prevent accidental page-level horizontal overflow.
In mockup mode, preserve semantic structure and visible focus styles even if the controls are not wired. Make the static review boundary clear.
  • 当原生元素具备合适语义时优先使用。
  • 支持通过键盘完成整个建模流程的操作。
  • 保持焦点可见，并在重要过渡后刻意设置焦点位置。
  • 为对话框设置无障碍名称，限制焦点范围，支持按
    Escape
    关闭，并在关闭后将焦点恢复至触发按钮。
  • 将表单错误与对应控件关联，并提示重要状态变更。
  • 请勿将核心交互隐藏在悬停操作之后。
  • 在保留状态反馈的同时，尊重
    prefers-reduced-motion
    设置。
  • 确保触控目标可操作，并防止意外的页面水平溢出。
在mockup模式下，即使控件未绑定交互，也需保留语义结构和可见的焦点样式。明确静态评审的边界。

Build contract

构建规范

  • Deliver one self-contained 
    .html
    file with essential CSS and JavaScript inline.
  • Require no build tooling, authentication, live API, or external service.
  • Use a responsive composition rather than shrinking a desktop canvas.
  • Keep design tokens small and specific to the chosen direction.
  • Use accessible contrast and more than color alone to communicate state.
  • Prefer depth and correctness in one flow over breadth across a fake product.
  • 交付单个独立完整的
    .html
    文件，必要的CSS和JavaScript需内嵌其中。
  • 无需依赖构建工具、身份验证、实时API或外部服务。
  • 使用响应式布局，而非直接缩小桌面端画布。
  • 设计令牌（tokens）需精简且符合所选设计方向。
  • 使用符合无障碍标准的对比度，且不单独依赖颜色来传达状态。
  • 优先保证单个流程的深度和正确性，而非追求虚假产品的广度。

Verify and hand off

验证与交接

Test the artifact at wide desktop and narrow mobile widths. Exercise every modeled state and control. Test 
Tab
, 
Shift+Tab
, 
Enter
, 
Space
, arrow keys where appropriate, and 
Escape
for dialogs. Check the console, page overflow, long content, disabled behavior, focus restoration, and reduced-motion mode.
Inspect computed foreground and background colors on every distinct surface, especially text that may inherit the body color inside a dark or tinted region. If browser tooling is unavailable, say which visual and interaction checks remain unverified instead of treating source inspection as a substitute.
Return the absolute file path, the fidelity mode, the scenario modeled, the states implemented, and the production behavior deliberately left out.
在宽屏桌面端和窄屏移动端测试产物。测试所有建模状态和控件。测试
Tab
、
Shift+Tab
、
Enter
、
Space
、适用的箭头键，以及对话框的
Escape
键。检查控制台、页面溢出、长内容、禁用行为、焦点恢复及减少动画模式。
检查每个不同区域的计算后前景色和背景色，尤其是深色或 tinted 区域内可能继承body颜色的文本。若无法使用浏览器工具，需说明哪些视觉和交互检查尚未验证，而非仅通过检查源代码来替代。
返回绝对文件路径、保真模式、建模场景、已实现的状态，以及刻意未包含的生产环境行为。

Further reading

延伸阅读

Read Plannotator's HTML wireframes and prototypes for coding agents for guidance on moving from an approved structure to a mockup or working prototype.
阅读Plannotator的《HTML wireframes and prototypes for coding agents》（https://docs.plannotator.ai/learn/code-context/html-wireframes-and-prototypes-for-coding-agents），获取从已批准的结构到mockup或可运行原型的构建指南。