例: 運用アクティビティ H5 をどのように設計するか?

この記事は、次のようなニーズを満たすことができます。製品の詳細な設計アイデアを 0 から 1 まで知りたいですか?オペレーションによって提案されたアクティビティ H5 を実装する方法を知りたいですか?実際の事件を解体しますか?プロトタイプとPRDの前にどのような作業が行われます?

最近、オペレーション業務に携わる友人が、会社の H5 イベントのフォローアップをしたいと申し出てきました。彼にとって製品とのインターフェースは初めてであり、スムーズなコミュニケーションを望んでいたため、製品について学ぶための資料を勧めてほしいと頼まれました。

製品の方法論やデザインに関する情報はたくさんありますが、短期間のタスクであることを考慮すると、残念ながら適切なものはあまりありません。確かに、iOS ヒューマン コンピュータ インタラクション ガイドライン、啓示、ユーザー エクスペリエンス要素などの古典的な教材は、考えさせるものではありませんし、Liang Ning の Thirty Lectures on Product Thinking も、最初の学期の忙しさを乗り切るのに役立ちません。

ゼロから 1 までの体系的な情報はほとんどなく、存在するとしても、金儲けのためのコースの指導に利用されており、その質は大きく異なります。

オンライン コースでも、 BATメンター陣とともに 3 か月間の Tencent Classroom のプロダクト マネージャー向け入門実践クラスを受講していたとき、クラスメートから最もよく聞かれる質問は常に同じでした。「事例はありますか?」この場合、他の人の問題解決のアイデアを参考にして、自分の考えを修正することができます。しかし、完全なケースは非常に少なく、不完全な場合が多いです。この場合、直接説明する記事を書いたほうがよいでしょう。

アクティビティ関連の要求は、業務の高頻度の要求として、明確な計画目的、完全なライフサイクル、独立したロジック、柔軟で変更可能な形式を持ち、設計時には小型製品に近く、ケースとしての使用にも適しています。

この記事では、実際のアクティビティを使用して、アクティビティ タイプの H5 が紙の計画から完成品に至るまで、さまざまな紆余曲折を経てどのように進むかを説明します。

プロジェクト開始

日用品。

オペレーターは、H5 を作りたいと書いてある Word 文書を QQ で私に送信しました。資料を開いてみると、下図のような活動計画提案書でした。重要なのは、これは単純な活動計画ではないということです。

単純な活動計画であれば、ポスターで運営側が自ら解決できますが、登録条件の制限、ユーザー情報のパーソナライズ表示、データ収集、オンラインスコアリング、リアルタイムデータ更新、活動状況の経時変化、ユーザーインタラクション、複数ページの条件判断切り替えなど、特に複数の要素が重なり合う場合は、こうした総合的な検討作業をプロダクトマネージャーに引き継ぐことを決断すべきです。

主なプロセスに関しては、自分の考えに頼るにせよ、参考資料に頼るにせよ、注意深く行えば、確かにほぼ完璧なものを生み出すことができます。しかし、訓練を受けていない人は、その結果生じる異常なプロセス、分岐プロセス、逆プロセスについて考慮したり、認識したりすることすらありません。専門的なことは専門家に任せましょう。

要件の開始点として、このドキュメントを見てみましょう。

イベント企画

このドキュメントは実際のドキュメントとほぼ同じですが、製品に関連しない要素がいくつか削除されています。このような確実な需要については、真の需要と偽の需要を区別する時間を節約し、需要の製品化に集中することができます。

テキストを読むことでどのような情報が得られますか?

少なくとも、これはアクティブなキャスターが参加する競争イベントであり、視聴者がチケットを集めて投票し、キャスターがランキングを競い、賞品を選び、魚や豆のボーナスを獲得するイベントであることはわかっています。

オペレーションとさらに詳細にコミュニケーションをとる方法について話す前に、まずは当時の背景を簡単に紹介し、業界、ユーザー、製品、機能モジュールについて全体的に理解しておきたいと思います。

プロジェクトの背景

当社の製品は、ニッチな分野のプラットフォームベースのアプリです。ユーザーグループはレジャー釣り愛好家で、主に男性ユーザーです。これは、Cエンドユーザー向けのシナリオベースのサービスプラットフォームです（ YuepaoquanやGOSIKに似ています）。ソーシャルインタラクション用のライブブロードキャストモジュールがあり、商業収益化のためのモールを試行しています。

