메뉴
HN
Hacker News 52일 전

이제 피그마 대신 클로드로 디자인합니다

IMP
8/10
핵심 요약

한 때 LLM을 불신하던 저자가 최근 코딩 에이전트(Claude)를 활용해 피그마(Figma) 목업이나 기획서 없이도 직접 인터랙티브 프로토타입을 빠르게 구현하게 된 경험을 공유합니다. AI의 무한한 반복 수정과 코드 기반 프로토타이핕을 통해 기존의 디자인-개발 간 커뮤니케이션 비용을 획기적으로 줄이며 업무 워크플로우를 완전히 바꿨습니다. 이제는 AI를 활용해 타당성을 증명하는 실제 동작하는 기능을 직접 만들고 검증하는 새로운 디자이너의 역할을 보여줍니다.

번역된 본문

저는 이제 피그마보다 클로드로 더 많이 디자인합니다. 2026년 2월 5일 | 읽는 데 5분 Edwin Morris 작성

오랫동안 저는 LLM(대형 언어 모델)에 회의적이었습니다. 필요할 때마다 도움을 요청했지만 결과에 실망하기 일쑤였죠. 작년에는 제가 만든 게임을 수정해 보려고 Copilot과 Cursor를 사용해 봤지만, 제대로 작동하는 코드를 생성하지 못했습니다. 이전 직장에서는 제품 기획서 개요를 잡고 와이어프레임을 만들기 위해 Gemini를 써봤지만, 결국 다 폐기했습니다. 제가 LLM을 시도할 때마다 제가 이미 잘하는 분야에 대한 것이었고, AI는 저보다 못한 결과물을 냈죠.

지난여름 제인 스트리트(Jane Street)에 합류한 후, 저는 AI의 지원이 없어서는 안 될 정도로 필수적이라는 것을 깨닫게 되었습니다. 제게는 너무나 새롭고 아직 서툰 것이 너무 많았기 때문입니다. OCaml과 Bonsai 같은 것들이요. 하지만 가장 큰 놀라움은 내가 가장 잘하는 분야인 '디자인 워크플로우'를 얼마나 크게 바꿔놓았는가 하는 점입니다.

이전에는 명세서 작성에 매달리고, 피그마 목업을 만들고, 제안서를 작성한 뒤 개발자들과 구현 사항을 검토하느라 고생했습니다. 하지만 지금은 제 마음속에 있는 것을 정확하게 구현해 내는 '프로토타입 기능'을 직접 만들고 있습니다. 실제로 어떻게 작동하는지 보자면 다음과 같습니다:

  1. 문제와 나의 제안을 설명하는 글을 작성합니다.
  2. 에디터를 열고 빌드를 시작하며 서버와 클로드를 실행할 때, 내가 작성한 그 설명을 프롬프트로 사용합니다.
  3. 기본 기능이 작동하게 만들어 스스로 가능성을 증명합니다.
  4. 원하는 만큼 이를 반복해서 수정(Iterate)합니다.
  5. 변경 사항을 개발 환경에 푸시하고 사용자들에게 어떻게 생각하는지 물어봅니다.
  6. 내가 원하는 모습과 동작을 정확히 구현한 기능(PR)을 제출합니다.

실제 코드 베이스에 있는 프로토타입 기능은 목업이나 문서와 비교했을 때 거의 모든 면에서 더 좋게 느껴졌습니다. 제가 최근에 만든 프로토타입을 예로 들어보죠. 이 프로토타입은 JSQL 입력창에 LLM 프롬프트 기능을 추가한 것입니다. (JSQL은 다양한 사용자 도구에 사용하는 사내 SQL 방식입니다.) 이 프로토타입은 실제로 작동했고, 저는 며칠 동안 이를 직접 써보고 테스트했습니다.

클로드는 무료로 무제한 반복 작업을 가능하게 해주었고, 제가 50번째로 마음을 바꾸거나 사소한 조정을 요구해도 불평하지 않았습니다. 저는 제출 버튼을 다듬고, 키보드 단축키를 추가하며, 문구를 수정하고, 프롬프트를 조정했으며, 생성된 확인 메시지도 추가했습니다. 예전 직장이었다면 며칠이나 몇 주가 걸렸을 엔지니어링 및 디자인 간의 반복 작업이자, 십중팔구 그냥 일어나지 않았을 워크플로우 개선 사항들이었습니다. 이 기능에 쏟은 모든 노력은 실제 결과물을 개선하는 데 사용되었으며, 피그마 컴포넌트를 만들거나 문서를 서식에 맞추는 등의 보조적인 중간 단계 작업에는 단 한 푼도 들지 않았습니다.

