1. 機能をつくる罠。ユーザーの利用シーンからゴールをデザインしよう

「要件の項目は全部入れたし、余白も揃えた。見た目も今っぽくて綺麗！」 「……でも、なぜかユーザーに使ってもらえない」

これ、実はUIデザインを学び始めた人が一番ハマりやすい罠なんです。

今回は、この「機能要件を満たした綺麗なUI」がなぜ使われないのか？ そして、その罠から抜け出し、ユーザーが本当に使ってくれる体験を作るための「シナリオベースドデザイン」について解説していきます。

要件は満たしている。でも、この体験で本当にいいんだっけ？

要件さえ入ってれば「100点満点」？

例えば、あなたの会社で「チームの会話量を増やして、知識共有を気軽にするため」に、新しく社内本レビューサービスを作ることになったとしましょう。

あなたは「レビュー投稿画面」をデザインすることになりました。
とりあえず作成してみたUIが以下の画面です。

要素はすべて揃っています。機能としてもちゃんと必要なものが揃っているように見えます。

「よし、これで完成でいいじゃん！100点満点。」と思うかもしれません。

本当にそれでいいのでしょうか？👻

現実のユーザー「田中さん」を想像してみよう

でも、ここでちょっと立ち止まって、この画面を実際に使う人のことを想像してみてください。

営業部の田中さん（28歳）です。 彼は3週間前に読んだビジネス書の感想を共有しようと、仕事の合間にこのアプリを開きました。

しかし、記憶はうろ覚え。文章を書くのもそこまで得意ではありません。 そんな彼が、あの「綺麗なUI」を見たらどうなるでしょうか？

• 「著者名？ えーっと、誰だっけ…調べるの面倒だな…本どこだっけ、えーと」
• 「レビュー本文…こんな巨大な真っ白の箱、何文字書けばいいんだよ…考えまとめるか」
• 「あー、今は忙しいし、また後で書こう（そして二度と開かない）」

そう、田中さんは画面を見た瞬間に絶望し、そっとブラウザを閉じてしまうかもしれません。社内のコミュニケーション活性化を目指したサービスは終了してしまうのでしょうか？

シナリオベースドデザインの習得をしよう

要件（機能）を満たしているだけでは、ユーザーは動いてくれません。
これが「機能要件を満たした綺麗なUI」の罠です。

このシリーズではユーザーを軸に体験をデザインしていくためのフレームワークである「シナリオベースドデザイン」を習得します。

これを身につけて実践していくことで、ユーザーの目的達成や、サービス価値のデザインをする1歩を踏み出すことで事業貢献をデザインで行える可能性が上がります。

ユーザーが満足する体験を考えるシナリオベースドデザインとは？

機能ではなく、ユーザーの文脈から逆算する

ここで登場するのが、「シナリオベースドデザイン」という考え方です。

これは一言でいうと、「誰が・いつ・どんな状況で・どんな気持ちで使うか」というユーザーのシナリオ（文脈）を起点にしてUIを設計していく思考プロセスのこと。

さきほどの田中さんの例で言えば、「Aという項目を入力して、Bを押して、Cを実行する」といったシステムの都合（機能）から考えるのをやめるということです。

その代わりに、「うろ覚えで、文章が苦手な田中さんが、どうすれば気持ちよく感想をシェアできるか？」というユーザーの感情や状況から逆算して「理想の体験」を整理してUIを考えていきます。

ユーザーをハッピーにすることでビジネス成果も出る

デザインの目的は「綺麗な画面を作ること」ではありません。 「ユーザーを理想の体験に導くこと」で、サービスに寄与することです。

ユーザーがハッピーになり、目的（今回は「気軽に知識共有すること」）を達成できれば、結果としてサービスは使われ続け、ビジネスとしての目標（会話量の増加）も達成できます。 また、ユーザーがメリットを感じる瞬間が課金を促すポイントにもなっているはずです。

「機能ではなく体験を作る」ことこそが、デザイナーが事業に貢献するための最も強力な武器になります。

【Before/After】ユーザーシナリオから考えるとUIはこう変わる！

シナリオベースで考えると、UIがどう変わるのかみてみましょう
※UIのビジュアルクオリティは低いですスンマセン

[Before] 普通に作ると「機能の羅列」になる

普通に「要件」だけで作ると、先ほどのようにシステムの都合を押し付けた冷たい画面になります。

これでは、田中さんのようなユーザーの心は折れてしまいますし、”チームのコミュニケーション頻度を上げる”ことは難しそうです。

[After] シナリオがあると「田中さんの背中を押すUI」に変わる

しかし、「文章が苦手でうろ覚えの田中さん」というシナリオを軸に”どういう体験がベストか？”を考えてUIアイデアを変更すると、例えば以下のような体験になるかもしれません。

いざ書き始めようとしたときに本のタイトルが怪しい...

そんな時はタイトルを入力したらサジェストする体験にすると、スムーズに書き進めるかもしれません。

本を読みながら気軽に気づきや疑問とかけたらハードルは低くなるかも？

入力のハードルが高いなら、”ユーザーはどういう風に本の投稿を考えるか？”を考えると、一気にまとめて書く必要はないという方向性がアイデアとしてあるかもしれません。

こちらの方がフランクに投稿でき疑問なども書ける体験になりそうで、社内のコミュニケーション活性化にも繋がりやすいかもしれません。

どうでしょうか？ 同じ「レビューを投稿する」という機能でも、ユーザーシナリオから考えていくと、どういう体験であるべきか？から目的を達成する体験をデザインしやすくなるはずです。

体験の流れから「必要な画面」が見えてくる

さらに、シナリオベースで「理想の体験の流れ」を作ってからアイデアを考えると、大きなメリットがあります。

それは、「ユーザーにどういう状態になってほしいか」をイメージしながら作れるため、その過程で「どんな状態の画面が必要か」が自然と見えてくるということです。

「なんとなくこの画面が必要そう」ではなく、「田中さんが迷わずに投稿完了のハッピーな状態へたどり着くには、ここでこの画面（UI）が必要だ」と、根拠を持って画面設計ができるようになります。

ユーザーを軸に体験をデザインする型を習得しましょう

シナリオベースでデザインする方法をここから学んで扱えるようになっていきましょう。

実践に入る前に、次の記事「ペルソナ中心UIデザインの進め方」で全体像を確認して、このフレームワークを実践する流れに入ります。

それではまずはこのフレームワークの全体像を見ていきましょう。