2021/06/10
UIとは情報設計。最近つくづくそう考えている。 当たり前だが、UIとはそのサービス、その機能、その画面において何が重要で、どうしてほしいかを伝え、コミュニケーションするための手段である。
それにもかかわらず、「この場合、こういうUIがわりと一般的」「競合サービスはこういうUIになっている」そんな理由で思考停止的に自らのサービスのUIを決めてしまう瞬間はないだろうか。
- サービスの方向性やおおよその機能要件は決まっているものの、各画面の詳細なUIはまだぼんやりとしか浮かんでいない
- だけどアイデアを具体化するためにもワイヤフレームを描き始めなければ…
こんな状況に立たされたプロダクトマネージャーは特にやりがちかもしれない。 しかし、そんなとき安易に他サービスのUIを参考に設計を始めたりすることは危険だと考えている。
なぜなら冒頭にも書いた通り、UIとは情報設計であるからだ（大事なので2回言った）。 他サービスにはそのサービスの世界観があり、情報設計があり、その中でUIを決めている。 当然、自らのサービスもそうであるべきで、ただ「流行っているから、イケているから」「他もそうだから」で取り入れてしまうのは本質的ではない。 ではプロダクトマネージャーは具体的にどのような手順でUIの設計に向き合うべきだろうか。
成し遂げたいことより、UIを考えることが目的になってしまっていないか？
今回は解決したい課題が明確になっており、サービスや機能についてのおおよその構想まで済んでいる、という前提で話を進める。
この段階までくると、ワイヤーフレームを描くなど、UIについて具体的に手を動かし始めるプロダクトマネージャーは多いと思う。 以前の僕もよく、この段階でワイヤーフレームを描き始めることが多かった。
しかし、このやり方にはいつの間にかインターフェースを考えることが目的になってしまうという罠がある（と僕は思っている）。
UI領域に強いプロダクトマネージャーならこれでも問題ないが、デザインの引き出しの少ないプロダクトマネージャーの場合、他サービスのUIのリサーチをはじめ、それっぽいインスピレーションを受けては、違和感のないデザインをワイヤーフレームに反映する、ということをやってしまってはないだろうか。
ワイヤーを書く前にテキストで情報設計する
この罠を避けるため、僕はワイヤーを描く前にもう1ステップ踏んだ方が良いと考えている。
やることはシンプルで「この画面では最も重要なことは何か？」を画面ごとにテキストで書く。 そして「どういう情報設計であればそれが達成されそうか」を一緒にテキストで整理する。それだけだ。
以下は例だが、こんな感じ。
このテキストを書いた時点で「この画面では何を重視して見せるべきか」「どの要素が前に出ているべきか」が自ずと決まってくる。
最近はこの作業の後にワイヤーを描くことが多いが、これがあれば少ない引き出しでも成し遂げたいことに限りなく近いUIが自然と浮かんでくることも多いし、この段階でデザイナーに相談したり、引き継いでもらうことも可能だ。
また、これを書いた上でそれを実現するための引き出しが足りなければ、他サービスを参考にすれば良いと思う。 この場合は冒頭に書いた状況とは違い、重視するものが明確になった上で、実現するための手段を探すというリサーチになるので、すでに存在するデザインに変に影響されることもない。
ちなみに上記の例は以前、動画共有機能のあるサービスの再生画面を設計するときに書いた時のものだが、これを書かずにYouTubeやTikTokを参考にしてしまっていたら、「コメント欄は再生画面から一階層奥まったところに設置するのが定石」と思い込んでしまっていたかもしれない。
また、このテキストがあれば「この画面を考えた時は何を重視していたのか？」がクリアになり、仮説と効果測定の照らし合わせがしやすく、振り返りの精度も上がっている感覚がある。
他サービスのUIを参考にするべき場面とのバランス感覚を持つ
一方で、多くの人に使われているサービスにUIを寄せると、ユーザー側の学習コストが下がり、最初から違和感なく使ってもらえるというメリットも存在するので、そこら辺はバランスだと考えている。 （ゆえにログイン画面とか、サービスのコアにあまり関わらない部分については特別な意図がない限りベーシックなデザインを採用していく、みたいなので基本的に良いと考えている）。
ただ、サービスのコアとなる部分を設計するとき、「達成したいことを起点にUIを設計できているか？」をプロダクトマネージャーは常に問うべきだと考えている。
また、言うまでもないが、日常的に他サービスのUIをリサーチし、引き出しを増やしたり、その意図を考察することはとても良いことあることは間違いない。