タベリー「グループ共有機能」の仕様
タベリーというプロダクトへ、グループ共有機能をリリースするにあたり、作成した仕様書を公開する。
仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。
仕様書の前提となる考え
仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。
そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。
この環境では議論のすべてが口頭で実施される。たとえば僕が作成したUIも一緒の画面を見ながらブラッシュアップの議論ができる。そんな状態だ。
そこで仕様書の立ち位置を以下としている。
- 価値から認知獲得までの「Why」「What」「How」がミニマムで記載された設計書
- 意思決定のプロセスと内容を端的に追えるストック情報
- これを満たすためのドキュメントであれば十分である。実装における空白エリアは口頭で埋めることができる安心感がある。「完璧な仕様書」は志向していない。その必要性や姿はチームに合わせるべきであるというのが僕の基本的な考えだ。
グループ招待機能仕様
達成したいこと
料理にまつわる最も強いコミュニティである、家族などのグループのコミュニケーションをサポートし、置き換える手段の提供。以下の対話を置き換える対象と考えている。
- 献立予定の共有（「今夜の料理何？」）
- 買い物リストの共有（「帰りにxxxを買ってきて」）
- 献立作成のリクエスト（「食べたいモノある？」）
ユーザーフロー概略
1 / 招待者 — Must Login
招待者は会員登録をマストとする。
- マイページ > グループを招待する
- 価値を訴求するページ > 招待する（未登録ユーザーの場合、会員登録へ。完了後、2へ戻る）
- シェアシートから招待（招待状は1通あたり1名に有効、有効期限は48h）
- 招待完了ページ > ☓ >ホームへ
2 / 被招待者 — Guest Acceptable
ゲストでもOK
- DL > ホーム > はじめる
- 初回起動時のみ、ポップアップで「招待された人は~~~」 > 了解
- メール or LINE からinvitationリンクを踏む
- モーダル「~さんが招待しています」 > 参加する
- トップ > 「献立がシェアされています」
全体UI像
以下がドラフトである。
1 / マイページ
共通の仕様
- 未招待と招待後でマイページUIは上記のように変わる。
- グループに参加している人は、だれでもグループへ招待できる。
- リストページでは「あとX名までグループに招待できます」と表示。上限は自分も含めて5名。
- 共有人数が5人に達した場合は、「グループへ招待する」ボタンを表示しない。かつ、リストの下のテキストを「グループは5人が上限です」に変更する。
共有解除
- オーナーのみ、自分以外の誰でも共有解除できる。それ以外の人は、自分自身のみ解除できる。
- 共有解除時は「Userさんとの共有を解除します よろしいですか？」のアラートを出す。
2 / 価値訴求ページ(LP)から招待の流れ
招待の流れ
価値訴求ページ→「グループへ招待する」ボタンの後はステータスによって分岐する。
訴求軸
- 献立の予定がシェアできる
- 買い物リストがシェアできる
- タベリープラスをシェア
3 / 献立予定のUI
- 「献立を自分以外の誰かが作成したこと」が通知とセットで認知できる
- 予定の有り/無し、ペアリングの有り/無しという4パターンに耐えうる汎用性
- レシピのAUTHERという誤認を与えない
などを同時に満たすUIである必要がある。結果として以下とする。
自分のアイコンは表示するか？ — YES
- ペアリング時は表示されたほうが良い（アイコン有り/なし）より（アイコン常に有り/中身が違う）の方が認識しやすいだろう。
- またペアリングを使っている、ということが一目瞭然になるのも良いかな。
献立変更時はどうするか？ — 作成者のみ表示
- 献立の変更有無にかかわらず、作成者を表示。
- 献立は作成者に所有が紐づくため。
4 / Inviteeの導線仕様
招待体験/UIで達成すべきこと
- 共有方法が中長期に渡って安全であり、運用マインドシェアを奪わない。
- 招待を受けてインストールした人が、初回起動時に何をすればよいか理解できる。
- 招待を受けていない人の初回体験に負を残さない。
論点 : アクション忘れ
inviteeに「アプリをDL」 + 「リンククリック」という2ステップある。リンククリックというステップを忘れ、次のアクションがわからないということがおきうる。解決策として以下をUIで表現する
- 招待者が招待後に被招待者がやるべき事を伝える (1. アプリDL, 2. 招待リンククリック)。
- ペアリングがうまくいかない場合に招待者にサポートしてもらう。
- pro: 初回体験に負の影響がない
- con: invitee自身が解決する道筋がない
5 / メール文面
プロセスの全体を把握できる、アクションが迷わない、迷っても解決のためのアクション ができるように。以下サンプル。
6 / 招待リンクタップ後の挙動
グループへの参加許諾、参加するとできることを端的に伝える。なおタップするユーザーの性質によって大きく4パターンに挙動が別れる。
エッジケースとして「すでにタベリープラスに加入中の人がグループに参加した場合」に通知をいつどう送るか。グループのペアリングが完了時に上記の分類に当てはまる方には通知を送る、でよさそう。
通知の復帰導線 → 積み残し
本機能を利用する上で価値のある通知が届けることができる。システム設定で通知を許可していないユーザーに通知許可を促す導線を用意する。リリース時は除外。
8 / 課金のシェアについての仕様
- グループの参加者の誰かがタベリープラスに加入していれば、全員がタベリープラスを利用できる。
- タベリープラス加入者が訴求ページのリンクをタップしたときに表示されるモーダルには「加入済みです」と記載 通知周りは7を確認。
9 / グループ解除時の献立の表示
- グループにはそのグループに参加しているメンバーが作成した献立がすべて見える
- グループ解除時は、「自分の過去に作った献立」のみがカレンダーに反映される。
- 編集者は関係ない。
10 / バージョン配布について
1.5.0以前のバージョンの人は、グループ招待を受けられない。そのため、強制アップデートが必要となる。強制アップデートの影響を最小化するため以下の手順とする。
1.5.0では「グループを招待する」という導線を消した状態でアプリを配布。
その普及率が80%を超えたあたりで導線を復活させた1.5.1をリリース。強制アップデートを行い、機能自体は1.5.1で開放することとする。
11 / プレスリリース → 価値を言語化できないのでやめる
機能紹介+アルファのリリースを出す。目的はユーザー伝達と方針の認知獲得。ただしこのままだと面白くない。フックを入れる。
→プレスリリースを書きましたが、パンチが弱くて辞めました。
12 / Datastoreの仕様
User EntityにGroupIdをもつ。一人あたり必ず一つのユニークなIDをもつ。
Group Entityが新たに作成。このGroupIdあたりのUserIDが2以上のグループは実際にユーザーがつながっているグループである。
以上。本来であればKPIの設計も組み込むのだが、それは現状口頭とダッシュボード直編集で済むので仕様書には掲載していない。
（了）
本来、仕様書というのは会社の特色が現れ、またなかなか表に出てこないアウトプットだと思う。しかし僕は「仕様書自体に一切の価値がない」と思っている。
価値があるのは仕様書ではなく「プロダクトを発明していくプロセス」自体にあり、それは10Xのチームだから再現するものでもある。ので、仕様書は僕らのチームの片鱗を感じてもらえればと思い公開に踏み切った。繰り返しになるが、10Xのプロセスが気になる、そのなかで力を発揮してみたい、という方はぜひこちらよりご応募下さい。
※ タベリーは2020/09をもってクローズし、現在はStailerという小売体験を10xするためのB2B2Cモデルのプロダクトに取り組んでいます。