Close

エンドツーエンドのデモ


エンドツーエンドのデモは、提供予定の最終的な製品やサービスと、顧客がそれらとどのように関わるのかを視覚的に表したものです。

このプレイの目的

ソリューションを視覚化すると、顧客や関係者が提供される価値を理解し、フィードバックしやすくなります。

ヘルスモニターで、ワンページャー概念実証の概念実証の改善に取り組んでいる場合は、このプレイを実行すると役立つでしょう。

詳細を見る
なぜこれが必要なのか

建築家や都市プランナーが縮尺模型を作成したがることをご存知ですか? これには理由があります。作業が多岐にわたるため、施工者が各窓やドアがどう設置されるかを把握する最善の方法は、建物全体の外観を視覚的に表現することだからです。

それはオフィスにもあてはまります。大規模なシステムの一部として機能しなければならないことを忘れて、この案件だけを完璧に磨き立てることに終始してしまいがちです。開発者の場合、これは統合の問題につながります。人事チームでは、新しく導入した従業員給付を既存のシステムでは管理できないといった問題を引き起こす可能性があります。いずれにせよ、最適とはいえないソリューションを提供することになります。

パフォーマンスが高いチームは、プロジェクト開始時点で時間を割き、プロジェクトの成果物や、顧客と成果物との関わりについて視覚化していることがわかりました。それが、エンドツーエンドのデモです。こうしたチームはプロジェクト全体を通じてデモを繰り返し、フィードバックを得て、精度を高めていきます。

誰に参加してもらうべきか

この作業はプロジェクトのフルタイム所有者が、必要に応じてデモの作成に参加するプロジェクトのコアチームメンバーと一緒に行います。

定期的にデモセッションを開催する場合、エグゼクティブスポンサーが毎回参加する必要はありません。最初の 1、2 回と、プロジェクトを進めるうえで重要なマイルストーンとして行うデモのみに参加してもらうようにしてください。

このエンドツーエンドのデモプレイは、反復して行う従来のプロトタイピング手法のバリエーションです。
ユーザーのチーム
スタッフ

3 ~ 6 人

時計
所要時間

30 分

難易度: 中
難易度

プレイの実施

デモはプロジェクトによってさまざま形式を取ります (スケッチや図、実用プロトタイプ、新機能、新製品など)。重要なのは、プロジェクトを形にする過程でそれを繰り返すことです。

資料

用紙

ホワイトボード

マーカー

UI のモックアップ

ビデオ

 

ステップ 1

エンドツーエンドのデモを作成する

エンドツーエンドのデモは通常、頭の中に描いているソリューションの概要、ローテク、完成度の低いところから始まります。たとえば、テーブル上のナプキンに描いた図や UI 画面のスケッチなどです。既存の製品やサービスを扱う場合、デモが現在のエクスペリエンスのどの部分に当てはまるものかも反映している必要があります。

反復して行うプロトタイピングと同様に、プロジェクトが明確に定義されるにつれて、デモが完成に近づきます。ユーザーが、どのように製品、フィーチャー、サービスを見つけ、どのように利用し、どのように利用をやめるかを、すべて示すことが重要です。そうでなければ、エンドツーエンドにはなりません。

不適切なパターン

絶対にやめましょう。まずは断片的な情報、なによりも現実に即したものにしてください。すぐに作れて、会話が弾むものにしましょう。きれいに作り込む必要はありません。

ステップ 2

デモを見せる (30 分)

30 分時間を取り、コアプロジェクトチーム、関係者、エグゼクティブスポンサー (存在する場合) に参加してもらいます。前回のデモからの変更点に重点を置いてもかまいません。ただし、全員がカスタマージャーニー全体を把握し、プロジェクトが全体的なビジョンに沿って進んでいることを確認できるように、必ずジャーニー全体をエンドツーエンドで説明してください。

注目度の高いプロジェクトや長期的なプロジェクトを扱う場合は、このプレイと確信のデモプレイを併せて実行し、まだイメージの段階でリーダーシップチームからフィードバックを得ることを検討してください。

コンテンツ検索
サンプル

複数のクラウド製品の登録一元化に取り組んでいるチームは、早い段階で、エンドツーエンドのデモとしてこのマップを使用しました。

ステップ 3

デモを進化させる

問題点について詳しく分析し、チームからフィードバックを得て、顧客へのテスト (最も重要) を実施するにつれて、エンドツーエンドのデモは進化していきます。プロジェクト自体が進化しているからです。すばらしい! 大規模なプロジェクトや深刻な問題を扱うときは、併せてジャーニーマッピングプレイの実施も検討してください。

次に、実行モードに移ります。ワークフロー、ワイヤーフレーム、プロトタイプ作業中のコードのスニペットなどが該当します。このステップを省略できるのであれば、それもまたよしです。顧客が求めているのは、デモではなく、ニーズを満たす実用的なソリューションだからです。早速やってみましょう。重要なことは、できるだけ早く実行し、最終的に顧客に提供できるようになるまで反復することです。

成果の確認

チームでヘルスモニターセッションをすべて通しで、またはチェックポイントを実施して、改善しているかどうかを確認してみましょう。

その他のパターン

現状のデモ

そして、現状に問題がある理由も伝えます。画面操作を録画すると効果的です。フローを録画しながらコメントを加えることで、顧客の抱えている課題がリアルに伝わります。

例:「ユーザーは通常、Google 検索を使ってサイトを見つけ、ホームページにアクセスします。運がよければ、ユーザーがこのリンクを見つけます。リンクをクリックすると、このページが表示されます。このクイックリンク集で、求めている情報がここにあることに気付くかもしれません。ユーザーがクイックリンクを見つけたら、この画面が表示されます。ここをクリックすると、詳しい情報の入力を求められます。Enter をクリックします。しかしまだ完了していません。次に...」のようなビデオを作ります。

試験的なデモ

改善されたエクスペリエンスを反映したデモを作成します。短時間ですぐに実行できるよう、軽量にしてください。エクスペリエンスが改善されない場合、その試みは中止して、既存のソリューションを継続します。

フォローアップ

エンドツーエンドのデモを、複数回に分けて実施可能なイテレーションに分割し、各イテレーションが最終的な製品にどう貢献するのかを示します。

プレイブックがもっと必要ですか?

下のボックスにメールアドレスを入力すると新しいヘルスモニターやプレイが追加されたときに通知が送られます。

Thanks! Now get back to work.

フィードバックを受け取りましたか?

アトラシアンコミュニティサイトで質問やコメントをしてください。