私たちのライブ放送は、一般の人のライブ放送とは異なり、釣りをテーマに限定されており、アウトドア志向で、余暇にアクティブに放送されることが多いです。そのため、ライブ放送ルームのデザインは特に派手ではなく、紅包の配布やギフト報酬などの定期的なインタラクションの設定に重点を置いています。ライブストリーミングではリアルタイム性とインタラクティブ性が重視され、日々の活動ではホストとユーザー間の協力が必要になります。

魚豆は仮想通貨です。アンカーが贈り物を受け取ると、その価値に応じて魚豆に変換されます。魚豆はアンカーの業務ラインである人民元に引き出すことができます。

ニーズを判断する

背景を理解した上で、現在に戻りましょう。運営から活動計画が渡されたら、次に何をするべきでしょうか？

多くの人はすぐにプロトタイプを描いて計画を立てます。

いいえ、馬鹿なことを言わないでください。この時点ですぐに描くプロトタイプは、単なる空想のプロトタイプにすぎません。誇らしげに文書を提出しても、運営側と技術側から深い軽蔑を受けるだけです。

では、この時点で何をすべきでしょうか?

あなたはその事の全体像を詳細に理解すべきです。誰も一度にすべての情報を送信することはできませんし、たとえ可能だとしても、誰も一度にすべての情報を受信することはできません。

信じられませんか？

コミュニケーションプロセスにおけるロスについては、前回の記事【基礎理論から実践まで、プロダクトマネージャーが持つべきコミュニケーションスキルとは？】をお読みください。 】

活動計画書には必要な情報しか記載されておらず、せいぜい基礎的な理解が得られる程度である、というのが現状です。あなたはその現象の背後にある考察について何も知らない。そのため、鉄は熱いうちに打つ、つまりオペレーション部門と協力して活動計画の詳細、手順、注意事項、役割行動を十分理解する必要があります...

どの程度理解できましたか？

理想的な状況は、運用部門よりも計画に精通していることです。

1. 主なプロセスを明確にする

物事の全体像を理解するには、マクロからミクロへと進む必要があります。最初のステップは、全体的な方向性と主要なプロセスを理解することであり、詳細は後回しにすることができます。コミュニケーションは一度や二度ではなく、設計と開発のプロセス全体にわたって行われます。

目的を理解するということは、デザインの全体的な方向性と原則を把握することを意味します。

この活動の目的は、アクティブなアンカーを主軸とし、福祉の向上を原動力として、この過程で、ユーザーのアクティビティ（チケットの保存、投票）を刺激し、商用トライアル（アンカーギフトパッケージ、ライブ放送ルームギフトパッケージ）を実施することです。

したがって、主なプロセスは次のようになります: アンカーの登録 - 視聴者が投票を収集 - 試合当日の PK - 上位 10 人のアンカーが最終候補に選ばれる - ギフト パッケージが選択される - ギフト パッケージが掲載される - アンカーがポイントを収集 - 基準を満たすと報酬が与えられる。

2. ビジネスプロセスの合理化

これはメインプロセスの大まかな理解にすぎません。さらにオペレーションと連携して、メインプロセスのサブプロセスと分岐プロセスを整理します。プロセスの進行は役割に依存するため、役割の重要なステップを決定する必要があります。

役割間の調整と相互作用は、グラフィックで表示すると、より直感的で明確になります。図で何千もの問題を解決できます。以下のホスト ユーザー タスク フロー チャートは、不明瞭なメイン プロセスをさまざまな役割ラインに整理します。

写真からもわかるように、アンカーラインがメインライン、ユーザーラインが補助ラインとなっており、点在する補助ラインをメインラインにどう統合するかを考慮した設計となっています。

ビジネスプロセス図

3. シナリオシミュレーション

ビジネスプロセスは複雑でも単純でも構いません。図にすると、前半はイベントの競争が激しく、後半はアンカーがお金を稼ぐ方法であることがわかります。シナリオを少し展開してみると、不合理な点がいくつか見つかります。

