ユーザーインタビューの録音を聞き直しながら、ふと思った。「この人の言葉、そのままプロンプトにしたらどうなるんだろう」。インタビューで語られる「使いにくい」「こうしてほしい」という言葉は、ユーザーの生の声だ。デザイナーがその言葉を解釈して設計するのが通常のプロセスだが、解釈を挟まずに直接 Stitch に渡したら何が起きるか。
実験した結果は、驚きと発見と、少しの限界があった。
結論から言うと
ユーザーの言葉をそのままプロンプトにすることで、「デザイナーの解釈」を挟まないUIの初稿が生成できた。このUIはユーザーが「まさに自分が言いたかったことだ」と感じる場合があり、要求の確認ツールとして機能した。一方で、ユーザーの言葉は「症状」であることが多く、「原因」を解釈せずに形にすると根本的な課題を解決しないUIになることもあった。ユーザーの言葉を「そのまま使う価値」と「解釈する必要性」を両方理解したうえで使うことが重要だった。
実験の背景と方法
今回の実験に使ったユーザーインタビューは、料理レシピアプリのUI改善プロジェクトで実施したものだ。対象は20〜40代の料理好きユーザー5人、各60分のインタビューを行った。インタビューで出てきた「UIへの不満・改善要望」を32個リストアップし、そのうち「UIに直接関わるもの」を20個に絞った。
実験手順：①ユーザーの発言をそのままプロンプトに変換 → ② Stitch で生成 → ③元の発言をしたユーザーに見せて「これはあなたが言ったことですか？」を確認 → ④デザイナーが解釈したバージョンと比較。この流れで20個のユーザー発言を検証した。
ユーザー発言をプロンプトに変換する方法
インタビューでの発言は断片的で感情が混じることが多い。例えば「検索して出てきたレシピ、どれがいいか分からなくて、ずっとスクロールしちゃうんですよね」という発言を、プロンプトに変換すると「レシピ検索結果一覧画面。ユーザーがどれを選ぶべきか迷わないよう、レシピの特徴（調理時間・難易度・評価）が一目で比較できるレイアウト」になる。
発言→プロンプト変換で意識したポイントは「感情（〜で困る・〜が嫌だ）を取り除き、UIの要件（〜が見えること・〜できること）に変換する」こと。感情的な言葉はプロンプトには向かないが、その背景にある要件は具体的にプロンプト化できる。
うまくいった事例
20個の検証のうち、「ユーザーが言いたかったことと近い」と評価されたUIが生成されたケースを紹介する。
事例1：「材料を全部揃えてから作れるレシピを先に教えてほしい」
この発言を「今ある食材で作れるレシピを最初に表示する画面。手持ちの食材を入力すると、それだけで作れるレシピが上位に表示される。買い足しが必要なレシピは下に表示し、何が足りないかを明示する」というプロンプトに変換して生成した。
生成されたUIは「食材入力フィールド＋今すぐ作れるレシピ（緑のラベル）＋あと1品買えば作れるレシピ（黄ラベル）＋買い足しが多いレシピ（グレー）」という3段階のフィルタリングUIだった。元の発言をしたユーザーに見せたところ「そうそう、これが欲しかった！」という反応が得られた。
この事例は「ユーザーの言葉がUI要件に直接翻訳できた」ケースだ。発言の中にすでに「今ある食材」「作れる」「揃えてから」というUI設計のヒントが含まれていた。
事例2：「お気に入りに保存したレシピ、どこにあるか毎回分からなくなる」
「お気に入りレシピへのアクセスが毎回分からなくなる問題を解決したホーム画面。ボトムナビゲーションにお気に入りアイコンを配置し、最近保存したレシピ3件をホームにも表示する」というプロンプトで生成した。
生成されたUIは、ホーム画面に「最近保存したレシピ」のミニカードが3枚並び、ボトムナビにお気に入りアイコンが常時表示されるデザインだった。元のユーザーの反応：「これだと毎回迷わない。こういうのが欲しかった」。
「ユーザーの言葉のまま」では解決できなかった事例
一方で、ユーザーの発言をそのままプロンプト化すると根本解決にならないケースもあった。
事例3：「フォントが小さい」という発言
「フォントを大きくしたレシピ詳細画面」というプロンプトで生成したUIを、元のユーザーに見せた。反応は「大きくはなったけど、なんか読みにくい」だった。
後から深掘りすると、ユーザーが「フォントが小さい」と感じていた本当の原因は「フォントサイズ」ではなく「行間が狭くて文字が詰まっている」だった。症状（小さく見える）と原因（行間の狭さ）が違っていたため、フォントを大きくしても解決しなかった。
この事例は「ユーザーの言葉は症状であり、設計者が原因を診断する必要がある」という典型だ。Stitch はユーザーの言葉を忠実に形にしてくれたが、言葉の背後にある本当の課題は、人間の解釈が必要だった。
事例4：「もっとシンプルにしてほしい」という発言
「シンプルにしたレシピ一覧画面」というプロンプトで生成したUIは、情報量を大幅に削ったミニマルなデザインだった。元のユーザーの反応：「シンプルになったけど、これじゃ選べない。料理時間くらいは見えないと」。
「シンプルにしてほしい」の本当の意味は「情報を全部削ること」ではなく「必要な情報だけを残して整理すること」だった。ユーザーの言葉は常に「今の状態への不満」を表現しており、「理想の状態」を正確に表現しているとは限らない。
この実験から学んだ「ユーザーの言葉の使い方」
実験を通じて、ユーザーインタビューの言葉を Stitch のプロンプトとして活用する際のガイドラインが見えてきた。
- 「〜してほしい」という具体的な要求：そのままプロンプト化しやすい。UI要件に直接翻訳できる
- 「〜が分からない」「〜に迷う」：ナビゲーションや情報設計の課題として翻訳して使える
- 「〜が小さい」「〜が見にくい」：表面的な症状かもしれない。本当の原因を深掘りしてからプロンプトにする
- 「もっと〜してほしい（シンプル・かっこよく・使いやすく）」：感情的な表現は一段解釈してから。「シンプル＝必要な情報だけ整理」のように具体化する
よくある質問（FAQ）
Q1. ユーザーインタビューをしていなくても、この方法は使えますか？
A. はい。ユーザーレビュー（アプリのレビュー・カスタマーサポートのログ・SNSのコメント）も同じように活用できます。実際のユーザーの言葉であれば、インタビューでなくても「ユーザーの声をプロンプトに変換する」アプローチは有効です。
Q2. ユーザーの言葉をプロンプトに変換するのが難しい場合はどうすれば？
A. 「この人は今何に困っているか、もし自分が同じ状況だったら何が欲しいか」と問い直してみてください。ユーザーの感情的な言葉を「UIとして何が必要か」に翻訳するスキルは、共感力と密接に関係しています。難しいと感じたとき、まず感情を取り除いて課題だけを取り出してみることが最初のステップです。
Q3. ユーザーの言葉そのままで生成したUIをユーザーに見せる意味は何ですか？
A. 「解釈の検証」に使えます。デザイナーが解釈したUIと、ユーザーの言葉通りのUIを並べて見せることで「どちらがより自分の意図に近いか」をユーザーに判断してもらえます。これは要求の確認と、デザイナーの解釈の検証を同時にできる方法です。
Q4. ユーザーリサーチを Stitch と組み合わせることで、設計プロセスはどう変わりましたか？
A. 「ユーザーの言葉→UI案→ユーザーへの確認」のサイクルが速くなりました。以前はユーザーインタビューの結果をデザイナーが解釈してFigmaで形にする段階に数日かかっていました。Stitch を使うことで、インタビューの翌日に「こういうUIですか？」という確認ができるようになりました。
Q5. 「症状」と「原因」を見分けるためのコツはありますか？
A. 「なぜそう感じるのか」を1回多く聞くことが基本です。「フォントが小さい」→「なぜ小さく感じるのか」→「文字が詰まっていて読みにくい」。この1ステップ深掘りが、症状の言葉を原因の課題に変換するカギです。インタビューで「なぜ」を一度追加することを意識するだけで、プロンプト化できる質の情報が増えます。
Q6. ユーザーリサーチなしでも Google Stitch でUIを作れますか？
A. 作れます。ただしリサーチのある・なしで「誰のためのUIか」の精度が変わります。ユーザーの声がない場合、プロンプトの「ターゲットユーザー」の部分は自分の仮説になります。この仮説が外れるほど、生成されたUIとユーザーの実際のニーズがずれる可能性があります。
まとめ
ユーザーの言葉を Stitch のプロンプトに変換する実験は、「デザイナーの解釈を一度外す」という体験だった。解釈を挟まずに形にしたUIが、ユーザーに「そう、これが欲しかった！」と言わせることもあれば、「症状を形にしただけ」で根本解決にならないこともあった。
ユーザーの言葉は設計の出発点として最高の素材だが、それをどう形にするかはデザイナーの仕事だ。Stitch はその「形にする」プロセスを加速してくれるが、「何が本当の課題か」を判断する責任は人間にある。この役割分担を理解したうえで、ユーザーリサーチと Stitch を組み合わせると、設計の精度と速度が同時に上がる。
