テックタッチアドベントカレンダー16日目を担当する、デザイナーの keita です。
私の日課のひとつが NBA 観戦なんですが、今シーズン大活躍中の渡邊雄太選手から目が離せません！ネッツの背番号18のジャージ買って、一緒にブルックリンに応援しに行く人いませんか？
はじめに
これまでの我々の開発プロセスは、兎にも角にも競合調査が中心でした。
ユーザーの課題を解決するためにはどういうソリューションが必要なのかを検討し、要件が薄ら見え始めた頃、競合他社には同じような機能がないかを調査します。そして UI や技術要件などが固まったら開発スタート！という流れでした。
課題
これまでのプロセスで特に問題ないと思っていたんですが、自分たちが「こうだ！」と自信満々にリリースした機能が、ユーザーの利用シーンを想定しきれていなかったためファーストリリースから芯を食った機能にできなかった、ということがありました（詳細な機能について記載できなくてごめんなさい🙇♂️）。
もちろん、Nice to have なフィードバックがあれば折を見て追加開発するんですが、この機能の場合はそもそも設計の段階から少しズレてしまっていたため、次回の改修で大幅な変更が必要になりそうな気がしています。
これの原因のひとつが、自分たちが「テックタッチ」ユーザーとして機能を使きれていないため検証が不十分だった、という点です。
「ドッグフーディングしっかりやろうぜ！」だったり「ユーザー理解しようぜ！」も策としてはあると思うんですが（もちろん別で進行中）、今回は「検証プロセスをテコ入れしようぜ！」になりました。
補足
一般的なSaaSであれば、新機能や機能改善は実装が終われば週単位や月単位でリリースできると思うのですが、「テックタッチ」に関してはユーザーの利用するシステム上で動作するという特性があるためバグは許されず、そのリスクを減らすために「リリース頻度を減らし、品質が高い状態を維持しながらリリースする」というサイクルをとっています。
なので、一度リリースしてユーザーの利用状況や反応を見てから機能改善する、というサイクルが回しづらいため、手前でいかに検証し切れるかが味噌になってきます。
シナリオとは？
情報設計のなかでカスタマージャーニーマップの作成というプロセスがありますが、それと似て非なるものだと思っています。
カスタマージャーニーマップは、サービスに触れる前からその後までの一連の道筋でどのタッチポイントでどういうコミュニケーションをとる必要があるのかを整理するのが目的だと思うのですが、我々の「シナリオ」は少し違います。
※カスタマージャーニーマップも、ペルソナの行動と感情のシナリオですが、今回は違うものだとわかりやすくするために、敢えて「シナリオ」と呼んでいます。
カスタマージャーニーマップとの違い
シナリオの場合は、あくまでも実装予定の機能とそれに関係する機能についてのみ深掘りしていきます。
ペルソナが、どういう状況下で「テックタッチ」の機能を利用し、誰とどのように連携し運用していくのか。これを想定できる数だけ作成します。シナリオの途中で別のシナリオに分岐したり、そこからまた元のシナリオに戻ったりと、道がいくつもできるイメージです。
もちろん、ペルソナについての理解がないとシナリオは書けないので、そこについてはカスタマージャーニーマップと変わらないとは思いますが。
このシナリオが固まり違和感がないことを確認できたら、それをもとにUIを作成します。
そして、作成した UI をシナリオ通りに操作したとき、ペルソナの目的が達成できるかどうかを検証します。途中で操作に詰まったり、シナリオに書いてあることが実現できない場合は、UI が要件を満たせていないということなので再度設計しなおします。
メリット
なんとなく頭の中で考えていたものを目に見えるようにすることで、UI を作成する際に外してはいけないポイントを洗い出しやすくなりました。
今までは「あー、その観点あったね」みたいな会話を、実装が終わってステークホルダー交えてのレビューでしていたんですが、それがもっと手前で、かつ自分たちで気づきやすくなったと思います。
「プロトタイプでレビューしてもらえばいいじゃん」という意見もあると思いますが、ユーザーの行動パターンはその手前でデザイナーができる限り把握しておくべき、という強い意志と、プロトタイプ作成コストの兼ね合いでこのプロセスを試しています。
かんたんな機能であれば Figma を見せるだけで伝わると思うんですが、複雑な機能になるとペーパープロトや Figma のプロトタイピングだと「よくわからない」という声もあり。結局のところ、動くものを触ってみないとよくわからないので、その動くものの確度をあげるための「シナリオ」というわけです。
なので「シナリオ」+「（実際に動く）プロトタイプ」を作成しステークホルダーのレビュー、そのあとに本実装だったら完璧なプロセスかもしれません。
デメリット
作成のコストがかかるので、小さな機能や改修には向かないと思います。大きめの新機能や、複数の機能が複雑に絡み合うものなどを設計するときには合っているのかなと。
最後に
シナリオ作成自体、正直なところまだ一周も回しきってはいないのですが、このようなデザインプロセスをチームで定義することはとても重要なことだと認識できました。
デザインプロセスを定義しておくことで、属人化が避けられ、一貫性をもったユーザー体験を提供できるのではないかと考えるようになりました。
さらに「テックタッチのデザインチームは、こういうプロセスでプロダクトデザインしているんだ」と社内で認識してもらうことができれば「この情報はデザインチームに渡しておかないと！」のように、組織がデザインをうまく利用するきっかけにもなるのではないかと思っています。
プロダクトや組織の数だけデザインプロセスはあると思いますが、より価値ある体験を提供できるよう今後も我々にあったやり方を模索していければいいなと思っています。