アンカーは常に興味によって動かされます。コンテストにノミネートされると賞品があり、ノミネートされた後も高額のコミッションを稼ぎ続けることができます。しかし、ユーザー側としては、名誉心からアンカーをリストにプッシュした後は、その後のサポートを提供する理由がなくなります。結局、生放送を見ること自体が娯楽行為であり、金儲けを語るということは本来の目的に反する。

そこで、当時、私はこのイベントを2段階の競争システムに変更することを提案しました。最終選考に残ったアンカーが同じステージで競争します。コンパクト感を演出し、リアルタイムのフィードバックを提供するために、リストは週ごとのリストに設定し、魚豆も毎週増やす必要があります。

運用部門はすぐに提案を受け入れ、新しいソリューションを実装しました。

要件は変更できますが、より効果的な結果を得るためには、理由と解決策を用意しておくことが最善です。需要製品化の担当者として、すべてはユーザーエクスペリエンスにかかっており、運用計画を改善する義務があります。

シナリオシミュレーションの段階では、図のようにマインドマップを使ってアイデアを整理・分析し、重複や漏れなく記録していきます。ペルソナの観点から彼らの懸念を想像することは、情報アーキテクチャを整えるのに役立ちます。

需要分析と分類

4. 機能構造

計画が与えられ、要件、ビジネス プロセス、シナリオが決定されると、運用部門との議論を中断して、アイデアを計画に変える作業に集中できます。
企業によってドキュメントの標準は異なり、製品マネージャーによって作業習慣も異なります。製品に決まった方法はありませんが、成功するドキュメントとは、基本的にあなたのアイデアやデザインを完全に実現できるものです。

アイデアを特定の機能ポイントに変換します。これは、グローバル機能構造図を使用して表現できます。論理性と完全性を確保するために、常に MECE 原則を使用して整理することを忘れないでください。

図からわかるように、クライアントの機能はそれぞれH5側とAPP側で担われており、APPは若干調整されて既存のライブ放送室のインタラクティブ機能を借用しています。 H5 側は、実際のアクティビティ情報と進捗状況の詳細を表示する、ゼロから設計されたページです。バックエンドは、クライアントの変更と連携して、ギフト パッケージの管理とデータのエクスポート機能を追加します。

グローバル機能構造図

名詞がバラバラなのが気になる方もいるかもしれません。テーマと創造性が決まった後のバージョンです。

一般的に、運用上必要な場合は、製品に引き渡す前に、アクティビティ プランですべての可能な部分を決定する必要があります。しかし、私はチームで最も優れたコピーライターであるため、運営チームはクリエイティブとコピーライティングの部分を私に引き渡すことに自信を持っていました（活動テーマは計画では常に空白でした）。製品計画を作成しているときに最終決定しましたが、ドキュメントの一貫性を保つために、ここでは最終版を使用します。

これは、チームメンバーが互いの強みを補完し、最大限の能力を発揮することです。もしそうなら、それは素晴らしいことです。そうでなければ、全員が自分の仕事をすべきです。

製品ソリューション

抽象的な機能ポイントから技術的な実行可能ファイルへの変換は、プロトタイプと製品ドキュメントを通じて実現されます。

製品計画がプロトタイプの形で確立された後、運用と技術でそれを検討することができます。要件が満たされていること、技術が実現可能であること、コストが削減されていることを確認した後、設計、テスト、開発に引き渡されます。このプロセスで問題が見つかった場合は、基本的に異論がなくなるまで何度も修正する必要があります。その他の書類は後で記入する必要があります。

プロトタイプは、製品ドキュメントの最も重要な部分です。製品の形式、複雑さ、開発の進行状況により、他の種類の製品ドキュメントにはトレードオフがある場合がありますが、プロトタイプは不可欠です。プロトタイプは、製品の最終的な形と機能を示し、特に小規模なチームでは、全員のコミュニケーションの合意となります。

1. 全体コンセプト

この設計では、アクティビティの有効なアクションはAPPライブ放送ルームでのインタラクションであり、アクティビティ情報はH5側にあります。設計するときは、両端の情報の連携に注意してください。関連するバックグラウンド機能についてはここでは省略します。

APPとH5の接続ポイントは、ライブ放送ルーム内の広告スペースとホームページ上のバナー広告スペースです。