저도 이 워크플로우에 도달하는 데는 시간이 조금 걸렸습니다. 지난여름 합류했을 때만 해도 저는 UX의 사소한 불편함(papercut)을 수정하는 것과 같은 작은 규모의 작업에만 AI를 사용했습니다. 더 큰 아이디어에 대해서는 여전히 피그마와 문서를 사용했고, 클로드로 그것들을 만들려고 시도하면 실패하곤 했죠. 하지만 지난 2개월 동안 제가 피그마에 손을 뻗는 경우는 급격히 줄어들었습니다. 모델의 성능 향상, 저 자신의 AI 활용 능력 향상, 그리고 적절한 작업 범위를 신중하게 선택한 결과, AI는 이제 큰 작업에도 잘 통하고 있습니다. JSQL 프롬프트뿐만 아니라 사용자 인터페이스, 데이터 모델, 라이브러리 변경을 수반하는 6개 이상의 다른 프로토타입(일부는 2,000줄 이상의 diff 포함)에 사용하고 있습니다. 또한 피그마에서 디자인한 후 완전히 새로운 앱을 위한 인터랙티브 프로토타입을 구현하는 데 사용하고 있으며, 어떤 새로운 앱에서는 아예 피그마를 건너뛰고 처음부터 클로드로 비주얼 디자인을 반복해서 수정하고 있습니다.

디자이너로서 이는 엄청난 권한 부여와 같습니다. 엔지니어들은 아이디어가 떠오를 때 작동하는 개념 증명(POC)을 직접 만들 수 있는 능력이 있습니다. 하지만 디자이너는 다른 사람들을 설득해 우리 대신 그것을 만들어 달라고 부탁해야만 하죠. "JSQL 입력창에서 직접 LLM 프롬프트 요청하기" 같은 아이디어를 제안한다면, 처음부터 그 타당성조차 명확하지 않은 것을 제안하는 것이기에 누군가에게 프로토타입을 만들어 달라고 하는 건 그들의 시간을 낭비하게 만들 수도 있습니다. 다른 경우에는 사용자의 요구를 명확하게 충족하지 못하는 것을 제안할 수도 있습니다. 클로드를 사용해 이런 아이디어들을 현실로 만들면서, 저는 다른 사람들이 평가하기를 훨씬 쉽게 만들고 있습니다. 그들은 그냥 직접 써보면 되니까요.

하지만 단점도 있습니다. 이 워크플로우에서는 리뷰어가 완전히 구워져 나온 기능(Fully baked feature)을 검토하게 됩니다.

