いまやFigmaよりClaudeでデザインすることのほうが多い
(blog.janestreet.com)- デザインワークフローは、仕様書とFigmaモックアップを経て実装を検討する方式から、実際のコードベース上で動くプロトタイプ機能を作る流れへ移行しつつある
- Copilot、Cursor、Geminiは、もともと得意だったゲーム修正・製品ブリーフ・ワイヤーフレーム作業では期待外れだった一方、新たに習得する必要があったOCamlとBonsai環境ではAI支援が不可欠な要素になった
- 問題と提案をプロンプトとして渡したあと、基本機能の実装、反復的な修正、開発環境へのデプロイ、ユーザー意見の確認、feature提出まで続く実装中心の手順
- JSQL入力にLLMプロンプティングを加えたプロトタイプでは、ボタン、ショートカット、文言、プロンプト、確認メッセージを何度も磨き込み、Figmaコンポーネントや文書の書式ではなく実際の成果物に労力を集中できた
- デザイナーがアイデアを自ら使える形にできるようになった一方、完成機能のように見えるプロトタイプは、レビューへの参加の仕方や創造的な探索に新たな課題も伴う
LLMへの懐疑から必須の支援ツールへ
- 長いあいだLLMを使うたびに結果に失望し、自分が得意な作業にLLMを適用すると、直接やるよりも品質が低いという経験が続いていた
- 昨年作ったゲームを修正しようとしてCopilotとCursorを使ったが、どちらも動作する変更を作れず、前職ではGeminiで製品ブリーフのアウトラインやワイヤーフレーム生成も試したものの、すべて破棄した
- 昨夏Jane Streetに加わってからは新しく学ぶことが多く、まだ不慣れな OCaml や Bonsai のような技術のため、AI支援が不可欠な役割を果たした
- 大きな変化は、最も自信があったデザインワークフローまでAIが変えてしまったことだった
Figmaや文書の代わりに、実際のコードベースでプロトタイプ
- 仕様書の作成、Figmaモックアップの制作、提案書の作成、開発者との実装レビューの代わりに、頭の中にある機能を正確に実行するプロトタイプ機能を作る
- 実際の流れは、問題と提案を説明する文章を書き、エディタでビルド・サーバー・Claudeを実行し、その説明文をプロンプトとして使うというもの
- まず基本機能を動かして可能性を確認し、その後は望むだけ反復的に修正する
- 変更を開発環境に上げてユーザーの意見を聞き、見た目と動作が狙いどおりになったらfeatureを提出する
- featureはJane Streetにおけるpull requestに相当する手順
- 実際のコードベース内にあるプロトタイプ機能は、モックアップや文書よりほぼあらゆる面で優れた体験だった
- 最近、JSQL入力にLLMプロンプティングを追加したプロトタイプは実際に動作し、数日間自分で使いながらテストした
- JSQLは複数のユーザー向けツールで使われている社内SQL方言
- Claudeは、50回目の気が変わった要望や細かな修正依頼にも動じず、自由でほぼ無制限の反復を提供してくれた
- Submitボタン、キーボードショートカット、文言、プロンプト、生成される確認メッセージに至るまで改善した
- 前職であれば、エンジニアリングとデザインのあいだで数日から数週間にわたる往復が必要だったか、あるいはもっと高い確率で最初から実現しなかったであろうワークフロー改善だった
- この機能に費やした労力は、Figmaコンポーネント作成や文書書式の調整といった中間成果物ではなく、実際の成果物そのものの改善に集中していた
直近2か月で広がった適用範囲
- この流れに至るまでには時間がかかり、参加当初はUXの小さな不便を直すような小規模作業にしかAIを使っていなかった
- 大きなアイデアには依然としてFigmaと文書を使っており、Claudeで作ろうとする試みは失敗していた
- この2か月でFigmaを開く場面は急激に減り、モデルの改善、ツール習熟、適切なスコープ選定が重なって作用した
- AIはJSQLプロンプトだけでなく、ユーザー向け、データモデル、ライブラリ変更を含むおよそ6件のプロトタイプでも機能した
- 一部のプロトタイプは2000行を超えるdiffになった
- Figmaで設計した新しいアプリのインタラクティブなプロトタイプ実装にも使った
- 新しいアプリの一部はFigmaを飛ばして、最初からClaudeでビジュアルデザインを反復した
デザイナーの権限拡大とレビュー方法の再定義
- エンジニアはアイデアがあると動く概念実証を作れるが、デザイナーは他の誰かに代わりに作ってもらえるよう説得しなければならない構造がある
- 「JSQL入力で直接LLMプロンプティングを行う」のようなアイデアは、出発時点では実現可能性が明確ではなく、他人にプロトタイプを任せると時間を無駄にする可能性があった
- 提案によってはユーザー要件を明確に満たせないこともあるが、Claudeでアイデアを実際の形にすると、他の人が自分で使って評価しやすい状態になる
- 欠点は、レビュアーが完成機能を受け取る形になり、機能そのものへの意見を出さずにコードだけをレビューすべきなのかが曖昧になること
- デザインにたとえるなら、PMが詳細なワイヤーフレームを渡して「見栄えよくしてほしい」と頼むのに近く、楽しいレビュー作業ではない
- 提案は明確かつ完全であるべきだが、エンジニアの同僚にはFigmaモックアップのようにデザイン空間で一緒に反復する対象として扱ってもらう必要がある
- 現在の解決策は、featureの説明に短い注意書きを入れること
- プロトタイプは生きた提案文書である
- コードは破棄可能である
- レビュアーの役割はデザインとユーザー体験へのフィードバックである
- 最終的にはレビュアーがアイデアを引き継ぎ、別のfeatureで実装し、プロトタイプを参照しつつも本番コードはレビュアーが所有する形になる
- 実際の業務では、この新しいワークフローで何が妥当で、何がしっくりくるのかを引き続き探っている
反復作業の制約と、再び実際の媒体に戻ってきた感覚
- Claudeでデザインすると、流動的で創造的な思考から離れ、Claudeが作れそうだと思える結果の範囲内で反復作業に閉じ込められるのではないかという懸念がある
- 変化が反復的で済む成熟したツールなら問題ないが、新しいものを作るときにはアイデアを取りこぼすリスクがある
- 2011年に専門職としてのキャリアを始めた頃には designers should code という議論が盛んで、批判的な立場の人たちは、プログラミングを始めるとアイデアに大きな変更を加えにくくなると主張していた
- Webサイト制作とプログラミングが好きだったのでコードを書き続け、Reactのようなフロントエンドフレームワークが一般化してフロントエンド開発が複雑になってからは専門分化を選んだ
- Reactの個人プロジェクトは開発者とやり取りするうえで役立ったが、仕事ではほとんどすべての時間をFigmaと文書の中で過ごしていた
- LLM以前にJane Streetへ加わっていたなら、Figmaにさらに深く固定されていたはずで、JavaScriptと違ってOCamlやBonsaiは完全に新しく、技術的な貢献は手の届かないもののように感じられていただろう
- 今は再び実際の成果物を作っており、その媒体の中で作業し、何でも試せる自由が大きくなった感覚がある
1件のコメント
Hacker Newsのコメント
ビジネス側はすでに要件を自分たちで考えた解決策の形で持ってくることが多く、たいていはルーブ・ゴールドバーグ装置のような代物なので、対話を通じてリバースエンジニアリングしないと本当の要件にたどり着けない
今後は、すでに「準備できていて」「動く」解決策を持ってきて、設計やアーキテクチャを全体として見直そうという話にはさらに乗り気でなくなりそう
「こう作ればいいだけじゃないか。ほとんどできてるのに、なんでX人日も必要なんだ？」となりそう
欠点は、ビジネス側がそのアプリをそのまま本番デプロイしてはいけない理由を理解しないこと
「AIなら速く進められるだろ」という圧力が強まり、結局は健全な組織力学にかかってくる話になりそう
利点は、ナプキンスケッチよりもアイデアがずっと徹底的に検証されている点
Claudeはすでに境界ケースや設計上の判断について質問していたはずで、どこかの時点で「それは気にしなくていい、そう仮定して」や「何度か使ってみたけどこのインタラクションはよくないので変えて」と明示していた可能性が高い
今は「何が問題なんだ、そのままデプロイしろ」という圧力が強く、愚かで士気をくじくので純損失に近いが、安定してくれば将来のプロジェクトでは純利益になるかもしれない
その細かな修正というのが、ブラウザ幅がちょうど1920pxでないとレイアウトが崩れる問題、フィルタやソートがたまに正しく動かない問題、ある操作のあと新しい値がアプリに正しく反映されない問題だったりする
問題の大きさに関係なく、ビジネス側は自分たちでもう95%はやったと思っているので、「熟練開発者ならすぐ直せるはずだ」と最初から見積もっている
人は自分の手元の成果物に慣れてしまい、新しいプロのミックスで変わる部分を受け入れにくくなる
顧客の問題を使い勝手のよい製品機能へ翻訳する感覚を持つPM、CSM、TAMもいるが、問題定義を飛ばして別の機能組織に解決策を作らせると、たいていはエンジニアリングや他のリソースを大きく浪費する惨事になる
誰かが解決策を持ち込むと、数か月かけて運用可能なソフトウェアを作ったあとで、顧客がそれを嫌い、問題を解決していないか、新しい問題を生んでいると判明するリスクが高い
今の職場ではなく前にいた会社だが、データ損失やセキュリティ問題を抱えたまま本番デプロイまでされた
Jane StreetがAnthropicの投資家だと認識しているので、その点は割り引いて考える必要がある
2025年7月には、インド証券取引委員会SEBIがJane Streetについて、複数の法人を使って市場操作を行ったと主張し、市場アクセスを禁止したという点もある
巨大な金の流れにはダッシュボードが大量に必要なのだろう
ここではデザイナーが間違ったアプローチをしているようで、プロトタイプをできるだけ深く現実的に作り込みたいというエンジニア志向への憧れに陥っているように見える
でもそれはデザイン業務で最も重要な部分ではない
最も重要なのは、正しいものが作られること
「なぜJSQL入力ボックスが必要なのか？ 本当に欲しいものは何か？ 別のやり方は何か？」といった問いは、ペンと紙のスケッチ、会議、観察、議論で解くほうがうまくいくことが多い
特定のデザインにあまりに早く絞り込み、ボタンが左か右か、LLMの細かな挙動がどうかといった議論に入るよりよい
もちろん、まさにそう考えてほしいと思っているのかもしれないが
たまにこれを感じる
LLMは現状、反復の先を見ることができないので、私が枠の外で考えて「この観点から見たらどうだろう？」とやらないと、突然新しい設計のやり方は出てこない
ときには、LLMに自分の進行段階の先を見せるためにフローチャートを作る必要がある
「Claudeは、私が50回目の気変わりや細かな修正を頼んでも気にしない、無料で無制限の反復をくれた」という話だが、Claudeの費用を払っていないのか？
小規模なデザインスタジオも似たようなもので、開発者のような時間課金ではないことが多い
正直に、私は本当にデザインが苦手で、デザインシステムを外挿するのにも問題があると答えた
まともに見えるところまで持っていくのがあまりに難しく、その過程でほとんどいつもかえって悪くしてしまう
面接していたデザイナーはそれを個人的に受け取り、私を問い詰めてきた
以前にも似たことがあった
デザイナーたちはどう見えるべきかについて絶えず質問されるのを嫌い、一度渡したら終わりという引き渡しを望んでいた
マーケティング・広告代理店でも、デザイン仕様にないものがどう見えるべきか、サンプルを出してくれと何度も争わなければならなかった
私が正しかったと言いたいわけではないが、私にとっては大きなアキレス腱だ
だから「無料、無制限の反復、気にしない」と聞くと、お金より先に時間と忍耐が思い浮かぶ
私がプロトタイピングに使うBoltは怒らない
最高のデザインを作るわけではなくても、私にできるものよりはるかによく、終わったら本物のデザイナーにもっと良くしてもらえばいい
それまでは、誰かを怒らせる心配をしなくて済む
フロントエンドで Claude Design を使ってきた。
仕上がりの見た目や雰囲気は十分よいが、デザインがしばしば似通って見え、だいたい現代的なウェブのありふれたパターンに従う。
これで非定型な創造的試みをした人がいるのか気になる。
ここまでで約3週間かけていて、まだ未完成だが雰囲気は伝わるはず。
過去10年間に SaaS ボイラープレートがあったように、インターネットで学習されたLLM ボイラープレートもある。
それでも十分に手を入れれば、まだ何でも可能。
要件を与えれば合わせてくる点と、方向性を与えないと無難な選択をする点が面白い。
出力の美学やユーザー体験・コンテンツを評価するつもりなのに、美学面のプロンプトをほとんど与えなければ、無難なデフォルトしか返ってこない。
bootstrap/tailwind のコピーっぽいデザインはうまく作るが、その部分は意識的に押し込む必要がある。
単純なウェブページでは、初期の反復の唯一の焦点を視覚スタイルに置き始めた。
標準的に見えないよう具体的に指示して、望むウェブサイトのスタイル例を渡せばよい。
少し格闘すればやや創造的に感じられるようになるが、プロンプト作業は必要。
とても尊敬され経験豊富なデザイナーたちに勧められたが、彼らは今ではほぼ全面的に Claude でプロトタイプを作り、気に入ったら Figma で整えている。
そもそも詳細なスタイルのプロンプトなしに一般的な UI を求めれば、一般的なデザインが出てくるのは当然。
ここでの利点は、デザイナーがコーディングを学ぶこと。
ソフトウェアがどう作られるかを知らないままデザイナーがソフトウェアを形作るというのは、ずっと奇妙だと思っていた。
ちなみに自分もデザイナー。
ただし、コードでデザインするのは技術優先のアプローチだ。
デザインの目的が人間の目的に合わせて成果物を形作ることだとすれば、コードの厳格な規則から始めないほうがよいとも言える。
見栄えのよい成果物のためではなく、思考を前に進めるという点では、いまだにペンと紙に勝つのは難しい。
今では実質的に声でコーディングできるようになり、再びバイブコーディングとプロダクト作りに戻っていて、本当に楽しい。
上司はこの新しい状況をまだ把握中だが、古い役割分担は死に始めている気がする。
交差点にいるのが今は一番いい立ち位置だと思う。
自分の人生全体がこの瞬間の準備だったように感じる。
デザイナーにとっては、結果を見てビジュアルエディタの代わりに言葉で修正する Figma に近いだろう。
うちの妻は FAANG でプロダクトマネージャーをしているが、チームは本来 Word や Excel のようなものでやっていたはずのソフトウェア断片を、AI でバイブコーディングすることに極度に依存している。
彼らはコーディングを学ばず、コードを1秒たりとも見ない。
「プロトタイプは生きた提案書であり、コードは捨ててよく、レビュアーの仕事は設計とユーザー体験にフィードバックを与えることだ。
最終的にレビュアーがアイデアを引き継いで別機能として実装し、プロトタイプは参考にしつつ、本番コードは自分で所有する」というアプローチは、自分があらゆる POC で経験していた問題を解決してくれる。
本当に良いやり方。
特定の製品の特定の課題を扱うときは「提案書」と呼びやすい。
だが今でも無数のデザイナーが Figma を使って、製品とプラットフォーム全体にまたがるデザインシステムを定義・維持しており、その場合 Figma が真実の源泉だ。
うちのチームもこうしていて、自分はフロントエンドエンジニアだが、正直以前のやり方が本当に恋しい。
書かれた仕様が動くプロトタイプに置き換わったことで、今ではコードを読んで意図された変更が何で、捨てるべきノイズが何かを判断しなければならない追加の認知負荷が生じている。
生成された PR を受け取って必要な変更をするか、最初から作り直すかを決めなければならず、どちらにしても摩擦がある。
意図しない変更が大量に生成されたこともあり、自分が再実装に時間をかけて移し替えたあとで、「あっ、すみません、それは変えるつもりじゃなかったんです」となることもあった。
権限を与えるという点は理解するが、以前の仕事で感じていた楽しさの一部を奪い、厄介ごとに変えてしまっている。
デザインとプロダクト側が Claude で機能や体験をバイブ設計・コーディングして、素早くプロトタイプを作り、最小限のエンジニアリング時間で顧客の前に持っていってフィードバックを得る。
すばらしい。
だが全体として、より速く出荷する助けにはあまりなっていないという点は意外かもしれない。
理由は、その過程で思考を失ったからだと思う。
かなりの思考がいまや言語モデルに外注されている。
プロンプトの隙間を塗りつぶし、明示されていない動作を幻覚で埋めてしまう。
以前なら「これはあまり合っていない」「このアイデアをどう伝えよう」「このケースではどうなる？」と立ち止まっていたはずのものが消え、今ではそうした細部はちゃんと作ったあとへ先送りされる。
もちろんプロセスを改善し、この新しい手法をもっとうまく使う方法を振り返ることはできるが、以前よりよいかと言われると微妙。
廃れていく。
今ではバックエンドの人たちもフロントエンドをやる。
そこが思い違いだ。
コンパイラが生成したアセンブリをのぞき込むか？ 見ない。
ではなぜこのコードを見ているのか？
私たちは抽象化レイヤーを上へ持ち上げたのだ。
私も同じアプローチをよく使う
AI以前から手作業でこうしていた
まずユーザーと一緒にペンと紙だけを持って座り、その次にフロントエンドのPOCやデモを素早く作り、ユーザーに触ってもらって、望む通りに動くまで調整していた
私にとっては、本番品質ではない高速なフロントエンドのデモをコードで作るほうが、Figmaで正確なインタラクションを作るより、すでに速いことが多かった
完全なインタラクションが可能なので、ユーザー体験におけるエッジケースをはるかに多く拾えた
今ではClaude Codeのおかげで捨てる前提のプロトタイプを作る速度がさらに上がったが、とてつもない差というほどではない
ユーザーと議論し、どう動くべきかを考える時間が全体の80%なので、Claudeは自分で素早く作る場合と比べて、残り20%を半分にしてくれる程度だ
最初のバージョンは速くなるが、完全に理解できていないときの反復はむしろ遅くなる
Edwin、投稿が上がっているのを見てうれしい
2012/2013年ごろに一緒にハッカソンをやった記憶がある
動くプロトタイプまでより早く到達できる力は、未完成のアイデアをそのままリリースしたくなる誘惑があるとしても、非常に大きな後押しになる
デザインやユーザー体験の要件は、ストーリーボードやワイヤーフレームを超えて、実際のフローを触って体験できるときに大きな恩恵を受ける