アプリとH5のメインインターフェース

ホームページバナーではユーザー情報を取得し、ライブ放送ルームH5ページでは現在のライブ放送ルームホストの競技情報を取得します。アンカーであってもユーザーであっても、ライブ放送ルームで H5 を切り替えると、現在のプロセスが中断されます。

したがって、H5 を設計する際には、メイン ページに情報を集中させ、階層を減らして情報を手元に置いて、検索時間と手順を短縮する必要があります。リアルタイム性を重視した一部の情報は、ライブ放送ルームのコメント欄にメッセージ形式で報告されるので、ユーザーやアンカーが情報を見るために頻繁にページを切り替える必要性が減ります。

2. H5イベントページ

H5 アクティビティ ページの全体的なフレームワークはフラットです。学習コストを削減するために従来の方法に従い、比較的低頻度の情報、報酬、ルールを第 2 レベルに配置し、高頻度のランキングとアンカーの進行状況を第 1 レベルに配置します。

アンカー情報列とリストを例に、デザインのアイデアを説明しましょう。

（１）アンカー情報バーのデザイン

アンカー情報列はリストよりも多くの機能があり、ユーザーやアンカーが最初に気にする情報です。実際、2 段階のスケジュール、複数の状態、複数のスコア統計、魚豆比ボーナスを理解していれば、アンカーの設計はより複雑になる必要があることがわかりますが、これらの複雑さは可能な限り設計者とバックグラウンド プログラムに任せ、ユーザーはいつでもシンプルさと必要性の原則に従う必要があります。

1) 未登録 - 出発期間

アンカーのステータス情報バーのデザインは段階的に説明されています。まず第 1 段階を示します。下の図に示されている順序は、未登録 -> 開始期間 - 非試合日 -> 開始期間 - 試合日 - トップ 10 -> 開始期間 - 試合日 - トップ 10 以外です。 （登録の成功または失敗、失敗の理由はここには表示されません）

デザインのアイデア:

1. ステータス バーには、ホストの現在のスケジュールが表示されます。スケジュールには、「出航に向けての努力」と「宝物を見つけるための長い航海」の 2 つの状態があります。
2. 未登録ユーザーの場合、賞品、ルール、登録期限。
3. 登録した新人は、現在のタスクに注意を払う必要があります。コンテスト当日までに、投票を募り、投票を蓄積する必要があります。投票を蓄積するためのルールは、土曜日のみが投票コンテストであるということです。残りの時間は、ユーザーはライブ放送を視聴して投票を蓄積する必要があります。ここで、アンカーとファンに同時にリマインダーを送信できます。
4. 自分の順位と進捗状況に注目してください。トップ 10 の場合、自分と最も近い競争相手との差に注目してください。トップ 10 以外の場合、自分と 10 位との差に注目してください。表示項目は異なります。
5. アンカーとユーザーの可視情報を区別する必要はありません。

アンカー情報欄 - 開始期間に登録されていない

2) 航海期間 - 活動終了

第 2 段階の写真の順序は、長い航海期間 - ユーザー バージョン -> 長い航海期間 - アンカー バージョン - 詳細を折りたたんだ状態 -> 長い航海期間 - アンカー バージョン - 詳細を展開した状態 -> アクティビティの終了です。

デザインのアイデア:

1. 魚豆の詳細情報はアンカーにのみ表示されるため、長距離段階ではユーザーバージョンとアンカーバージョンを区別する必要があります。
2. セーリングレースのアンカーの焦点はすべて魚豆に集中しているので、今週の魚豆の報酬を直接見ることができます。
3. 魚豆ボーナスは最終結果です。ユーザーは非常に細かいという事実に基づいて、予測可能な説明作業を減らすために、ここでの変換関係は、開始点から終了点まで明確に表現する必要があります。週間スコア-スコア魚豆変換率-基本魚豆に比率を掛けたもの-報酬魚豆。
4. 可能な限り、グラフを使用してください。1 つのグラフで何千もの問題を解決できます。明確な視覚的な手がかりに注意し、データ ポイントが多数ある場合はパーティションを使用してデータ ポイントを表します。
5. ユーザーが混乱する場所にルールジャンプを追加します。ここの魚豆マイニング ガイドは、元のルールの説明の一部です。

