タベリーのグループ機能_仕様書

タベリーというプロダクトへ、グループ共有機能をリリースするにあたり、作成した仕様書を公開する。

仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。

10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい!」という方はぜひこちらから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。

仕様書の前提となる考え

仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。

そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。

この環境では議論のすべてが口頭で実施される。たとえば僕が作成したUIも一緒の画面を見ながらブラッシュアップの議論ができる。そんな状態だ。

そこで仕様書の立ち位置を以下としている。

この前提のもとに、以下の仕様書を公開する


グループ招待機能仕様

達成したいこと

料理にまつわる最も強いコミュニティである、家族などのグループのコミュニケーションをサポートし、置き換える手段の提供。以下の対話を置き換える対象と考えている。

ユーザーフロー概略

1 / 招待者 — Must Login

招待者は会員登録マスト

  1. マイページ > グループを招待する
  2. 価値を訴求するページ > 招待する(未登録ユーザーの場合、会員登録へ。完了後、2へ戻る)
  3. シェアシートから招待(招待状は1通あたり1名に有効、有効期限は48h)
  4. 招待完了ページ > ☓ >ホームへ

2 / 被招待者 — Guest Acceptable

ゲストでもOK

  1. DL > ホーム > はじめる
  2. 初回起動時のみ、ポップアップで「招待された人は~~~」 > 了解
  3. メール or LINE からinvitationリンクを踏む
  4. モーダル「~さんが招待しています」 > 参加する
  5. トップ > 「献立がシェアされています」

全体UI像

以下がドラフトである。 draft

1 / マイページ

UI遷移図

共通の仕様

共有解除

2 / 価値訴求ページ(LP)から招待の流れ

招待の流れ

価値訴求ページ→「グループへ招待する」ボタン の後はステータスによって分岐する。

table

訴求軸

invitation_ui

3 / 献立予定のUI

などを同時に満たすUIである必要がある。結果として以下とする。

pairing

自分のアイコンは表示するか? — YES

献立変更時はどうするか? — 作成者のみ表示

4 / Inviteeの導線仕様

pairing

招待体験/UIで達成すべきこと

論点 : アクション忘れ

inviteeに「アプリをDL」 + 「リンククリック」という2ステップある。リンククリックというステップを忘れ、次のアクションがわからないということがおきうる。解決策として以下をUIで表現する

5 / メール文面

プロセスの全体を把握できる、アクションが迷わない、迷っても解決のためのアクション ができるように。 以下サンプル


献立アプリ「タベリー」への招待です。献立を共有すると、「これ食べたい」が簡単できます。

2ステップで「ゆまじろう」さんと共有できます!

①アプリをインストール

https://tabe.ly/hogehoge (インストール済の方は②へ)

②インストール後、以下の招待リンクをタップ

https://tabe.ly/hogehogehoge

(有効期限 : 131 10:59)

招待を受けるには、アプリのバージョンが1.5.0以上である必要があります。

何かご不明の点がありましたらタベリー運営事務局まで info@tabe.ly


6 / 招待リンクタップ後の挙動

グループへの参加許諾、参加するとできることを端的に伝える。なおタップするユーザーの性質によって大きく4パターンに挙動が別れる。

invitation_ui invitation_table

エッジケースとして「すでにタベリープラスに加入中の人がグループに参加した場合」に通知をいつどう送るか。グループのペアリングが完了時に上記の分類に当てはまる方には通知を送る、でよさそう。

通知の復帰導線 → 積み残し

本機能を利用する上で価値のある通知が届けることができる。システム設定で通知を許可していないユーザーに通知許可を促す導線を用意する。リリース時は除外。

8 / 課金のシェアについての仕様

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のプロセスが気になる、そのなかで力を発揮してみたい、という方はぜひこちらよりご応募下さい。