クラウドを基盤としたプロジェクト管理システムを提供するLiquidPlanner社では、ユーザーが時間をかけずにダッシュボードを作成できるようにする必要がありました。
古いシステムでは、ウィジェットを含めたダッシュボードの作成をゼロから行うというものでした。顧客エンゲージメントとLTV（ライフタイムバリュー）の向上はダッシュボードの利用増加と比例しているため、プロダクトチームは新たなダッシュボードのテンプレート機能の開発に着手しました。
チームの目標は、ユーザーが設定しなくても便利なダッシュボードをすぐに作ることができる「ワンクリック・ソリューション」を開発することです。
新たなダッシュボードのテンプレート機能は４カ月間で完成し、その結果、特に重要な顧客層からの良い評価を得ることができました。機能はユーザーに広まり、プロジェクトは成功しました。
下の画像は、実際にチームが作成したダッシュボード画面です。
Credit: LiquidPlanner
以下では、実際にどのようにプロジェクトが進められたかを説明していきます。
サービスが利用される状況を設定する
制作に入る前に、ユーザーグループとプロジェクトの目標の検証が行われました。
１．最重要ユーザー層のペルソナ
LiquidPlannerは、３つの最重要なユーザーグループを設定しました。
- プロダクトマネージャー：LiquidPlannerを使ってくれる最も重要な人たちです。彼らは意思決定者であり、チームの時間管理や共同作業のために、LiquidPlannerの製品を採用しています。
- 機能に関するマネージャー：UXに関する責任者など意思決定にあたるもう一つの立場にあり、チーム内に影響力と責任をもつ人たちです。
- 最前線で働く人たち：製品を最も頻繁に使用する人たち。LiquidPlannerを自分達で選択する立場ではありませんが、日々の業務において製品を使用しています。
２．プロジェクトの目標
今回のプロジェクトの成功を測定するものとして、以下の量的・質的な目標が設定されました。
- リリースから30日以内での、ダッシュボードの利用増加。アプリ内で起きたことを追跡するために分析ツールHeapを利用し、ダッシュボード作成が難しいことによる弊害が製品全体にわたり見られることが分かりました。
- 業務に関する重大な情報へ即座にアクセスできるようにする。製品の質だけでなく、スピードも重要です。LiquidPlannerは、合理的かつ効率的にデータへアクセスできるようにすることが必要でした。
- プロジェクトを３カ月間で完了する。2016年１月にスタートし、ローンチは4月初めを予定していました。最適なソリューションを作成するのに、無駄のないタイムラインが必要とされました。
ステージ１：状況分析とコンセプトの決定
時期：2016年１月初旬
実際の開発をスタートする前に、プロダクトマネージメントを行うチームはブレインストーミングを行いました。エンジニアのリードマネージャーと、UXのマネージャー、そしてUXデザイナーのEdward Nguyen氏が出席をしました。
Heapからの分析結果を検証して、最も共通して作成されるダッシュボードを以下のように分類しました。
- 業務用ダッシュボード
- チーム用ダッシュボード
- ポートフォリオ用ダッシュボード
この分類をもとに、彼らはホワイトボードにアイディアを描き出しました。これらの図は、スクリーンごとにユーザーフローやユーザー体験を網羅的に表したものです。このユーザーフローが、ダッシュボードに関する問題点を完璧に解決するための基本的な考えとなりました。
ステージ２：初期フローの作成と実証
時期：2016年1月初旬
ホワイトボードのセッション後、Edward氏は直ちにイラストレーターを使って、ホワイトボードに描いたアイディアを描き出しました。これは初期バージョンとして作成され、ユーザーテスト用のプロトタイプが作成されるまで、内部の検証段階における重要なキーとなりました。
初期段階のフィードバックのために、Edward氏はこの中間段階のユーザーフローを、プロダクトチーム以外の５～10人程度の同僚に見てもらいました。彼はダッシュボード作成における現状の問題点を同僚に説明しカジュアルなテストを個別に行い、再デザイン案を作るためのフィードバックを集めました。
この検証は、協力者に内容を事前に伝えた上で行われたもので、Edward氏は彼の個人的な疑問点や関心事に関して明確な答えを得ることができました。
ステージ3：ハイファイなプロトタイピング
時期：2016年1月中旬～２月
初期ユーザーフローと中間フィードバックが完了した段階で、チームは実際に運用するバージョンのデザイン作成に取りかかりました。
１．作成
ワイヤーフレームとユーザーフローは製品のおおよその動きを表すものです。そして、プロトタイプは実際に製品がどのように動くかを示します。
プロトタイプを作成する目的は、決定したことを検証することです。最初のステップはユーザビリティテストのプランの中で、チェックした方が良いであろう事柄を書き出すことでした。このドキュメントは、最も重要なユーザーアクションを検証するテストのゴールに対して優先順位をつけるものとなります。
- ユーザーが新規ダッシュボードの作り方を理解していることを検証する。
- ３種類のデフォルトのテンプレート（業務用、チーム用、ポートフォリオ用）が効果的に活用できることを検証する。
- 作成されたダッシュボードが業務中に発見できることを検証する。
- どのデフォルトのウィジェットが、ダッシュボードのテンプレートの中で最も有用かを決定する。
ユーザビリティテストのプランには、ユーザーが行うタスクリストなども含まれました（例えば、「業務Aのための業務用テンプレートから、ダッシュボードを作成できましたか？」など）。
この段階で、どのウィジェットがどのテンプレートに含まれるのが良いかを分析し一覧にするために、データマイニングを行いしました。これにより、作成したプロトタイプは、最終的な製品により近いものとなりました。
ダッシュボードを作成するフローにおける最初の画面のプロトタイプ
実際のインタラクティブなプロトタイプを作成する段階では、UXPinを利用しました。Edward氏は、UXPinについて「機能性に富んでいる割にシンプルで、複雑なインタラクションのモデルを素早く作成・検証できます。月曜日にプロトタイプを作り終えて、火曜日と水曜日で検証を行い、木曜日には結果を表示することができます。」と述べています。
新しいデザインは、現在のユーザーを煩わせることなく直感的に使えるものである必要があったため、Edward氏は初期段階で描いていた複数のプロセスによるものではなく、画面の左側にタブが付いているフォーマットを採用しました。この方が、ユーザーの使い勝手が良くなるのに加えて、開発チームにとっても実装が簡単でした。
これによって、デザイナーは無駄にアイコンを作成する必要がなくなり、開発者も複数のステップによるウィザードを作る必要もなくました。またユーザーにとってもより少ない手順でダッシュボードの種類を選択することが可能でした。
Edward氏が実証した通り、デザイナーは実際のコードを知る必要がない一方で、デザインの導入に関する技術的なことについては、常に理解しておかねばなりません。
２．ユーザビリティテストと反復
チームはJoin.meを利用して、14人のユーザーに遠隔・承認制のユーザビリティテストを実施しました。
Edward氏が協力者に対してセッションを行い、他のチームメンバーがその観察・記録を行いました。彼らが主に検証したのは２つのシナリオ――ダッシュボードの作成と、プロジェクトの中から既に作成されているダッシュボードを見つけるというシナリオです。
テスト結果は即座に次のバージョンへ適用され、何度も検証とフィードバックの適用のプロセスが繰り返されました。これは、理想的なデザインが検証されるまで続きます。
ユーザーの信頼を得たハイファイなプロタイプは、既にしっかりと作りこまれたものだった。
ユーザビリティテストによって、デザインがうまく機能していることが明らかになりました。
- テンプレートからダッシュボードを作成する際に、ユーザーはタブを使ったレイアウトを使いやすいものだと認識している。
- ユーザーはデフォルトのテンプレートが使いやすく、ニーズに合うものだと言っている。
- ほとんどのユーザーがデフォルトのウィジェットを便利だと思っている一方で、違うウィジェットが良いと言うユーザーもいた。例えば、あるユーザーたちは「残りの仕事」という、折れ線グラフによるウィジェットは使いにくいと感じていた。またあるユーザーたちは、テンプレートに対してカスタムしたものを保存する機能がほしいと感じていた。
- ユーザーは、一度作成されたダッシュボードにアクセスするのに、やや手間取っていた。
Edward氏は得られたインサイトを固めるために、エンジニアのマネージャーと一緒にかなりの時間をかけてフィードバックをパターン分けして図に書き出しました。この作業は、ほかのユーザーにも当てはまり実用可能なフィードバックと、１回限り出てくるような例外的なフィードバックを分けるものでした。
新規で作成されたダッシュボードをより見つけやすくするために、Edward氏は画面の中にある「View Project Dashboard（業務用ダッシュボードを見る）」の文字の周りのホワイトスペースを増やすことにしました。
また、MVP（Minimum Viable Product、最低限の機能を持った製品）のスコープから抜けていた、ウィジェットの編集・保存機能など追加の改善はその後のテストに後回しすることになりました。
ステージ４：開発とユーザーの目の前での始動
時期：2016年２月～４月
アジャイルの手法に従って、デザインのスプリントが始まってすぐに開発スプリントも開始されました。
Edward氏のチームはまだプロトタイプを検証している段階でしたが、開発チームは実証された検証結果から順次プログラムを構築していました。「プロトタイプの作成と内容のテスティングが同時に行われていましたので、開発チームも問題なくデザインの決定案をコード化する作業に取り組めました。」とEdward氏は言います。
チーム内での意見交換を活発に行うことで、Edward氏が新たなユーザビリティテストの結果を開発チームに報告する日々のスタンドアップ・ミーティングもより効率的に行えました。
入念にテストを行ったことにより、LiquidPlannerはダッシュボードの新しいテンプレートを、ベータテストを行わずにユーザーにローンチできました。より大きな機能ではベータテストを行いますが、以前のダッシュボード作成がユーザーにとっては難しすぎたのでこの新しい機能をすぐに発表する必要があったのです。
効率的かつハイファイなプロトタイプとチーム一丸となった作業のおかげで、チームは予定通り、2016年４月９日に新しい製品を発表することができました。ローンチ後に最初に集計されたリアクションは、期待のもてるものでした。
- これまでに17,000個のダッシュボードがLiquidPlannerで作成され、その内10％にあたる1,700個がローンチから２週間以内に作られました。
- テンプレート機能は、アプリから作成された新規ダッシュボードの75％で利用されました。
- 大企業の大多数が、既に新しい機能をビジネスで有効活用しており、特に大規模で複雑な事業において利用されています。
「この数字は予想以上でした。」Edward氏は言いました。「自分が精力を注いだものが、ユーザーにこんなに利用されてるのを見るのは素晴らしかったです。」
今回の事例から学ぶべきこと
LiquidPlannerの成功から、私たち自身の製品をデザインするにあたり、以下の事柄を覚えておきましょう。
- 再デザインのプロジェクトでは、野心的すぎてはいけません。新しいデザインは、新たなユーザーにアピールする一方で、既存のユーザーも継続して利用できるものでなくてはいけません。この微妙なバランス感覚の中で作業するためにも、可能な限りを全てをシンプルにしましょう。
- 効率化という観点から、徹底的にテストをするには、スケッチの段階からユーザーフローとハイファイなプロトタイピングまでを、迅速に行うことが大事です。既存の製品がある場合、既にビジュアルデザインの基礎部分ができているため、ハイファイなプロトタイプの作成はよりリスクの少ない作業となります。
- 締め切りがタイトなスケジュールでは、デザイナーは開発者よりも工程をひとつ先に進んで仕事をしましょう。
- MVPのスコープを守りましょう。Edward氏が「ウェジェットの編集・保存」機能を付け加えたように、テストで得られた新しいアイディアをローンチ後まで保留することを恐れてはいけません。
- 綿密かつハイファイなプロトタイプとチーム連携を密にすることで、開発者が誤解することなくコーディングを行うことができます。
ケーススタディに基づく優れた実践法をより知りたい方は、Project Guide to Enterprise Product Designを無料でダウンロードして下さい。