アンカー情報バー - 航海期間終了

3) アンカー バーの状態を説明するためにアンカーの全プロセスが使用される場合でも、上記でキャプチャされたプロトタイプ図はその一部にすぎません。完全なプロセスは、以下のアンカー バー ページのフローチャート - アンカー バージョンで確認できます。このフローチャートでは、上の図に示されていない分岐プロセスと異常なプロセスが完了します。

アンカーバーページのフローチャート - アンカーバージョン

アンカー情報バーのプロセスは比較的複雑で、情報量が多く、ロールの観点に分かれており、完全なライフ サイクルを備えています。プロトタイプ、ページフローチャート、デザインアイデアの説明により、小さな製品がどのように形成されるかはすでにわかりました。

しかし、設計プロセスは必ずしもスムーズではありません。初期段階で十分なコミュニケーションをとっていても、プロトタイプのレビュー時に需要家側が要件を変更したり、追加したりすることは避けられません。次のパートでは、投票リストの設計を活用して要件を変更する問題について紹介します。

（２）セーリングスタートリスト投票

アンカー情報列は、リストがアンカーのタイムラインと一致しないため、2 つのリストの形式を採用しています。Qihang と Yuanhang は 2 か月間並行して重複しています。ユーザーが 1 つのアンカーだけをフォローしているとは想定できないため、レイアウトは 2 つのリストで並行しています。

最初のリストである投票開始リストのデザインはかなり特殊です。元々は今週のリストと先週のリストの通常の縦型リストでした。しかし、プロトタイプのテスト中は、運営側は競争を弱めることを期待している。その理由は、前回のランキング競争がアンカーの間で不満を引き起こし、コアユーザーグループからのフィードバックもあったためです。

私たちのイベントの目的を覚えていますか? 最も人気のあるアンカーを選ぶことではないので、変更される可能性があります。

問題：

要求は正しいものの、それを満たすのは困難です。

1. 毎週のトップ 10 + 500 票のルールは変更されず、全員がトップ 10 を直接確認する必要があります。
2. 競争要因を軽視し、リストのランキングを明らかに弱める。
3. ストリーマーとファンはリアルタイムのランキングを見て自分の行動を決める必要があります。
4. リストは合格システムではなく、ランキングシステムに基づいています。最後の瞬間までどの出場者が優勝者かを決定することは不可能です...

本質的には、リストやリアルタイムのランキングを提示しなければならない場所で、ランキングを弱めるという要件は、カラフルな黒のようなものですよね？

解決：

最終的な解決策は、アンカーとそれを気にするファンの間のランキングのギャップをアンカーのステータス情報列に移動することです。リストは、すべてのアンカーの垂直ランキングから、トップ 10 を独立した領域に分割する水平スクロール領域に変更されます。なぜなら、最も熾烈な競争は頂点で起こるからです。プラットフォームやアンカーの場合、トップ 10 に入るだけで十分であり、順位は重要ではありません。

トップ 10 の横スクロール エリアに正当なスタートを与えるために、ユーザー ベースと製品の機能を組み合わせて、最初のステージをすべてのアンカーが毎週 10 枚のチケットを競う (ランキングを弱める) と創造的に定義し、スクロール エリアをスタート席を競うエリアとして定義します。UI デザインでは、船に乗ったイメージを使用して認識を強化します。ゲーム終了時に 10 席に残っているアンカーが勝者となり、正常に出航できます。第二段階に入り、海に出航し、遠くまで航海して宝物を探し、魚豆の宝鉱山を採掘します。

（追記：この操作上のパーソナライゼーションの制限により、イベントの創造性とテーマがようやく完成しました）

プロトタイプの完成:

デザインのアイデアは次のとおりです。

