お久しぶりです。
個人で開発している旅行プラン共有アプリをリリースしてから、約6ヶ月が経ちました。
リリース直後はUIの微調整や軽微なアップデートを中心に進めていましたが、
運用を続ける中で、ある大きな課題に直面しました。
それは、ユーザーが思ったように増えないということです。
特に、アプリの中核となる「お店の登録」がほとんど進まない状態でした。
当時の設計では、お店はオーナーの方に直接登録してもらう前提だったため、
- お店が登録されない
- プランが作られない
- 見るコンテンツが増えない
- ユーザーが定着しない
- その結果、お店側にも登録メリットが生まれない
という、完全な悪循環に陥っていました。
正直なところ、この構造のままでは
どれだけUIを磨いても、どれだけ細かな改善を重ねても、
状況は変わらないと感じました。
そこで大きな判断として、
お店の設計そのものを見直すことを決めました。
これまでの「オーナー登録を待つ」設計から、
ユーザー自身がお店を作成できる仕組みへと方針を転換しました。
ユーザー作成のお店は、Googleマップや既存の口コミサービスのように、
まず情報が集まり、後から公式管理へ引き継がれることを想定しています。
ただし、この変更は単に「誰でも作れるようにする」だけでは済みません。
ユーザー作成という自由度を持たせる以上、
- オーナーからの公式アカウント申請
- 情報の修正・編集申請
- 削除申請
- 不正利用を防ぐための申請フロー
といった仕組みを、あらかじめ整備する必要がありました。
結果として、
既存の設計変更 + 新機能追加を含む、かなり大掛かりなアップデートになりました。
まず、この設計変更で一番大事にしたのは、オーナー向けの機能設計でした。
アプリにとってお店の情報が重要なのは間違いありません。
しかし一方で、オーナーから「掲載をやめたい」という意向があるにも関わらず情報が残り続ける状態や、
ユーザーによって誤った情報が登録されてしまう状態は、健全とは言えません。
そこで今回の設計変更では、
「情報の自由度」と「管理・責任の所在」をどう両立させるかを強く意識しました。
具体的には、
お店情報の変更履歴を前提とした設計に切り替え、
複数のユーザーが関わる場合でも、差分を把握できる構造にしました。
その上で、オーナーが関与できる申請フローを整備しています。
また、お店の画像を扱う以上、
第三者が写り込むことによるトラブルのリスクも無視できません。
そのため、写真をアップロードする際には、
注意事項を必ず表示し、同意がない限り投稿できない仕組みを取り入れました。
あわせて、不正な情報や不適切な投稿に早く気づけるよう、
通報機能もこの設計変更に合わせて実装しています。
やるべき方向性自体は比較的明確でしたが、
既存設計の変更に加えて複数の機能を同時に実装する必要があり、
結果として作業量は想像以上に大きくなりました。
それでも、「後から継ぎ足す」よりも
最初に運用を見据えた設計にしておく方が、結果的に健全だと判断し、
時間をかけて実装を進め、無事アップデートを行うことができました。
今回はお店の設計変更について書きましたが、この変更をきっかけに、UI・運用・セキュリティ面でも多くの改善を進めることになりました。
これらについては、また別の記事でまとめようと思います。
