- Claude Codeを活用して、中間段階のモックアップなしでそのまま動くコードを作成し、デザイン効率を高めている
- Figmaの使用量は大きく減少し、動くコード上で実データを使って機能を編集すると、静的なモックアップよりもUXの改善点がはるかに早く見えてくる
- 小規模な機能はFigmaなしでそのままClaude Codeで実装し、大規模な機能はディスカバリー作業の後にインタラクティブなアーティファクトを作成してチームと共有
- ハンドオフや無駄な成果物なしでPR提出まで自分で完了するプロセスへと変化
- ユーザー中心の思考と課題探索、反復的な改善は維持しつつ、デザインの核心原則は保ちながら、デザインと開発の境界を縮める新しいワークフローへ進化中
核心的な変化: Claude Codeによるデザイン作業
- Claude Codeを毎日使っており、自分のGitコミットグラフでコミット数が増えていることが、デザインと開発の統合を示している
- Figmaの使用は大きく減り、コードベースのデザインへ移行
- 意図したユーザー体験（ユースケース、想定される動作、機能の発展方向）を自然言語で説明すると、Claude Codeが実装方法を把握する
- これまでエンジニアと協業していたやり方と同じだが、デザイナーが直接コントロール権を持つ
- 中程度の忠実度（mid-fi）モックアップを完全に飛ばし、Claude Codeでプロンプトによって動作するバージョンを数分で実装できる
- 実データを含む動作版で編集すると、整列、フィルタリング、データ長の問題などUX改善点が即座に目につく
新しいデザインプロセス
- ここ数か月でプロセスが大きく変化
-
小規模な機能はFigmaなしでClaude Codeで直接実装
- QoL改善、一覧への検索フィールド追加など、既存のパターンやコンポーネントを活用する機能はFigmaを完全に省略してそのままClaude Codeで進める
- ワイヤーフレームもハンドオフもない
- Claude Codeは適切なコンポーネントやパターンをうまく使い、特にOpus 4.6はコードベースを理解し、明示的な指示がなくても正しい作業を行う
-
大規模な機能では依然として事前探索と課題定義を行う
- 課題、ユースケース、良いソリューションの「形」（例: 「速くて摩擦のない感じ」「ユーザーに追加作業をさせない」）、潜在的なアプローチを文章でまとめる
- それを通常のClaudeチャットに持ち込み、追加のアイデアを求めると、見落としていた興味深いアイデアがいくつかと、文脈に合わないものが一緒に出てくる
- 好みの方向性についてClaudeでインタラクティブなアーティファクトを生成し、自分で感触を確かめ、チームに共有してフィードバックを集める
- プロンプトを書くより速い場合は、Figmaで簡単なローファイのワイヤーフレームを描くこともある
- 反復とチームでの議論、ユーザーフィードバックによってアプローチを固めた後、Claude Codeでコード内で直接ビルドとポリッシュを行う
Figmaが依然として有利な領域
- ビジュアル探索（配色、タイポグラフィの選択肢、新しいコンポーネント）はFigmaが依然として優位
- 並べて比較する、拡大縮小する、要素を移動するといった作業はコード上では行いにくい
- ただし既存プロダクトと既存デザインシステム内での作業がほとんどのため、この領域の比重は縮小している
変わらないもの
- ユーザー中心の思考、ニーズ把握、課題理解、さまざまな選択肢の探索、反復とテスト、完成度を高めるためのポリッシュはそのまま維持されている
- プロセスの中間段階が主にClaude Codeへ移っただけであり、コードをユーザーの手元に届けるところまで自分で行える
- 結果としてデザインと開発の境界が縮まり、実際のユーザーに届ける速度が速くなった
- ハンドオフや無駄な成果物なしで最終媒体上でそのまま作業し、PRを提出する流れ
- 今後の変化は予測できないが、新しいツールや方法を活発に試している時期である
2件のコメント
開発者が今や Claude Code を使ってデザインまでやるべきだという話も出ているようですが、デザインにはレビューや検収は必要ないのでしょうか？
開発に比べると、はるかに速く、頻繁に発生するフィードバックループが必要ですよね。
開発者は業務サイクルの末端にいるぶん、チーム内での役割が過大に解釈される面もあると思います。