2. ペルソナの利用シーンを決める

🙋 この工程のゴール

自分がデザインするものについて「誰が、どんな時に使うのか」を、想像できるレベルまで具体的に決めること。 これがこの回のゴールです。

まずは1つ、自分が「あー、こういう人いそう」と共感できる利用シーンが手元にある状態を目指します。

👉 これが何につながるか

このトレーニングの最初のフェーズのゴールは、課題と配慮を見つけることです。デザインの中身を決める材料になる部分ですね。

ただ、課題っていきなり出そうとしても出てこないんですよ。「誰の、どの場面の話か」が決まっていないと、思いつきの一般論しか書けなくなる。

なので順番はこうなります。

利用シーン → ゴール → 行動フロー → 課題と配慮

この一番左が今回です。ここが曖昧なままだと、後ろのフェーズが全部ぼやけます。逆にここが具体的だと、この先ずっと楽になります。

💡 利用シーンとは

ひとことで言うと、こういうことです。

誰が / いつ / どこで / なぜ / どんな時に、それを使うのか

この5つを埋める、と考えてもらえれば大丈夫です。よくある5W1Hですが、利用シーンではこの並びで書くと考えやすいかなと思います。

作るものが大きい機能でも、小さい改善でも、考え方は同じです。今のプロジェクトの使い手が、どんな状況でそれを使うのか。それが利用シーンです。

🔍 なぜ、これを一番最初にやるのか

UIを作っていて手が止まる瞬間って、だいたい「これでいいのか分からない」時じゃないですか。ボタンをどこに置くか、この情報は出すべきか、この画面はいるのか。

で、判断できない理由はけっこうシンプルで、判断するための基準が手元にないからなんですよね。

その基準の一番土台になるのが利用シーンです。「新しいプロジェクトにアサインされたばかりの人が、業務時間の合間に使う」と決まっていれば、「じゃあ長い入力は無理だよな」と自然に判断がつく。決まっていないと、何を出しても正解に見えるし、何を出しても不安になります。

もう少し根っこの話をすると、僕らがやっているのは「機能を作ること」ではなくてユーザーの体験を作ることです。誰がいつ使うのかがイメージできていないと、そこに向けてデザインするという話がそもそも始まらない。使う人が想像できないものは、作れないんですよね。

逆に、ここが具体的になるとこうなります。

• ✅ デザインの優先度がつけられる
• ✅ どこに工夫を入れるべきかが見える
• ✅ このフェーズのゴールである「課題」を具体的に捉えられる

「具体的に」がポイントです。このあと行動フローを書いてユーザー像を捉えていくんですが、そこでもずっと使い続ける土台になります。

📝 実際に書いてみるとこうなる

今回のお題は、制作会社の社内で使うサービス。仮説ベースで書くと、だいたいこんな感じになりました。

書いてみると、それだけで見えてくるものがあります。

たとえば「そもそも本を読む」というきっかけがあって初めて投稿が発生する、という順番。あとは、仕事に関係ない本だと社内には投稿しないかもしれない、みたいな肌感も出てくる。この時点でもう、デザインのヒントになっているんですよね。

⚠️ 良くない例と、良い例

良くない例

本を読む社員が、読んだ後に感想をシェアする

お題をそのまま書いてしまったパターンです。

良い例

新しく銀行のプロジェクトにアサインされた新米デザイナーが、上司に勧められて銀行の仕組みや業務を理解するための本を読み、その内容をシェアする

パッと見て「後者のほうが具体的だな」とは分かると思います。ただ、この差が何なのかというと、想像できるか・共感できるかなんですよ。

前者だと、この人がなんで本を読み始めたのか、なんでわざわざ社内にシェアしようと思ったのかが分からない。具体的じゃないからです。

後者だと、デザイナーであっても関わる事業のことが分かっていたほうがクライアントと話しやすい、という背景まで見えてきます。そうすると本を読む目的も、「上司に言われたから」という信頼関係の話かもしれないし、「もっと活躍したい」という成長欲求かもしれない、と想像が伸びていく。

ここまで想像できてからデザインを始められるかどうかで、出てくるアイデアが変わります。「上司の信頼を得たいからシェアするんだよな」と分かっていれば、じゃあどうやったら貢献が見える形にできるか、みたいな発想が出てくるわけです。

✅ 書いた利用シーンが良いか、自分で判定する方法

迷ったら、この2つを当ててみてください。

1. 読んだ人が「この人、こういう時いそうだな」と絵が浮かぶか
2. 「なぜそれをやるのか」が書いてあるか 👉 抜けていると、あとでゴールも課題も出せません

お題の言葉をなぞっただけになっていないか、でチェックしてもいいと思います。

🛠 どうやって考えるか

1. インタビューする（本来はこれが一番）

実際にユーザーが取っている行動をそのまま採用できるので、一番リアルです。今回は仮説で進めますが、現場でやるなら社内のメンバーに「どういうものだったら投稿したいと思うか」を聞きにいったほうが確実にいい。

2. 5W1Hでアイデアを出す

さっきの「誰が / いつ / どこで / なぜ / どんな時に」で出していきます。インタビューで拾った事実をこの形で整理する、というのが実は一番強くて、利用シーンの定義がぐっと具体的になります。

✅ やってみましょう

自分のお題で、利用シーンを書き出してみてください。

• まずは発散。1個だけじゃなくて、いくつも出したほうがいいです。まだ仮説の段階だし、最初のプロトタイプを提示するフェーズなので、ここで絞りにいくのはもったいない
• そのうえで、自分が一番共感できる（＝想像できる）ものを1つ選ぶ。全部やるのは大変なので、進めるのは1つでOKです

🗒 補足：重要な利用シーンが複数ありそうな時

練習としては1つに絞ってと言いましたが、現場では当然、複数をちゃんと考えます。

たとえばBONOだと、まったくの未経験の人、Webデザインの経験がある人、すでに現場でプロダクトに関わっているデザイナー。この3者は状況が違うので、利用シーンも少しずつ違います。

ただ、それぞれ整理していくと、課題が重なることがあるんですよね。最近だと「AIを使ったワークフローが分からない」「ちょっと置いていかれている感じがする」あたりは、立場が違っても共通していたりする。そうなると、ここを潰せば3つのケースに同時にヒットする、という判断ができるわけです。

とはいえ、複数あっても1個ずつ整理していくのは変わりません。まずは1つの重要な利用シーンに対して、ちゃんと価値提供ができているか、UIとして体験が提供できているか。ここが基本になります。

新規機能でも改善でも同じように使える考え方なので、まずは1つ、手を動かしてみてください。

👉 次は 「ゴール：なりたい状態を決める」 です。選んだ利用シーンの裏にある「なりたい状態」を言葉にしていきます。