收益：
- 能够利用人工智能快速生成原型骨架、样本内容和微交互创意
- 能够为原型生成真实的占位符文本和数据并在实际使用中测试设计
- 将 AI 输出转移到设计工具（Figma 等）时能够保持一致性和组件逻辑
原型是对设计的可点击、可导航的模仿；这是一种模拟，用户可以体验到与真实产品一样的体验。另一方面，高保真设计是在颜色、排版、真实内容和微交互方面更加接近最终产品的设计。此阶段的目标是使这个想法“就像它是真实的一样”可测试。人工智能在这方面的优势体现在三个方面：快速生成骨架和变体、提供真实的占位符内容和数据以及提出微交互想法。但是，在将输出转移到设计工具中时保持一致性和组件逻辑（即将系统融入系统而不使其混乱）是一项人类工作。
原型的目的：以低成本测试正确的问题
原型设计有一个目的：无需编写代码即可廉价地测试假设。 “用户理解这个流程吗？”，“这个布局是否加快了他的任务速度？”这就是为什么原型不必像真实产品一样完美；它必须足够真实才能令人信服地描述要测试的问题。
人工智能加速了这种可信度。但存在一个危险：高分辨率让人感觉“已经完成”了。当利益相关者看到完善的原型时，他们可能会误认为这是最终的决定；然而，这仍然是一个假设。始终明确说明原型正在测试哪些内容以及哪些内容仍处于开放状态。
注意：抛光的原型夸大了成熟度。如果您在向利益相关者展示时没有将其描述为“这是一个测试工具，而不是最终设计；我们正在测试这个问题”，则会产生错误的期望。
现实的内容：将原型从谎言中拯救出来
原型最大的谎言是完美的占位符，例如“Lorem ipsum”和“First Name Last Name”。在现实世界中，名字很长，列表有时是空的，数字有时是负数，日期有时是过时的。当原型充满了理想的内容时，它就隐藏了真正的问题。
这就是人工智能的价值所在：它产生真实的占位符内容和不同长度、不同状态的数据。您可以通过诸如“给我 20 个真实的产品名称，其中一些很长”、“编写 5 个不同的空案例场景”、“生成包括负余额的示例帐户数据”等请求，使原型更接近实际使用。因此，测试测试的是现实，而不是理想。
内容类型
假的（误导性的）
现实（人工智能）
名称
《姓名》
短名称、长名称、单个名称、特殊字符的示例
列表
总是满的
空白、1 项、100 元素变体
数量
总是积极的
零、负、非常大的值
文字
理想长度
标题过多，描述非常简短
日期
今天
过去、未来、“刚才”、“3年前”
微观互动：虽小但决定性的
微交互是微小的、单一的交互时刻，例如按下按钮时的反馈、填充时变为绿色的字段、加载动画等。这些让用户感觉“系统听到了我的声音”。人工智能是产生微交互想法（何时、反馈什么、状态改变）的良好头脑风暴伙伴。但每个微交互都必须在性能、可访问性和干扰方面进行权衡；花哨但不必要的动画会减慢体验。
三个迷你箱子
案例 1 — 订单因真实数据而崩溃。一个团队用人工智能生成的 30 个真实的（有些很长）产品名称填充了原型。两张卡片布局溢出；该问题在测试之前就被发现并修复了。教训：现实的内容会尽早发现隐藏的错误。
案例 2——经过打磨的原型造成了错误的期望。设计师准备了一个高分辨率原型用于“仅进行流程测试”，但在没有框架的情况下向利益相关者展示了它。利益相关者说“太好了，我们发布吧”；而可访问性和内容还不存在。教训：清楚地说明原型正在测试什么。
情况 3 — 组件一致性被破坏。 AI 的屏幕草图包含与设计系统中的按钮不同的按钮样式。当将其移植到 Figma 时，设计者忘记将其链接到系统组件；产品上有两个不同的按钮。教训：将输出移动到工具中时，必须将其连接到现有组件。
可复制的提示
为此屏幕生成真实的占位符内容：- 20 个<<元素类型>> 名称：有些太短，有些太长，一个带有特殊字符。- 4 个空案例场景。- 3 个极端数据示例（零、负、超大）。目的：以真实的、不理想的用法测试原型。上下文：<<屏幕/产品>>
建议此流程的原型框架（屏幕列表+每个屏幕中的主要元素）：任务：“<<任务>>”。我要测试的问题是：“<<假设>>”。建议足够的屏幕来测试这个问题；不要添加更多。
为此次交互提出 4 个微交互创意（按钮按下、现场验证、加载、成功）。对于每个：触发器、反馈、持续时间建议和辅助功能注释（动作灵敏度、屏幕阅读器公告）。上下文：<<交互>>
检查此屏幕草图是否与我的设计系统兼容：按钮、排版、间距和颜色是否符合我现有的组件规则（“<<摘要>>”）。列出每个不兼容的项目以及它应连接到哪个系统组件。草稿：<<正文>>
弱提示/强提示
弱：“给出这个原型的示例内容。”
结果是：理想的长度、统一的虚假内容隐藏了真正的问题。
Strong：“生成20个产品名称；有些太长，一个带有特殊字符；添加4个空案例和3个边缘数据示例；旨在通过实际使用来测试原型。”
结果：内容真正推动了布局，尽早发现错误。
区别：强烈的提示需要多样性+边缘案例+目的。
常见错误
- 用理想的内容进行测试。伟大的占位符隐藏了真正的问题。
- 将打磨好的原型误认为是最终决定。如果不进行框架设计，就会出现错误的期望。
- 添加不必要的屏幕。原型应该足以检验假设；太多就是浪费时间。
- 破坏组件逻辑。将系统组件运输到车辆时忘记连接系统组件会产生不一致的情况。
- 花哨但不必要的微交互。添加动画而不考虑性能和可访问性。
综上所述
原型设计是一种无需编写代码即可廉价测试假设的方法；高分辨率让它变得可信，但也造成了“完成”的错觉。人工智能通过快速的框架、逼真的占位符内容和微交互理念为这个阶段提供动力。它最有价值的贡献是多样化和极端的数据，使您可以在真实的而不是理想的环境中测试原型。人类有责任明确框架原型正在测试的内容，在将输出转移到设计工具时保持组件和样式的一致性。
应用任务
- 写一个您想要测试流程的假设句子。
- 根据第二个提示，创建一个足以检验该假设的原型骨架。
- 根据第一个提示，创建真实的、边缘情况占位符内容并填写原型。
- 根据第三个提示，生成 2-3 个微交互想法并评估可访问性注释。
- 根据第四个提示，检查并更正草稿以确保设计系统的一致性。
清单
- [ ]我把原型测试的假设写清楚了。
- [ ] 我用现实和边缘情况的内容进行了测试。
- [ ] 我将原型设计为利益相关者的“测试工具”。
- [ ] 我保留了足够的屏幕数量来检验假设。
- [ ] 我权衡了微交互与可访问性和性能。
- [ ] 我通过将输出绑定到系统组件来保持一致性。