業務システムの案件を担当するようになって早数年。初期の頃から言われ続けて、いまだにしっかりできているのか不安なことがある。
それは「ユーザー視点での設計」だ。
- そもそも「ユーザー視点」とは何なのか？
- どう考えれば「ユーザー視点」で設計していることになるのか？
その感覚がなかなか掴めず、どちらかというと機能面で実装可能かどうか？
という視点で考えてしまいがちだった私はとても苦労した覚えがある。
とはいえ何案件か担当させてもらい、その度にユーザー視点をもてていなかった場合には、他のチームメンバーにガンガン指摘してもらうことによって、「機能的な要件」に偏りがちだった私でもだいぶ「ユーザー視点」が身についてきたかなと思う。
なので、今回はそこに至るまでに意識していた「ユーザー視点」の持ち方についてのポイントをまとめてみたいと思う。
1. ユーザー像を深堀りし、書き出してみる
まず、一つ目はユーザー像を深堀すること、これはワークフローの中ではいわゆる「ペルソナ作成」のフローにあたるかもしれない。
ベイジではペルソナは案件ごとに、作ったり作らなかったりと、必要に応じて様々なのだが、それとは別に（もちろんそれをベースにでも良い）が自分で型を作ってペルソナを定義してみると、ユーザー像の深堀の良い機会になる。
自分の頭の中でぼんやりとしたイメージを持っていたとしても、あえてそれをテキストに書き起こしてみることによって、たくさんの気づきが見つかることがある。
思っていた以上にぼんやりしていて、全然ペルソナ像を書き起こせないことに気がつくかもしれないし、反対に要素はたくさん出せたけれど、客観的にみたら「この年齢でこの行動はしないよな…」とか「この職業の人って本当にこんな行動をとるのだろうか？」など、自分の偏った視点に気がつくことができる。
書き出してみたら、今後の自分の制作の軸にしつつ、なんか違うなとアップデートしていくもよし。他のチームメンバーに共有して、チーム内での認識の共有を行ってみるのも良い。ひとまず自分の頭の中にある像を書き出してみるのが良いだろう。
2. その機能が必要になった背景を深堀する
①は制作が始まる前ぐらいのタイミングで行うのがベストかなと思うが、反対に②は制作中にやってみると良いことだ。
業務システムの案件では、大きなシステムの改善をベースとしつつ、より具体的な「この機能（サービス）を使いやすくしたい」「新しい機能（サービス）を追加したい」といった要望を聞く機会も多いだろう。その際に、ただ要望通りに対応するだけでは、ユーザー視点の設計ができているとは言えない。
また、私がよくやってしまいがちなのが、要望をベースに「機能的に実現するには、こうした方が良いですよ」といった形の提案をすること。これが私が「機能的な要件」に偏りがちという指摘を多く受けてきた要因だと感じている。別に間違いではないのだが、この時点では、上記の提案も本質的ではない。ここでやるべきなのは、まず「なぜこの機能が必要になったのか？」という背景を理解することだ。
例えば「目的のセミナーが見つからないので、検索機能に条件を追加し、より条件を絞って検索できるようにしたい」という要望をもらった場合に、単純に検索機能の条件を追加することが問題解決につながらないことも多々ある。
この場合の問題は「検索条件が少ないこと」ではなく「目的のセミナーが見つからない」なので、まずはなぜ「目的のセミナーが見つからない」という問題が発生しているのかの背景をより深掘りするべきだろう。
深掘りしてみたところ、もしかしたらその理由は「検索条件が多すぎて、検索機能を使う気になれない」かもしれない。そうだった場合、検索条件を増やすことは、ユーザー視点での問題解決とは真逆のことになってしまう…背景を深掘りして起きてよかった…となるだろう。
実際の案件では、ここまでシンプルなことはないのが難しいところなのだが、要望が出たら、まずは「なぜそれが必要になったのか？」という背景の深掘りはできる限りしてみるのが良いと感じている。
3. ユーザー行動を深掘りし、 実際に使うシーンをイメージする
①で制作前、②で要望を聞いたタイミングときたので、③では実際に手を動かしている時の意識すべきポイントをまとめてみようと思う。
３つ目のポイント、それは「実際に使うシーンをイメージする」ことだ。それは今手を動かして作っている機能（画面）にたどり着くまでに、
- ユーザーがどういった行動をするか？
- 何を目的にこの機能（画面）にきたのか？
- この機能を使うのにどのくらいの時間をかけてくれるのか？
そういった、実際にユーザーが使うシーンをイメージしていくと、その機能のデザインや、どういうUIパーツを使うか？が決まってくる。
例えば、本の検索機能をイメージしてみよう。本の検索一つにおいても、いくつかのユーザー行動をイメージすることができる。
明確な目的がなく、どんな本の種類があるのかをみて、カテゴリなどで絞り込みを複数回行って探したいユーザーが多い場合は、複数の選択肢を可視化したUIにするのが良いだろう。反対に、本のタイトルが明確に決まっていて、すぐにその本を一覧の中から探し出したいユーザーが多い場合には、キーワード検索等の少ない手数で、目的の情報まで辿り着けるUIが求められているだろう。
こういった違いをユーザーが使うシーンをイメージすることで判断できると、よりユーザー視点での設計になると感じている。
またこのポイントに関しては、ユーザーテストの結果を活用するのも良いだろう。実際に画面を操作してもらいその行動を見たり、どんな環境・用途・頻度で利用するかといった、情報をヒアリングすることができる。
ユーザーテストはユーザーがその機能（画面）をどう感じたのか？どう評価したのか？という体験ベースに幅広く、多くのことを観察でき、よりユーザー視点を伴った改善につながるので、ベイジのワークフローでも積極的に取り入れている。
仮説ではなく、実際のユーザーの行動を観察したり、インタビューすることができるので、これほどユーザーが改善対象の機能（画面）使うシーンをイメージするのに役立つ情報はないだろう。
もちろん、ユーザーテストの結果が、全ユーザーの行動に当てはまるというわけではないので、その結果を全て鵜呑みにすることはできないのだが「ユーザーが実際にどういう時にこの機能を使うのか？」といったユーザー行動の深掘りにはとても役立つ情報だといえるだろう。
4. システム的なことは度外視で考える
最後に、元も子もないが、いったん設計のタイミングでは、機能的な実装可否や、工数的に対応可能かどうか？といったことは考えずに、ユーザー視点の最適解を突き詰めて考えてみるのも大事だと感じている。
もちろん、そのままでは理想論だけを突き詰めた、再現不可能な画面になってしまう可能性もあるので、見直しは必要だが、初回の設計時点では、システム的な部分は度外視で考えた方が良い塩梅に収まるのでは？というのが個人的な持論である。
最後に
長々と書いてきたが、正直なところ「ユーザ視点」に明確な答えはなく、極論を言えば、しっかりと顧客とそのサービスに向き合って、深掘りし、考え続けるしかないのだろうなと思っている。
ただ、その考え方のきっかけとして、私自身は上にあげた４つのポイントを意識してみると、うまくはまることが多いと感じたので、まとめてみた。
もし、同じようなことで悩んでいるデザイナーさんがいれば、考え続けるための助けになれば嬉しい限りだ。
