nimaruのチームの一員として新機能のUI/UXデザインを担当
0. 概要
青果流通は市場流通と直接流通の2パターンに分けることが出来ますが、nimaruはそのうち8割を占める市場流通側のDXを進めるSaaSです。
ユーザーは出荷者と流通事業者ですが、料金を払うクライアントは流通事業者のみです。彼らはLINEを窓口にnimaruにアクセスすることが出来、取引業務や帳票作成を簡単かつ効率的に利用できる点を評価しています。 nimaruの開発チームは多くのクライアントから強い要望を受けていた、出荷者が流通事業者に事前に出荷量を連絡する機能(出荷予約機能)の開発を決定しました。開発チームの中にはデザインのスペシャリティを持ったメンバーがいなかったため、私が開発チームの一員としてUI/UXを担当することになりました。5つのセクションに分けてUI/UXデザインと改善をリードしました。
出典:いちばんやさしいグロースハックの教科書
1. ユーザーの課題は何か(KGI&Analytics)
プロジェクト当初、私には青果流通現場の知識があまりなかったので、ユーザーにとって本当に役に立つプロダクト開発をこのまま進めることは難しいと感じていました。 そこで、この機能を特に欲していたJA松本ハイランドに業界と業務に関するインタビュー、そしてプロダクト開発中の定期的なヒアリングをお願いすることにしました。私とkikitoriのオーナーと二人でヒアリングを進める中で、「事前に出荷量を把握したい」という要望がなぜ強くなったのか知ることが出来ました。 JAは農家の所得を高めるべく、農家の農畜産物を集荷して数量や品質を均一にした後に、需給の動向に合わせて卸売事業者や小売事業者に有利に販売する事業を行っています。これを有利販売と言いますが、JAの最も主力な事業になります。よってKGIはJAの有利販売事業全体の利益上昇率になります。
しかし他の商材と比べて自然の影響を受けやすいため農作物は供給の予測が難しく、JAが出荷量を事前に把握することは難しいのです。本JAでは紙の出荷予約表を用いて、事前に出荷量を把握しようとしていました。しかし、「事業所に届ける面倒さ」「変更の手間」といった原因から、出荷予約表を活用する出荷者はあまりいませんでした。そこで**「高精度」かつ「簡単」**に出荷量を把握するシステムを最短で構築することが、有利販売を加速するにあたって最善の施策だと仮説を立てました。
JA松本ハイランドで使用されていた出荷予約表
2. 課題解決の進捗を数字で見える化する(KPI)
SaaSであるnimaruの強みは、ソフトウェアを導入して終了ではなく、徹底的にクライアントの課題を解決し続けることです。そのためには利用状況を継続的にモニタリングしながら改善施策を打っていくことが必要です。 利用状況をモニタリングすべく、以下の条件に当てはまる指標を策定することにしました。
- ROIが高い
- 理解しやすい
- 期間ごとに比較ができる
- 行動につなげやすい
候補の中から選出したのは**「出荷予約内容の修正回数」です。出荷予約表(既存のやり方)の場合、面倒なため「出荷予約内容の修正回数」は出荷者平均で0.5回でした。これをまず1回以上**に設定すれば「正確」かつ「簡単」に出荷量を共有できる仕組みになったと言えるとしました。 ※定性的な分析もできるようwebセッションリプレイツールやユーザーインタビューの準備も行っています。
3. どんな方法で課題を解決できるか？(Hack案出しパート)
プロジェクト当初に徹底的にユーザーに向き合い、深く共感できたことはデザイナーである私にとって大きな収穫でした。課題解決の提案が広がり、よりPDCAサイクルをスムーズに進めることが出来るからです。私たちは、KPIを達成し出荷者と流通事業者のそれぞれが課題を解決するにあたって必要なユーザーストーリーをまとめ、プロダクトの全体像をチーム内で共有することにしました。
ユーザーストーリーを列挙した後、ROIを見積もりながらファーストリリース(KPIが測定する上で最小限の機能を含むリリース)での範囲とリリース日を調整しました。最も重要となるユーザーストーリーは**「出荷者は1週間分の出荷予約を連絡できる」「流通事業者は1週間分の担当する出荷者の出荷予約を確認できる」**の2つであると設定しました。ファーストリリースではこれらのユーザーストーリーを叶えるプロダクトを実装し、先ほど挙げたKPIと有利販売にいい影響を与えられたかを検証します。
4. 理想のプロダクトはどんなカタチをしているか？(Hack実行パート)
ユーザーストーリーを決定したので、どういうカタチであればそれらが叶えられるのかを検討していきます。この段階で気を付けたことは以下の4つです。
- 不確実性の高い仮説から順番に検証していく
- 複数のパターンのプロトタイプで検証していく
- プロトタイプの作成は出来るだけ早く安く進める
- クライアントからのフィードバックを効率強く得るために、触れるプロトタイプを作成してからフィードバックの機会を作る
重要なユーザーストーリーから順に、それに関係する情報構造上やレイアウト上の不確実性を出来るだけ早いスパンでつぶしていく必要があります。ボタンや色など表層部分の検討するのは後です。そのために「出荷者は1週間分の出荷予約を連絡できる」「流通事業者は1週間分の担当する出荷者の出荷予約を確認できる」というユーザーストーリーを叶えるにあたって考えられる画面遷移や情報構造を最低限チームメンバーに共有できるプロトタイプを作成しました。プロトタイプを複数パターンの手書きのスケッチにしたのは最低源のコストで情報構造上やレイアウト上の不確実性をつぶせるからです。
※ユーザービリティの検証にあたってプロトタイプの精度は関係ないという研究
チーム内での検討の結果、案1の導線で決定しました。
同様の手法で他のユーザーストーリーに係る画面遷移や情報構造を決定しました。その後、レイアウトも含めた表層面の調整も進めるべく、高精度なプロトタイプを作成していきます。ボタンや色など論点とそれに係るパターンを示しながら、表層面も整えていき、1つの動くプロトタイプを作成しました。
この段階で初めてクライアントにレビューを頂きました。触れるプロトタイプの作成が出来ているので、ここではユーザーストーリーの追加や表層部分でのレビューを効率よく収集することが出来ました。このレビューと、エンジニアと開発可能性を踏まえたコンポーネントの調整を踏まえた後デザインFIXしました。
※結果に結びつきやすいユーザーフィードバックのタイミングに関する研究
5. 課題解決は出来ているのか？(Check)
エンジニアがMVPの意図を漏らさず実装できるように、継続的にコミュニケーションをとりながら無事リリースを迎えることが出来ました。 リリース後はKPIであった「出荷予約内容の修正回数」をトラッキングし続けています。開始1か月間の修正回数は0.8回。まだKPIの目標を達成できていないので、ROIの高い施策から打ち続けてKPI達成に向けて改善を進めています。
