誰にも気付かれないけどユーザーのための1割のこだわり
こんにちは。
お店のキャッシュレス決済「 STORES 決済 」のPMをしているMasakoです。
今回は、先日リリースした電子マネーのQUICPay対応の中で、誰にも気付かれないけどPMとしてこだわったところを紹介します。
プロジェクト概要
決済手段を増やすには、一言で書くと「決済サービスを提供している側（決済ブランド）の仕様を、自社プロダクトに組み込む」ことで実現できます。
ね、簡単でしょ？
と言いたいところですが、
決済手段といってもクレジットカード、電子マネー、QRコード決済など、様々な決済手段があり、また決済ブランドによっても各社のルールや、たくさんの仕様があります。
例えば、同じ電子マネーの交通系とQUICPayでも、細かなルールが異なります。
決済開始から◯秒以内に決済完了すること
レシートを印刷する時の表示項目が異なる
決済処理中に通信エラーが発生した場合のルールが違う
などなど。
これはほんの一例です。
数百ページに渡る決済ブランドの仕様書とにらめっこをしながら、
自社プロダクトの要件定義に落とし込んでいくのが、決済手段を追加するプロジェクトにおけるPMの大事なお仕事となります。
じゃぁ決められた仕様をただやれば良いだけ？
PMの人なら「最初から決められた仕様があるなら、PMとしては楽なんじゃないの？」と思われた方もいるかもしれません。
たしかに、1つの決済手段を追加するだけであれば、簡単かもしれません。
仕様書に書かれている仕様で、そのまま開発メンバーに実装してもらえば良いだけですから。
しかし、そのまま素直に自社プロダクトに組み込むと、"小さな違和感"があちこちに発生することになります。
同じ意味を指しているのに、決済ブランド毎に用語が異なる
決済ブランド毎にエラー画面のデザインが全く異なる
決済ブランドによって、決済取消できる期限が異なる
どれも些細な違いに見えるかもしれませんが、
ユーザー目線に立つと、この"小さな違和感"は、認知コスト・学習コストに繋がります。
私たちのユーザーは、お店のレジや決済をしている方なので、
毎日何度も STORES 決済 のアプリを立ち上げて使っています。
何の工夫もなく、ただ決済ブランド側のルールで実装してしまうと、
ユーザーに負荷をかけた使いにくいアプリができあがってしまうのです。
やったことは地味だけど
今回のプロジェクトは「QUICPayに対応するプロジェクト」ではなく、
「QUICPayが増えても、違和感がなく使い始められること」を意識して取り組みました。
といっても、決済ブランド側のルールがある中で、工夫できる余地は多くなく、具体的にやったことは決済ブランド側に仕様の交渉を粘り強くやるだけでした。
結果的には交渉した半分の要望は通りました。
細かな文言変更から、QUICPay利用開始までのリードタイムの短縮化（運用ルールを変えてもらった）など。
それでも、自分たちのプロダクトらしさを出せたのは全体の1割くらい。
（本当はもっとここをこうしたい）（ここのUI変えたほうが伝わると思うのにな…）など、実現できなかったことも沢山ありました。
また、交渉には時間がかかるので、プロジェクトとしては期間が長くなってしまう懸念があります。しかし、最終的にはユーザーの負担を減らすことができたので、長期目線では必要な交渉だったと感じています。
PMが介在する価値
QUICPay対応をリリースする前に、実店舗運営をしている数名のユーザーに協力いただきユーザーテストを行いました。
操作方法を案内したときに皆さんから「操作は今までと変わらないのね」「今まで通りだから、これならスタッフにもすぐ教えられるよ」と言っていただけたのが嬉しかったです。
"今まで通り使える" が今回こだわった部分なので、ユーザーの声に一安心しました。
今回のプロジェクトを通じて感じたことは、
仕様通りに作るだけでは面白くなく、やらされ感がでてしまうこと。
決められたルールがある中で、どんな工夫ができるのか？
ユーザーのために、どこまでこだわれるのか？がPMが介在する価値でもあり、難しくも面白いところでした。
今後は、体験にこだわりつつも、より早くユーザーに価値を提供できるよう精進してまいります。
おわり
弊社のメンバーでアドベントカレンダー書いているので、他の記事も良かったらみてください〜。
いいなと思ったら応援しよう！