1. 大会のスコア統計は土曜日の12:00に締め切られ、日曜日の深夜に新しい大会週が始まるため、今週のランキングに加えて、先週のランキングも必要です。先週のランキングでは、スタートに成功したアンカーのみを表示する必要があります。
2. 今週のリストは、スタート席競争エリアと一般縦リストエリアに分かれており、準トップ10と他のプレイヤーとの差が直接広がります。
3. すべてのライブ出場者はライブ放送アイコンでマークされるため、ユーザーはすぐに参加して投票することができます。
4. トップ 10 について最も直感的なのは、それ自身のランキングです (ここには表示されていません)。他のトップ 10 は一目ではわかりにくく、ランキング競争が弱まります。
5. 詳細を確認したいユーザーは、座席競争エリアを手動でスクロールして詳細を表示できます。
6. Top10 のしきい値は 500 票であるため、実際の人数は 10 人未満になる可能性があり、そのため、縦方向のリスト領域の 11 番の値はサーバーによって制御可能である必要があります。

実際、デザインのアイデアは、機能構造、プロセス、ページのプロトタイプなど、あらゆるところに反映されています。ドキュメントを出力するときにも組み込まれるため、必ずしも書き留める必要はありません。ただし、設計は合理的である必要があり、他の同僚から説明を求められた場合に答えて書き留めることができるように、設計について明確な考えを持っている必要があります。

3. アプリ

APPはすべて既存のライブ放送室機能を有効に活用しています。活動は段階的に行われるため、元のAPPのロジックへの影響を最小限に抑えるように努めています。ニーズを満たしながら、技術コストを考慮し、既存のモジュールを再利用しています。

APP側では、H5アクティビティへのトラフィックの誘導に留意し、ゲーム前、ゲーム中、ゲーム後にコメントエリアとギフト報酬エリアでガイダンスとリマインダーを提供する必要があります。潜在的な参加ユーザーの動員と無関心なユーザーへの妨害防止のバランスに注意する必要があります。

APPのプロトタイプ画像の一部は次のとおりです。全体的なテキストとパターンはテーマスタイルと一致しています。ギフトエリアでの指定ギフトのクリックと非クリックは、アクティビティの進行状況を反映し、優れたガイダンスを提供します。

製品計画の他の部分も同様のプロセスに従って形成されるため、個別にリストされることはありません。必要に応じて、完成したプロトタイプへのリンクが後で提供されます。

開発と発売：

プロトタイプと関連ドキュメントが運用部門で確認され、技術部門とやり取りされた後、次のステップである開発に渡すことができます。

次に、次の手順に従って続行します。

1. 開発期間中は緊密なコミュニケーションを維持し、開発者からの変更提案に注意を払います。
2. オンラインになる前に、受け入れ要件が完全に満たされているかどうかをテストします。
3. オンラインになった後は、各重要ノードの運用担当者と緊密にコミュニケーションを取り、動作やデータが正常かどうかに注意してください。
4. イベント終了後はプロセスを見直し、経験をまとめ、次回は改善します。

オンライン化は、製品をテストするための試金石です。オンライン化後、小さな問題も大きな問題も発生する可能性があります。問題の数については、多くの要因とチームによって異なります。もちろん、志があるなら、少なくとも責任と引き継ぎのつながりにおける落とし穴を減らすべきです。強さを向上させることは、常に人の基本的な資質です。

結論

これまで、アクティビティ H5 のライフ サイクルを 0 から 1、そして 100 まで見てきました。

プロジェクトがアイデアから始まるか、活動計画から始まるかに関係なく、また、初期段階の議論に参加するかどうかに関係なく、製品として、製品設計を開始する前に、まず需要者のニーズを詳細に理解し、次にビジネスプロセスを整理し、ニーズを具体的な機能ポイントに変換し、機能を全体的に配置して割り当て、プロトタイプを描き、計画がニーズを満たしていることを需要者と確認し、プロトタイプ、フローチャート、マインドマップ、テキスト、表などの製品ドキュメントの最終バージョンを技術部門に渡す必要があります。その後は、製品の導入・発売までフォローし、最終的な導入効果が期待通りとなった時点で、作業は一旦終了とさせていただきます。

修正や要件の変更に関しては、提案が早ければ早いほど良いですし、問題が早く発見されるほど良いです。基本的なポイントは、プロジェクトが開発フェーズに入ったら、勝手に変更することはできないということです。これは、重要なロジックや大きな問題がない限り、開発フェーズの終わりに特に当てはまります。

この記事を最後まで読めば、あなたはスタートを切ったことになりますが、前進し、改善するにはまだ長い道のりが残っています。