如果要判断一种交互是否可行，粗糙的界面可能比精致的界面更适合作为产品设计工具。在 Deel，设计师用快速生成的 AI 原型测试想法，再确定需求。概念经得起检验后，他们会转向使用 Deel UI 组件构建的代码原型，此时细节和边界情况更为重要。
先测试交互，再打磨界面
一个早期的对账项目需要在两种方案之间做选择：让用户通过拖动交易记录，将其与对账单条目匹配，还是在固定的并排表格中选择匹配项？一名设计师用 AI 网页应用生成工具 Lovable，为两种方案分别制作了可点击的版本。这些早期界面看起来很粗糙，也没有遵循 Deel 正式产品的设计系统。
缺少精细打磨有其用意。在核心问题尚未得到解答时，精致的界面可能让人把注意力放在颜色、字体排版或间距上。粗略版本让团队更容易讨论如何找到匹配项并确认匹配。内部用户测试更倾向于表格方案：在这个场景中，它比拖放方式更能减少人为失误。
▲ 交易匹配的两种方式
这个概念原型的提示词编写工作耗时不到两小时。再配上一段约两分钟的 Loom 操作演示，可点击原型就能在一到两天内获得利益相关方的验证，而完整的产品需求文档（PRD）此时尚未定稿。这个时间点很重要：团队可以趁交互方案仍可舍弃时修改它，而不是带着未经验证的想法进入工程规划。
粗糙不等于草率。原型仍需具备足够的交互行为，让人们尝试团队正在权衡的方案。只是要回答第一个问题，它不必看起来像已经完成的软件。
根据问题选择流程
并非 Deel 的每个项目都从原型开始。有些项目从一个需要快速测试的拟议方案起步；更复杂的工作则从调研开始。AI 可以帮助整理研究资料、探索规律，但不能取代对系统的理解，也不能代替相关负责人达成共识。
在一项资金管理系统的工作中，设计师先在 FigJam 中梳理利益相关方、支付流程、会计要求和边界情况，再确定界面方案。这些图也记录了银行合作伙伴和 API 带来的约束；API 是软件系统交换信息的接口。在支付流程中，一个看似细微的界面决策可能产生界面之外的后果，包括客户付款失败，或劳动者拿不到报酬。
Deel 还使用内部 AI 工作流平台，将访谈记录、问卷调查和其他研究材料转化为结构化报告。其研究工作流会检查问题背景、输入材料是否完整、翻译是否准确，以及建议是否可执行。报告可以加快研究结果的梳理，但设计团队仍须判断这些发现对产品意味着什么。
将经过验证的想法纳入设计系统
当一个概念需要更贴近实际产品的测试时，设计师会使用 Deel UI Playground。这是由 Deel 工程团队搭建的内部 GitHub 仓库，包含 Deel UI 设计规则、依赖项和有文档说明的组件。设计师向 Claude Code 提供需求、流程图和组件文档，生成可交互的 React 界面。React 是用于构建这些原型界面组件的软件库。
▲ 代码实现的界面原型
这两个阶段的区别很重要。Lovable 制作的草稿可以帮助判断某种交互是否值得继续投入。Playground 原型则能呈现这种交互在更接近工程师实际使用的组件和约束条件下如何运行。工程师可以检查生成的代码，也可以通过拉取请求接收代码，完成交接。
Checks Module 展示了为什么需要这个更深入的阶段。其原型包含支票列表、状态筛选器、用于创建支票的抽屉式面板，以及 CSV 批量上传工具。CSV 是“逗号分隔值”的缩写，是一种用于表格数据的文件格式。内部用户可以尝试上传、编辑银行账户，并模拟批准或拒绝。走完这些流程后，一些集成问题浮现出来，包括服务提供商 API 的响应时间，以及排队中、已寄出、已兑现和已对账等支票状态。
代码原型仍需仔细审查。如果 Claude Code 生成了错误的组件或样式，设计师可以从 Storybook 提供准确的规范和组件代码。Storybook 是用于记录和检查界面组件的工具。Deel UI 的规则有助于约束生成结果，但设计师仍须发现内边距、圆角半径或字体排版不一致等细节问题。如果利益相关方把可运行的原型误认为已经完成的软件，高保真度也可能造成误导，因此需要明确原型所处的阶段。
无需等待会议，也能评审交互
Deel 的评审流程会在 Slack 讨论串中同时分享可运行的原型链接和简短的 Loom 操作演示。产品经理、工程师和设计师可以跨时区检查交互行为并发表评论。一条关于 Checks Module 的评审讨论串有 23 人参与。工程师指出了边界情况、缺失的校验规则和 API 状态，AI 则帮助将评论汇总为下一轮代码修改的待办事项。
与只评审静态界面相比，这种方式让反馈更具体：参与者可以亲自尝试一个流程，并指出实际发生了什么。它不会让所有评审自动完成，也不能省去调研。但它能在决策尚未确定时，为团队提供一个共享、可测试的对象。
下一个原型该怎么做
实践中的要点是：选择能回答当前问题的最小成果。如果不确定交互本身是否可行，就先用纯文本描述用户目标，再制作粗略的可点击概念原型。如果工作涉及支付、服务提供商或其他复杂依赖关系，就先梳理系统流程和约束。概念通过初步验证、值得接受更贴近实际产品的测试后，再使用有文档说明的设计系统组件构建原型，并分享可运行的链接和简短的操作演示。
粗略版本应当随时可以舍弃，代码版本则应保持可修正的状态。无论是精致的界面，还是 AI 生成的代码，本身都不是目标；目标是弄清楚应该构建什么，并让负责构建的人有具体的东西可供检验。