6. プロトタイプの作成

🙋 この工程のゴール

決めたデザイン要件をもとに、パターン全部をプロトタイプにすること。 これがこの回のゴールです。

作り込む必要はありません。触って体験できれば十分です。むしろ作り込まないでください、というのがこの回の一番のメッセージかもしれません。

👉 これが何につながるか

次のフェーズは、作ったものをチェックして改善に回すところです。そのチェックの対象がここで作るプロトタイプになります。

アイデア → 理想の体験 → パターンを決める → デザイン要件 → プロトタイプ（今回） → チェックと改善

🔍 なぜプロトタイプを作るのか

1. 机上の空論は、形にしてはじめて分かる

言葉の上でアイデアを整理してきましたが、それが本当にどういう体験になるのかは、触ってみないと分かりません。

理想の状態に近づいているのか。そのズレが、形にすると一気に見えるようになります。実際、この記事の後半でプロトタイプを見てもらいますが、「ここはこうなんじゃないかな」「ちょっと違和感あるな」と感じるところがあると思うんですよね。その感覚が大事です。体験できるから拾えるものなので。

2. メンバーの意見を集めやすい

今回のお題だと、社長みたいな人から依頼が来たという設定ですよね。プロトタイプがあれば、その人に触ってもらって「改めてどう思うか」を確かめられます。

人の気持ちって変わるし、言葉ってけっこうあやふやなんですよ。触れる形があると、明確な意見を引き出せます。プロジェクトの早い段階でこれができると、ビジネスやエンジニアリングの視点も先に集まるので、ミスも減ります。

言葉だけで終わらせず、体験でチェックする。 そのためのプロトタイプです。

💡 何をUIに変換するのか

前回まとめたデザイン要件の、特にこの2つです。

実現したい利用シーン
体験フローのイメージ

これを「体験できるUIの形」に変換したものがプロトタイプになります。要件の④で書いた流れが、そのまま画面の流れになるイメージですね。

ローファイでいい＝作り込むな

今回はローファイ（粗いプロトタイプ）です。なのでビジュアル・ボタンのサイズ・色・オブジェクトのスタイル、この辺は一切気にしなくていいです。

確認したいのは「この方向性で、僕らが解決したい課題は解決できそうか」「理想の体験になっていそうか」。それを早めに確かめるために作るので、作り込む意味がないんですよね。

🗒 画面の中に何の情報が必要か、順番の優先度はどうか、抜け漏れはないか
👉 こういう情報設計の話は、ここでは全部捨てています。「ゼロから始めるUI情報設計」のレッスンでやる内容なので、ハイファイを作るときにそちらを参照してください

⚠️ 作るときのポイント4つ

1. ダミー情報は絶対に入れない ← 最重要

ここだけは本当に守ってほしいところです。

❌ タイトル「あああああ」／コメント「テストテスト」／Lorem ipsum
✅ 実際に投稿されそうなトピック名、人っぽいアイコンと名前、リアルなコメント

なぜダメか。実際の体験と全然違うものになるので、使うときのイメージが湧かないからです。

設定した理想のフローが本当に行えそうか、プロトタイプでチェックするのが目的なのに、中身がダミーだとそれができません。リアルな情報が入っていると、こういうことに気づけます。

• このコメント、2行じゃ収まらなそうだな
• この質問って確かにこのくらい短いけど、一回質問返しが来て、その後に返答する流れになりそうだな
• じゃあこの形でいいのかな

これが次のチェックにつながっていきます。AIを使えば文言もすぐ出ますし、要件がここまで整っているなら精度も出ます。粗くていいので、必ずリアルな情報を入れてください。

2. 荒くていい

重要な体験がある程度できればOKです。作り込まないでください。まだそういうフェーズではありません。

3. 文字ではなく、体験で評価する

具体化して触ってみると、考えていたものと実は違ったり、もっと考えたほうがいいことが見つかったりします。

4. パターンは必ず全部作る

比較できるのがパターンを作った理由でした。大変に思うかもしれませんが、今はAIがあるので大変じゃありません。

🛠 何で作るか

僕は今回、全部AIで作りました。Claude Code で Opus 5.0 を使っています。

渡したのは、みなさんが書いているであろうデザイン要件だけです。解決したい課題、実現したい利用シーン、体験フローのイメージ。それを渡して、まず質問や確認をしてもらって、どういうものを作るべきかを出してもらう。それでよさそうなら進めてもらう、という形です。

UIデザインにおけるAI活用の、一番分かりやすい事例だと思います。ワークフローにもう入っているべきものかなと。

📝 実際に作った3つ

動画では、僕が作った3パターンを実際に触りながら見てもらっています。ここでは何を作ったかだけ置いておくので、中身は動画で確認してください。

🔍 並べると、違いがはっきりする

3つを並べて触ると、投稿のハードルが明確に違います。 他のメンバーの意見をシェアしやすいのがどれかも、触るとすぐ分かる。

考えていた時点では「そうかもね」くらいだったことが、体験すると明確に違う部分と、共通している部分として見えてきます。これはどれだけ言葉で整理しても出てこない感覚です。

提案するときも同じで、「レビュー案にはこういうデメリットがあります」と説明するより、触ってもらったほうが早いんですよね。「確かに」となる。比較できると気づきも増えるし、提案もしやすくなります。

✅ 作ったプロトタイプが良いか、自分で判定する方法

1. ダミー情報がひとつも残っていないか 👉 残っていたら、その画面はまだチェックに使えません
2. 要件に書いた体験フローが、最初から最後まで通せるか 👉 途中で止まるなら、まだ形になっていません

見た目の完成度は判定材料に入れないでください。今はそこを見るフェーズではありません。

✅ やってみましょう

決めた3つのパターンを、デザイン要件をもとに形にしてください。

1. デザイン要件の利用シーンと体験フローをAIに渡す
2. 質問・確認をしてもらってから作ってもらう
3. リアルな情報を入れる（ダミー禁止）
4. 荒く作る（ビジュアルは気にしない）
5. 3パターン全部作る

作ったものを比較すると、「この方向性のこのポイントは意味がなさそうだな」「課題に刺さらなそうだな」が自分で分かってきます。それがそのままUIの経験値になります。

このフェーズ、ここまでの流れ

前のフェーズで「現状と課題」を捉えて、ここで「理想と、それを形にしたもの」まで来ました。

👉 次のフェーズは チェックと改善 です。作ったプロトタイプを要件に照らして確認し、改善点をまとめて次にやることを決めます。量としてはここまでより少ないはずです。おつかれさまでした。