원문 보기
원문 보기 (영어)
I design with Claude more than Figma now Feb 05, 2026 | 5 min read Share on Facebook Share on Twitter Share on LinkedIn By: Edwin Morris For a long time I was skeptical of LLMs—whenever I reached for them I was disappointed by the results. Last year I tried Copilot and Cursor to tweak a game I’d built, and neither generated working changes. At a previous job I tried Gemini to outline product briefs and generate wireframes, but ended up throwing them all away. Every time I tried LLMs it was for something I was already good at, and they did a worse job than I would have. Having joined Jane Street this past summer, I’m finding AI support indispensable. There’s just so much that’s new to me, and so much I’m not good at yet, like OCaml and Bonsai . But one big surprise is how much it’s changed the thing I’m best at: my design workflow. Instead of laboring over spec docs, building Figma mockups, writing proposals, and reviewing the implementation with devs, I find myself building prototype features that just do the exact thing I have in mind. What that looks like in practice is: Write something describing the problem and my proposal Open my editor, start a build, the server, and Claude, using that description I wrote as the prompt Get the basic functionality working to prove to myself that it’s possible Iterate on that as much as I want Push changes to a development environment and ask users what they think Submit a feature (our version of a pull request) that looks and behaves exactly the way I want A prototype feature in the actual codebase has felt better in almost every way compared to mockups and docs. Take a prototype I made recently that added LLM prompting to a JSQL input (JSQL is an internal SQL dialect that we use for lots of different user-facing tools). This prototype really works, and I spent days living with it and testing it. Claude gave me free, unlimited iteration, unbothered when I changed my mind for the 50th time or asked for a small tweak. I refined the Submit button, added keyboard shortcuts, tweaked copy, adjusted the prompt, and added generated confirmation messages. These are workflow improvements that would have taken days or weeks of engineering and design back-and-forth at my previous job, or more likely would just never have happened. All the effort spent on this feature went into improving the real artifact, and none on ancillary in-between work like creating Figma components or formatting docs. It took me a while to arrive at this workflow. When I joined last summer, I only approached smaller-sized tasks with AI, like UX papercut fixes. For bigger ideas I was still using Figma and docs, and when I tried making those things with Claude it failed. But in the past 2 months the situations where I’ve reached for Figma have fallen off a cliff. Through some combination of improved models, my own facility with them, and carefully choosing the right scope, AI is now working for big stuff too—not just the JSQL prompt but a half dozen other prototypes that make user-facing, data model, and library changes, including some that are 2000+ line diffs; I’m using it to implement interactive prototypes for brand new apps after designing them in Figma; and for some new apps I’m even skipping Figma entirely, iterating on the visual design from the beginning with Claude. As a designer this has been empowering. Engineers have the ability to create working proofs of concept when they have an idea. Designers have to convince other people to do that for us. For an idea like “direct LLM prompting in the JSQL input” I’d be proposing something whose feasibility is not even clear at the outset; getting someone to build a prototype might waste their time. In other cases I might propose something that doesn’t clearly fill a user need. By using Claude to make these ideas real I’m making it a lot easier for others to evaluate them—they can just use it. But there’s a downside: in this workflow, the reviewer is given a fully baked feature. Does that mean they have zero input on the functionality and are just supposed to review the code? Review is not the most fun work—the equivalent in the design world would be getting a detailed wireframe from a PM and being asked to make it look good. I want to make my proposal as clearly and completely as possible, but I still want my engineering teammates to treat it the same way they’d treat a mockup in Figma, as something they and I can iterate on together in design-space. Our solution for now is just to think about these features differently. I write a short reminder in the description: prototypes are living proposal docs, the code is disposable, and a reviewer’s job is to give feedback about the design and user experience. Eventually, reviewers still take over the idea and implement it in a separate feature, referencing the prototype but owning the production code. In practice we’re still figuring out what makes sense and feels good with this new workflow. There’s also a fear I have that designing with Claude keeps me out of a fluid, creative mindset and stuck in an iterative one, constrained to the outcomes I think Claude can produce. That’s fine for mature tools, where changes are iterative, but might mean I miss ideas when working on something new. This is a familiar tension. When I was getting started professionally in 2011 there was a lot of discourse about whether designers should code . Critics argued that once you’ve started programming you’re less likely to make big changes to an idea. But I liked making websites, and I liked programming, so I kept writing code. Then, when frontend frameworks like React became common and frontend development got more complicated, like others I decided to specialize. I still made personal projects in React—that certainly helped me interact with devs—but I spent almost all my time at work in Figma and docs. Had I joined Jane Street before LLMs, I think I would have become even more entrenched in Figma. With JavaScript I at least have some experience; OCaml and Bonsai are entirely new, and contributing on a technical level would have felt out of reach. Instead I’m back to making the real thing, and it feels amazing to be working in the medium again. I feel more free than ever to just try things. Edwin is a designer on the options desk at Jane Street. prev ious post next post Subscribe to Email Updates Signals & Threads Podcast Listen to the latest episode Featured Tech Talk The Algorithm for Precision Medicine Jane Street YouTube Channel Featured Reads Read more Using ASCII waveforms to test hardware designs Read more Finding memory leaks with Memtrace Tags async book c camlp4 code-review comments compiler core hackerschool hg incremental internship interviewing machine-learning ocaml parallel-programming performance ppx real-world-ocaml registers speed ui RSS Get the RSS feed Jane Street Open Source From committing patches to the Linux kernel to releasing our own projects, we’re always looking for ways to participate in the open source community. Join Our Team Where FP meets the real world. If you're interested in working at a place where functional programming meets the real world, then apply for a job at Jane Street. Learn more Jane Street Group, LLC uses cookies and similar technologies, including third-party cookies, on this Site to provide basic functionalities and perform analytics. You may accept or decline cookies by selecting “Accept” or “Reject”. For information regarding our cookie practices, see Jane Street’s Ad and Cookie Policy . Accept All Reject All