Back to Details

html-wireframe

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

HTML Wireframe

HTML Wireframe

Turn a product question into a low-fidelity HTML artifact that is easy to inspect, change, and discuss. The wireframe should help reviewers decide what belongs on the screen and how the task should work. It should not look like a finished product.
将产品需求转化为易于检查、修改和讨论的低保真HTML制品。该线框应帮助评审人员确定页面应包含的内容以及任务的运作方式，不应看起来像成品。

Establish the review question

明确评审问题

Read the conversation, supplied brief, and nearby project material before choosing a layout. Reuse the project's vocabulary, content model, and known product constraints.
Authority runs in this order:
  1. The user's explicit instructions and accepted decisions.
  2. The product's existing structure and terminology.
  3. The user, task, and content being modeled.
  4. Your own layout judgment.
Before coding, identify:
  • the user and the job they need to complete;
  • the screen or bounded flow under review;
  • the information and actions the artifact must contain;
  • the assumptions that can be made safely;
  • the structural questions the wireframe should help answer.
Use real labels and representative content. Low fidelity is not permission to use anonymous boxes or lorem ipsum where wording affects the layout.
在选择布局前，先阅读对话内容、提供的简介以及相关项目资料。复用项目的词汇、内容模型和已知的产品约束。
优先级顺序如下：
  1. 用户的明确指示和已确认的决策。
  2. 产品现有的结构和术语。
  3. 所建模的用户、任务和内容。
  4. 自身的布局判断。
编码前，需明确：
  • 用户及其需要完成的工作；
  • 待评审的页面或限定流程；
  • 制品必须包含的信息和操作；
  • 可安全做出的假设；
  • 线框应帮助解答的结构问题。
使用真实标签和代表性内容。低保真并不意味着在措辞会影响布局的地方使用匿名框或乱数假文（lorem ipsum）。

Explore structure before style

先探索结构，再考虑样式

When 
design-artifact
 is available, read it for subject-specific composition and hierarchy guidance without importing editorial polish. This skill's low-fidelity contract remains authoritative.
When the layout is still unsettled, create two or three meaningfully different directions. Vary product decisions such as:
  • navigation model;
  • grouping and order;
  • primary-action placement;
  • content density;
  • overview versus step-by-step flow;
  • desktop-to-mobile reflow.
Do not call color changes or minor card rearrangements separate directions. Give each direction a short descriptive name and one sentence about its tradeoff.
Keep the directions in one HTML file when practical. Use a small, keyboard-operable selector so reviewers can compare them without opening several files. Preserve the same core content and task across directions. If the user has already chosen a structure, build that direction only.
当
design-artifact
可用时，阅读其中针对特定主题的构图和层级指导，但无需引入编辑层面的精致处理。本技能的低保真要求仍为首要准则。
当布局尚未确定时，创建两到三个有显著差异的方向。在产品决策上做出不同选择，例如：
  • 导航模式；
  • 分组与排序；
  • 主要操作的位置；
  • 内容密度；
  • 概览式与分步式流程；
  • 桌面端到移动端的回流布局。
请勿将颜色变化或卡片的微小重排视为不同方向。为每个方向起一个简短的描述性名称，并附上一句关于其权衡的说明。
在可行的情况下，将所有方向放在一个HTML文件中。使用一个小巧的、可通过键盘操作的选择器，以便评审人员无需打开多个文件即可进行比较。确保所有方向保留相同的核心内容和任务。如果用户已选定结构，则仅构建该方向。

Keep the artifact intentionally unfinished

保持制品的刻意未完成状态

  • Use a restrained grayscale palette, system type, plain borders, and simple blocks.
  • Avoid brand colors, gradients, shadows, illustrations, decorative imagery, and polished component styling.
  • Use limited radius and spacing. Enough order should be present to judge hierarchy, but not enough polish to invite a brand review.
  • Show images or rich media as labeled placeholders unless the asset changes a structural decision.
  • Add annotations only when they expose an assumption, open question, or behavior that cannot be shown directly.
The wireframe may still be well composed. Intentional unfinishedness is different from careless spacing, illegible type, or broken responsive behavior.
  • 使用简洁的灰度调色板、系统字体、普通边框和简单区块。
  • 避免品牌色彩、渐变、阴影、插图、装饰性图像和精致的组件样式。
  • 使用有限的圆角和间距。应具备足够的秩序性以判断层级，但精致程度不应引发品牌评审。
  • 除非资产会改变结构决策，否则将图片或富媒体显示为带标签的占位符。
  • 仅当注释能揭示假设、未解决问题或无法直接展示的行为时才添加注释。
线框仍可具备良好的构图。刻意未完成与随意的间距、难以辨认的字体或失效的响应式行为不同。

Add only useful behavior

仅添加有用的交互行为

Use basic click-through behavior when it helps test navigation, disclosure, or a short task flow. Keep it immediate and plain.
  • Make links, tabs, and next or back actions work when they are part of the review.
  • Use native controls and visible keyboard focus.
  • Do not build elaborate animation, persistence, simulated APIs, or production state management.
  • Remove controls that have no review purpose, or label them clearly as out of scope.
当基础的点击交互有助于测试导航、信息披露或短任务流程时，可添加此类功能。保持交互直接、简洁。
  • 当链接、标签页以及前进/后退操作属于评审范围时，使其可正常工作。
  • 使用原生控件并显示可见的键盘焦点。
  • 请勿构建复杂的动画、持久化存储、模拟API或生产级状态管理。
  • 删除无评审用途的控件，或清晰标注其超出范围。

Build contract

构建规范

  • Deliver one self-contained 
    .html
    file with essential CSS and JavaScript inline.
  • Require no build tooling or external service.
  • Use semantic landmarks, headings, lists, forms, and buttons.
  • Make the layout useful at wide desktop and narrow mobile widths.
  • Keep the page free of accidental horizontal overflow.
  • Respect the source material. Do not invent extra product scope to fill space.
  • 交付一个包含必要内联CSS和JavaScript的独立
    .html
    文件。
  • 无需构建工具或外部服务。
  • 使用语义化地标、标题、列表、表单和按钮。
  • 确保布局在宽屏桌面和窄屏移动设备上均可用。
  • 避免页面出现意外的水平溢出。
  • 遵循源材料。请勿为填充空白而额外增加产品范围。

Verify and hand off

验证与交付

Open the result at desktop and mobile widths. Check reading order, wrapping, overflow, focus visibility, and every implemented click path. Confirm that the directions remain structurally distinct at both sizes.
Return the absolute file path, the names and tradeoffs of the directions, and the visual decisions deliberately deferred to a later mockup or prototype.
在桌面端和移动端宽度下打开结果。检查阅读顺序、换行、溢出、焦点可见性以及每个已实现的点击路径。确认各个方向在两种尺寸下仍保持结构上的差异。
返回绝对文件路径、各方向的名称及其权衡说明，以及特意推迟到后续模型或原型阶段的视觉决策。

Further reading

延伸阅读

Read Plannotator's HTML wireframes and prototypes for coding agents for guidance on what to decide at the wireframe stage.
阅读Plannotator的HTML wireframes and prototypes for coding agents，了解在线框阶段应做出哪些决策。