SaaSプロダクトのデザインで学んだこと vol.1 〜ユースケースについて〜
はじめに
SaaSのデザインを経験して3年になりますが、未だに学ぶことが多くその奥深い世界に戸惑ったりワクワクしたりを日々繰り返しています。
今年はありがたいことにグッドデザイン賞を頂くことができました。
初めてのSaaS・初めてのドメイン領域ということで色々と手探りでしたが、日々のデザインを通して自分的に押さえておきたい観点も幾つか見えてきました。
今回はその中から「ユースケースを考えることは奥が深いしめっちゃ大事なんじゃないか？」ということについて書いてみたいと思います。
「ユースケースの見極め」が肝
SaaSのデザインにおいて考慮すべき事はたくさんありますが、中でも一番大事な要素が「ユースケースの見極め」なのではないかと最近感じています。
そもそもユースケースとは？
この記事で、ユースケースとは「ユーザーが何か目的を持って行う一連の行動・操作」の事とします。（厳密な意味ではちょっと違うかもですが悪しからず。）
（詳しい説明は下記usagimaruさんの「ユースケースモデルとユースケース中心設計」の項を見て頂くのが分かりやすいかもしれません。）
なぜユースケースの見極めが大事か？
それはユースケースの集合体がSaaSプロダクトそのものだからです。
SaaSはユーザーが抱える業務上の課題を解決するために開発されるケースが多いですが、そこには無数のユースケースが存在します。
全てのユースケースに対応しようとするとキリがないしプロダクトの輪郭がぼやけてしまうので、特に負が大きいと思しき幾つかのユースケースに着目し、そこに向けて機能を開発・提供することになります。
つまりSaaSは自分たちが注目したユースケースによって形作られているのです。言い換えると対応するユースケースを決める事は、自分たちが何者であるかを決める事に等しいことになります。
良いユースケースを捉えるとプロダクトは非連続な成長をする
突然ですが、ユーザベースに入社し程なくした頃、社内で用いられていた下図を目にしました。「プロダクト開発は何を目指して行うのか？」
それは「ユーザーのため」そして自分たちが実現したい「ビジョンのため」。この両端を追い求めるのが大事。どちらかに偏ってもいけないし、中間解（中途半端な解決策）に落ちると中途半端な結果しか生まないから気をつけるべし。そういう図でした。
当時、この構図自体に「なるほど！」と思考がクリアになった感覚と感動を覚えました。そしていま一歩思考を進めて、デザイナーである自分は具体的にどのような行為によってこれを実現できるか？を考えてみると、それが「ユースケースの見極め」なのではないかと思います。
良いユースケースを捉えていればユーザーにWow!となる体験を届けられるし、後述しますがビジョン実現に向けてどういうステップを踏んで行くかを明確にすることにもなるからです。
取り組むべきユースケースを見つめることは、それくらい重要で価値があることではないでしょうか。
ユースケースの見極め方
しかし、ユースケースの見極めはなかなか難しく奥が深い。特にtoBとなるとデザイナーにとっては独特の壁が立ちはだかっているように感じます。ここではどのようにユースケースを見極めていくか、幾つか観点を書いてみます。
1.業務を知る
まずユーザーが行っている具体的な業務についてちゃんと把握する必要があります。
ここでの壁は、toBな業務内容はデザイナーにとって門外漢であることが多く、想像したり理解したりがやや難しいということです。
ここは地道に当事者であるユーザーにインタビューさせてもらったり、書籍を読んで勉強するしかありません。もしできるならその業務を実際に体験してみるのも良いと思います。
【Point1】
デザイナーにとって門外漢であることの多いtoBな業務内容について、しっかり理解する必要がある。
2.業務を新たに定義するような姿勢で臨む
上記と並行して、業務の背後にある「目的」も知る必要があります。表出しているユースケースはただの一手段であって、目的達成のためなら別の手段もあり得るかもしれないからです。
別の手段とは、もしかしたら、まだ世の中にないユースケースかもしれません。むしろ革新的なプロダクトというのは「こんなシンプルな使い方なのに、今までにないこんな成果が出せる」というのをサポートしてくれるものだと思います。
【Point2】
目に見えたユースケースに留まらず、より良いユースケースを模索する必要がある。それは時に「業務を新たに定義するような行為」に近い。
つまり、ただでさえ土地勘がないけど
- その目的なら、こんな業務・手順・操作をすると、より良い結果を出せますよ
- 私達のプロダクトは上記を圧倒的にやり易くします
- そのために最適なインターフェースがコレです
というような、良い意味でユーザーの想像を超えるユースケースを見出し、それに対応したデザインを考えようとする姿勢が望ましいように思います。
この姿勢は「答えはユーザー側にあるそれを探るだけでなく自分たちから創造していく」という意味において、Figma CPOの山下さんも語っていた「解決策の提案 → 問題の定義 の方が革新的なプロダクトに繋がるケースが多かった」という話にも繋がる所かなと個人的には感じます。
3.ステップの切り方を意識する
見出したユースケースに革新性があり、自分が思う最強のデザインを描けたとしても、実装されないことには意味がありません。そして多くの場合、一足飛びに理想状態まで持っていくことは難しい。
開発にはそれ相応の時間がかかるので、どういうステップを踏んで理想状態まで持っていくかを区切る必要が出てきます。
この時、MVPとして何を切り出すかが重要になってきます。最小単位のリリースでもしっかり価値が届くこと、そしてその先に続く開発が無駄なく効率的に進められる形になっていること。これらを考慮することも非常に大事なポイントだと感じます。
【Point3】
MVPでもしっかり価値が届くユースケースをカバーしていること。かつ後続開発に繋げやすいユースケースとして切り出せていること。
4.事業開発の側面も考慮できるとなおよし
いちデザイナーには難易度が高くなってしまうのですが、事業開発の側面を考慮できるとまた違ったユースケースの見極め方もアリになって来るのかなと思います。
例えば他社とのアライアンスを組めば、自社プロダクトの延長には考えつかなかったユースケースをカバーできるようになるかもしれません。もし自社で複数プロダクトを扱っているのであれば、事業間シナジーを活かした新しいユースケースを見い出せるかもしれません。
ユースケースは奥が深い
いかがでしたでしょうか。上記観点を総合的に考慮した上で、いま解決すべきユーザーの課題は何でどのユースケースに着目すべきか…その見極め作業はとても奥が深く、難しく、面白いと改めて感じます。
途中、toB特有の壁がある…と表現しましたが、だからこそ面白い領域なのかなとも思います。誰かの仕事が巡り巡って自分たちの生活に届いているわけで、裏側でそんな事やってるんだというのを知るのは純粋に面白いと感じます。
自分もまだまだ手探り中なので、引き続き精進していきたいと思います。
＊
最後まで読んで頂きありがとうございました。DESIGN BASEのみんなの記事もぜひあわせてご覧ください。
Text: Takasumi Moteki
Cover Design: Kurumi Fujiwara