はじめに
私はフルスタックエンジニアですが、得意なのはバックエンド（API、ドメインモデル、データベース、インフラ）で、デザインの経験はありません。
それでも最近、クリックして操作できるUIモックを作ることになりました。Claudeと一緒に作り、最終的には今後も使いたいと思えるワークフローができました。この記事では、その経験を振り返り、自分が何をしたのか、そしてどこで自分が手を入れる必要があったのかを紹介します。
プロジェクトの概要：
- クライアントは卸売業者で、レガシーなデスクトップの販売・在庫管理パッケージを使っている
- 目的は、その画面のUI/UX（ロジックではなく）を作り直すことと、簡易的なB2B受注サイトを作ること
- モックは契約前の打ち合わせでクライアントに見せる予定だった
クライアントは匿名とし、「卸売クライアント」「レガシー販売パッケージ」と呼びます。画像は汎用的に再現したものです。
振り返ると、作業は7つの段階に分かれていました：
- 既存資料を仕様として使う
- デザインではなく選択肢を求める
- スタイルを全画面に広げる前にレビューする
- オフラインで動く1つのHTMLファイルで納品する
- プレゼン機能をモックに組み込む
- 小さなフィードバックサイクルとテストの委任
- 常に更新するメモドキュメント
※本記事は英語から日本語へ ChatGPT を使って翻訳しています。
1. 既存資料を仕様として使う
モックの仕様書はなく、自分で書くこともしませんでした。代わりに、すでにあるものをすべてClaudeに渡しました：
- レガシー画面のスクリーンショット
- ベンダーのPDFマニュアル
- 打ち合わせの文字起こし
- 社内メモ
そこから、フロントエンドに必要な情報をClaudeに抽出させました：
- 画面の一覧
- 各画面の項目とラベル、そのレイアウト
- クライアントが使っている言葉
- 主な業務フロー
資料は、私がゼロから書く仕様書よりも正確にシステムを表していました。その結果、モックは項目のラベルに至るまで、クライアントの言葉で書かれたものになりました。
2. デザインではなく選択肢を求める
自分ひとりでゼロから良いデザインを考えるのは、私には難しいです。ただ、いくつかのバージョンを並べて見せてもらえれば話は別で、どれが良いか、なぜ良いかはたいてい判断できます。
そこで、Claudeに「いい感じのデザイン」を頼むことはしませんでした。代表的な1画面について、バリエーションを1ページに並べてもらいました：
- 情報が詰まったものから余白の多いものまで、いくつかのレイアウト案
- カラーパレット
- ヘッダーのスタイル
そのうえで、デザイナーとしてではなくユーザーとして反応しました。フィードバックは短いものです：
- 「v3は検索欄が目立ちすぎる」
- 「項目が読みにくい」
何回かのやり取りと、試しては捨てたいくつかの方向性を経て、1つの案が抜きん出ました。それが全画面の基本スタイルになりました。
うまくいった理由は、作るより判断するほうがずっと簡単だからです。気になる点を伝えるのに、デザインの専門用語は必要ありませんでした。また、新しい案が数分で手に入るので、ある方向性を試して捨てるコストはほとんどかかりませんでした。
3. スタイルを全画面に広げる前にレビューする
他の画面を作り始める前に、選んだスタイルについてClaudeにデザインレビューとアクセシビリティレビューを依頼しました。デザインの知識がない私には、そうした問題を自分で確実に見つけることができません。
レビューでは、読みやすさから視覚的な手がかりの不足まで、自分では見落としていた問題が見つかりました。
タイミングが重要でした。基本スタイルは全画面にコピーされるので、この段階で見つけた問題は1回の修正で済み、画面ごとに直す必要がありません。すべてのサービスが依存する前に共有ライブラリをレビューするのと同じ理由です。
4. オフラインで動く1つのHTMLファイルで納品する
モックは、スタイル、スクリプト、ダミーデータ、画像をすべて含んだ、オフラインで動く1つのHTMLファイルとして作ってもらいました。モックのコードは本番の開発が始まれば捨てるものなので、そこに時間はかけませんでした。コードとビルドスクリプトは完全にClaudeに任せ、自分の時間は、クライアントが見るのと同じ形でブラウザ上の結果を確認することに使いました。
この形式は、クライアント向けのモックに合っていました：
- ダブルクリックで誰でも開ける（サーバーもインターネット接続も不要）
- メールに添付できる
- フィードバックのたびに番号付きの新しいファイルができるので、どの打ち合わせで何を見せたかにいつでも戻れる
5. プレゼン機能をモックに組み込む
モックは打ち合わせで見せるものだったので、スライドを用意する代わりに、プレゼン用の機能をClaudeにモックへ組み込ませました。それぞれの機能は、クライアントから出そうな質問に答えるものです：
- 「今使っているものと何が変わったのか？」：モック、元の画面、またはその両方を並べて表示できる比較モード
- 「どこが新しいのか？」：変更点すべてに短い説明を表示するトグルと、以前はなかった機能に付けるNEWバッジ
- 「日々の業務にどう当てはまるのか？」：ステップチップでシナリオを1画面ずつたどれるフロー切り替え
- 「他とつながっているのか？」：共有のダミーデータ。ある画面での操作が他の画面にも反映され、管理画面とB2Bサイトの間でも連動する
これにより、クライアントはクリックするだけで答えにたどり着け、私もデモ中に画面遷移で迷わなくなりました。共有ダミーデータは、バックエンドエンジニアの私にとって一番なじみのある部分でもありました。1つの状態に対して、複数のビューがある構造です。
6. 小さなフィードバックサイクルとテストの委任
スタイルが決まってからは、作業のほとんどがフィードバックの繰り返しでした。1回ごとの範囲は小さく（具体的な問題の短いリストを出し、新しいビルドを受け取る）、変更を確認しやすい状態を保ちました。
テストも任せました。ビルドのたびに自分でクラッシュを確認する代わりに、Claudeに各バージョンをテストさせ、渡す前にClaude自身が撮ったスクリーンショットからレイアウトの問題を確認させました。壊れたビルドが私の手元に届くことはほとんどなくなり、確認の時間は「画面がしっくりくるか」のような、人にしか判断できない点に使えました。バックエンドでテストのないコードを受け入れないのと同じ習慣が、モックでも通用しました。
7. 常に更新するメモドキュメント
モックと並行して1つのドキュメントを用意し、何かが決まるたびにClaudeに更新させました。セクションは次の4つです：
- 既存画面の改善点（それぞれの理由付き）
- 新機能
- デモシナリオ
- クライアントへの確認事項
ルールは1つだけで、メモとモックの内容を常に一致させることです。フィードバックで画面が変わったら、同じタイミングでメモも更新しました。
このドキュメントは、結果的にいくつもの役割を果たしました：
- 打ち合わせの台本
- 提案書と見積もりの元ネタ
- セッションの最初にClaudeに読み直させることで、毎回すべてを説明し直す必要がなくなった
振り返り
Claudeに任せたこと
- 既存資料の読み込みと情報の抽出
- デザイン案の生成
- CSSとフロントエンドのコードすべて、そしてビルドスクリプト
- デザインレビューとアクセシビリティレビュー
- 渡す前のビルドごとのテスト
- メモドキュメントの更新
自分でやったこと
- 選択肢の中から選ぶこと
- スコープを決めること：モックに入れるもの、最初のリリースに入れるもの、入れないもの（何でも作ってもらえるので、断るのは自分の役目）
- 実際のユーザーのようにモックを使い、問題を報告すること
- クライアントに何を、いつ確認するかを決めること
- メモドキュメントを本質だけに絞り込み、人が読めるドキュメントにすること
ぶつかった限界
- スクリーンショットからレイアウトの崩れを見つけるのはClaudeに任せられましたが、画面がごちゃごちゃして見えるかどうかの判断は自分の仕事でした。
- 自分の漠然とした「感覚」をもとにUIを作ってもらうのは難しかったです。デザインの知識がない場合は、言葉で説明するより参考例を見せるほうがうまくいくかもしれません。