ユーザーストーリー起点のUIデザインに潜む罠 ~モーダルな機能の実装を防ぐ~
こちらはSaaS Designer Advent Calendar 2023 18日目の記事です。
他の方の記事も是非見ていってください！
こんにちは、株式会社アトラエのデザイナー、おおもりです。 組織力向上のためのSaaSプロダクト、Wevoxのデザインをメインに行なっています。
本記事では、問い合わせからユーザーストーリーを作成し、機能開発に落とし込む際に潜む落とし穴についてご紹介できればと思います。
ユーザーストーリーの概要
ユーザーストーリーは、顧客がソフトウェアで実現したいと思っているフィーチャーを簡潔に記述したものだ
本題に入る前に、ユーザーストーリーについて簡単に触れておこうと思います。(正確な定義があるわけではないので、あくまで解釈の1つとして捉えてもらえれば嬉しいです。)
ユーザーストーリーはユーザーの実現したいことを、最小単位で記述したものです。ユーザーストーリーに基づいた開発プロセスを踏むことで
■ユーザーを起点にした機能設計がしやすい
■チームで誰にどのような価値提供をするのかの目線合わせがしやすい
のようなメリットが生まれます。
近年のユーザー中心のプロダクト設計の広がりもあり、ユーザーストーリーをベースに開発を行う企業も増えてきました。特にアジャイル開発との相性が良いため、スプリントごとにバックログに積まれたユーザーストーリーを実装していく、という手法はSaaSプロダクト開発ではメインストリームになりつつあります。
より詳細な説明や導入プロセスを知りたい方は、是非下記の書籍やサイトを参照してみてください。
Wevoxの開発も例に漏れず、リサーチやユーザーから寄せられた声といった一次情報をベースにユーザーストーリーを作成し、アジャイル的に企画→実装につなげるといったプロセスを踏む機会が増えてきました。
自分自身、ユーザーストーリー起点での企画では、
■早い段階で、なんとなく解決方法が見える
■ユーザーニーズの解像度を上げた状態でUIデザインに入れる
という実感があり、ユーザーストーリーを重宝し盲信していました。そう、あの日までは、、
改善プロジェクトのMTGで抱えた違和感
数ヶ月前、「Wevoxのユーザビリティを、問い合わせ起点から改善する」というプロジェクトのMTGにアサインされました。
Wevoxでは、お問い合わせとしてユーザーから頂いた声は外部ツールを用いてタグ付けし、内容とともに一元管理しています。このときは、
タグをベースに問い合わせを分別→特にイシューが大きい部分を特定→減少が期待される問い合わせの数をKPIとして設定→ユーザーストーリーと機能改善施策の叩きを作成
のフェーズまで、問い合わせの一次対応をしてくれているチームが進めてくれていました。そのため自分は、KPI設定の妥当性や、施策をUIに落とすとしたらどのような形としてかの壁打ち相手としてMTGに入ることになりました。
ユーザーにとっても、社内にとってもプラスとなるはずの改修。腕をぶん回し、気合十分でMTGに臨みました。ところが、、
どうUIに落とせばよいか、全然わからない！！！！！！！
MTG中も、MTGが終わっても、終始この感覚でした。
もう少し詳しく説明すると、作成されていたユーザーストーリーから導かれるようなデザイン/機能では、どのようなパターンで作ったとしても使いやすい物ができるイメージが全く沸かなかったのです。
ユーザーストーリーは構造的に整理されているので、それに基づけば改修箇所は自然に導かれるはず。また、作る機能も、サポートが一次対応して解決したことをそのまま実装すれば良いはずなので、やることはデザインをつくるだけのはず、、
なのにどうして、どうして、、、、、、、
解決のきっかけ
ところがこのMTGから数日後、僕のモヤモヤは完全に解決されることになります。
解決のきっかけは「SaaS Design Conference 2023」というデザイナーイベントでの、GOGENのCXO、金子剛さんの登壇内容でした。(非常に学ぶところの多い登壇だったので、未読の方は是非チェックしてみてください)
めっちゃくちゃかいつまんで発表内容をご紹介すると、サービスデザインのプロセスと重要性、そこにCXOが介在することで発揮できるバリューが網羅的に紹介されている、という内容のものでした。
そして、サービスデザインのプロセスの説明の中で、次のようなスライドが投影されていました。
このスライドが表示されたとき、ふと頭に思い浮かびました。
あれ、この話って機能改善のレイヤーでも全く同じことが言えるな、、。でも、今のプロジェクトって、体験的な整理はできていたっけ、、？
抱えていたモヤモヤが晴れた瞬間でした。
何が起こっていたのか ~問い合わせ起点での改善の、構造的な罠~
そう、先述の改善プロジェクトでは、プロジェクト内で、体験の話が乏しいままユーザーストーリーが作成され、施策の話が進んでしまっていたのです。そのため、起票されたユーザーストーリーが実現すべきユーザー体験とずれがあり、ベストなUIを考えられる状況ではなかった、というのが違和感の原因でした。
では、なぜこのような状況が発生してしまったのでしょうか？
一般に、0→1プロダクトや新機能の開発では、プロジェクトの発案者が体験の青写真を描き、そこからユーザーストーリーに落としている、というプロセスを取っていることがほとんどだと思います。かつて自分が企画をしたときも、一連のユーザー体験を想像したうえでユーザーストーリーを切り出していました。
そのため、暗黙的に「ユーザー体験」を前提にしながらユーザストーリーや施策の議論ができますし、プロジェクト内に一人以上の体験の解像度が高いメンバーの存在が担保されます。
ところが、「問い合わせ起点の改善」では、体験の青写真を描かなくてもユーザーストーリーが起票できてしまいます。というのも、問い合わせという事象自体が体験から切り出されたユーザーの機能要求であり、ほぼユーザーストーリーの様相を呈してしまっているからです。
「問い合わせ起点の改善プロジェクト」では、問い合わせの背景にあるユーザーが実現したかった体験を議突き詰め、その体験をシームレス実現できる機能は何かを検討したうえで、施策の議論を始めることが非常に大事になってきます。このプロセスを経ないと、汎用性が低く、体験に寄り添わないモーダルな機能をプロダクト上に設計してしまうことになります。
自分は、この構造を理解していないまま、ユーザーストーリーに落ちているのだから体験設計はもう考慮済みだろうという前提でUIを考えようとしてしまったため、泥沼にハマってしまった、という構図が違和感の原因でした。
まとめ
ユーザーストーリー単体からUIを作るのではなく、背後にあるユーザー体験を突き詰め、制約条件にしたうえでUIを作ろう
が本noteでお伝えしたかったことになります。
本来はデザイナーとして自分がアサインされている以上、自分がユーザー体験に常に責任を持ち、MTGの時点でこの観点から体験に議論を一旦戻すべきだったのですが、、w
反省とともに、このnoteを読んでくれた方が、僕の失敗を活かしてくれればとても嬉しいです。
【PR】オフィスに遊びに来ませんか？
弊社には素敵なバーがあります。デザインについて、組織について、是非お酒飲みながらディスカッションしましょう！XにDMください！
X : https://twitter.com/ohmori_takashi
アトラエでは採用も積極的に行っています！ご興味ある方は上記XのDMでお知らせください！
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？