设计师自述：我用Claude比用Figma还多

很长一段时间我对LLM持怀疑态度——每次尝试都让我失望。去年我试了Copilot和Cursor来调整自己做的游戏，但都没能生成可用的改动。上一份工作中，我尝试用Gemini写产品简报和生成线框图，最后全扔了。

每次我尝试LLM，都是在我已经擅长的事情上，结果它们做得比我自己还差。今年夏天加入Jane Street后，我发现AI支持不可或缺。有太多东西对我来说是新的，有太多我还不擅长，比如OCaml和Bonsai。

但最大的惊喜是，它改变了我最擅长的事情：我的设计工作流。我不再费力写规格文档、做Figma原型、写提案、和开发一起审查实现，而是直接构建原型功能，精确实现我脑海中的想法。

实际操作是这样的：- 写下问题描述和我的方案- 打开编辑器，启动构建、服务器和Claude，用刚才写的描述作为提示词- 实现基本功能，向自己证明可行- 随心所欲地迭代- 把改动推送到开发环境，

问用户意见- 提交一个外观和行为完全符合我预期的功能（相当于我们的pull request）在实际代码库中做原型功能，几乎在各方面都比mockup和文档更好。

以我最近做的一个原型为例：给JSQL输入添加LLM提示功能（JSQL是一种内部SQL方言，用于很多面向用户的工具）。这个原型真的能跑，我花了好几天使用和测试它。Claude给了我免费、无限的迭代，当我第50次改变主意或要求小调整时，它毫无怨言。

我改进了提交按钮、添加了键盘快捷键、调整了文案、优化了提示词、添加了生成的确认消息。这些工作流改进在我上一份工作中需要花数天甚至数周的工程和设计来回沟通，更可能根本不会发生。所有精力都花在改进真正的产物上，没有花在创建Figma组件或格式化文档这类辅助中间工作上。

我花了一段时间才摸索出这个工作流。

去年夏天刚加入时，我只用AI处理小任务，比如UX小修小补。对于更大的想法，我仍然用Figma和文档，尝试用Claude做那些事时失败了。但过去两个月里，我使用Figma的情况急剧减少。

通过改进的模型、我自己对工具的熟练度以及精心选择合适范围，AI现在也能处理大项目了——不仅是JSQL提示功能，还有另外六七个原型，涉及面向用户、数据模型和库的改动，有些差异超过2000行；我用它来实现全新应用的交互式原型，先在Figma设计，然后用Claude实现；

对于一些新应用，我甚至完全跳过Figma，从一开始就用Claude迭代视觉设计。作为设计师，这让我感到很有力量。工程师有想法时能直接做出可工作的概念验证。设计师却需要说服别人替我们做。对于像“在JSQL输入中直接LLM提示”这样的想法，我提出的东西可行性一开始都不清楚；

让别人做原型可能浪费他们的时间。其他情况下，我可能提出一些没有明确满足用户需求的东西。通过用Claude把这些想法变成现实，我让别人更容易评估它们——他们可以直接试用。但有一个缺点：在这个工作流中，审阅者拿到的是一个完整的功能。

这是否意味着他们对功能没有输入，只能审查代码？审查不是最有趣的工作——在设计领域，相当于从PM那里拿到一个详细的线框图，然后被要求把它做漂亮。

我希望尽可能清晰完整地提出方案，但我仍然希望工程队友像对待Figma中的mockup一样对待它，作为他们和我可以在设计空间中共同迭代的东西。我们目前的解决方案是换个角度看待这些功能。

我在描述中写了一个简短提醒：原型是活的提案文档，代码是一次性的，审阅者的工作是提供关于设计和用户体验的反馈。最终，审阅者仍然会接手这个想法，在单独的功能中实现它，参考原型但拥有生产代码。实践中，我们仍在摸索这个新工作流中什么合理、什么感觉好。

我还有一个担忧：用Claude设计可能让我失去流畅、创造性的思维，陷入迭代思维，受限于我认为Claude能产出的结果。这对成熟的工具没问题，因为改动是迭代式的，但可能让我在处理新事物时错过想法。

这是一种熟悉的张力。2011年我刚入行时，有很多关于设计师是否应该写代码的讨论。

批评者认为，一旦开始编程，你就不太可能对想法做大改动。但我喜欢做网站，也喜欢编程，所以我一直写代码。后来，像React这样的前端框架变得普遍，前端开发变得更复杂，我和其他人一样决定专精。

我仍然用React做个人项目——这当然帮助我和开发人员互动——但工作中几乎所有时间都花在Figma和文档上。如果我在LLM出现之前加入Jane Street，我想我会更加深陷在Figma中。至少我对JavaScript有些经验；

OCaml和Bonsai完全是新的，在技术层面做出贡献感觉遥不可及。而现在，我又回到了制作真正的东西，再次在这个媒介中工作感觉太棒了。我觉得比以往任何时候都更自由，可以大胆尝试。