1.ペルソナの設定
なぜ重要か
製品を使ってくれる顧客の具体的なイメージを共有するためにペルソナという仮想の人格を定義するという手法があります。 ペルソナを用いることでチームの議論が活発になり、エンジニアやデザイナーの事業理解も進みやすくなり、より高速な開発や価値のある開発が可能になります。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-1-1 | メトリクスの計測 | 少なくとも1つの大きな事業仮説に対して、対応する1つ以上のペルソナが作成されているか。 |
DESIGN-1-2 | 学習と改善 | 事業、製品のペルソナについて、データや仮説検証で学習したことを受けて定期的に見直しているか。 |
DESIGN-1-3 | プラクティス | ペルソナを記述した資料は、施策会議のたびに意識され、参照されているか。 |
DESIGN-1-4 | プラクティス | ペルソナについて、チームで繰り返し議論されイメージの共有化をしているか。 |
DESIGN-1-5 | プラクティス | B2Bなど顧客における関係者が複数人いる場合、購買プロセスの各担当者など、意思決定に関わる人物の数だけ必要なペルソナを作っているか。 |
DESIGN-1-6 | アンチパターン | ペルソナの具体的なライフストーリーが欠如しており、仮説構築につながらない。 |
DESIGN-1-7 | アンチパターン | 過剰に属性情報が肉付けされていて、チームのメンバーが同じユーザー像を想像しづらいペルソナになっている。 |
DESIGN-1-8 | アンチパターン | ユーザーインタビュー/ユーザー調査なしに勝手なイメージでペルソナを作っている。 |
2.顧客体験
なぜ重要か
顧客からの問い合わせに対する効率的なマネジメントは、サブスクリプションや継続率を重視するサービス型の事業にとっては短期の売上以上に経営インパクトのある指標です。 そのため、顧客の行動履歴から重要なインサイトの発見や満足度の向上にどれだけ投資できているかはデジタル化のインジケータになります。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-2-1 | メトリクスの計測 | 顧客に対してNPS(ネットプロモータースコア)や満足度を継続的に測定しているか。 |
DESIGN-2-2 | 学習と改善 | 顧客による問い合わせから返信までのリードタイム、問い合わせおよび回答への満足度について定量計測を行い、目標管理をしているか。 |
DESIGN-2-3 | プラクティス | 構造化されたヘルプページがあり、ヘルプに書かれた内容を改善するために顧客がフィードバックできるか。 |
DESIGN-2-4 | プラクティス | CRM(顧客管理システム)、SFA(営業支援システム)を導入しており、お問い合わせや行動履歴を把握できているか。 |
DESIGN-2-5 | プラクティス | 顧客が価値を感じるまでの感情的な動きやチャネルを分析したカスタマージャーニーマップを作成しているか。 |
DESIGN-2-6 | アンチパターン | カスタマーサポートなど顧客接点となるスタッフから、課題の吸い上げができていない。 |
DESIGN-2-7 | アンチパターン | 電話やメールでの対応に対して、柔軟な対応をしすぎてしまい自動化の阻害要因になっている。 |
DESIGN-2-8 | アンチパターン | 顧客体験の向上のための担当エンジニアリングチームが存在せず、システム化や自動化による改善ができていない。 |
3.ユーザーインタビュー
なぜ重要か
顧客の隠れたニーズや、課題の感覚を拾い上げて数字になかなか現れない事業仮説を構築するというのは、とても難しい創造的な工程です。 それを補助するためには、専門的な知見と実際のインタビュー接点を持ち続けることは必要不可欠な事業ケイパビリティになります。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-3-1 | メトリクスの計測 | ユーザーインタビューによって見つけた課題に対してどの機能がリリースされているのかが記録されており、その効果も測定されている。 |
DESIGN-3-2 | 学習と改善 | 直近、半年以内になんらかのユーザーインタビューを行っているか。 |
DESIGN-3-3 | プラクティス | ユーザーインタビューの実施のための稟議やフローは軽量で、一ヶ月以内に行うことができるか。 |
DESIGN-3-4 | プラクティス | インタビュー結果のインサイトをまとめて、共感マップなどを作成しているか。 |
DESIGN-3-5 | プラクティス | インタビュー参加者が話しやすい雰囲気作りのための工夫がインタビュースクリプトに組み込まれている。 |
DESIGN-3-6 | アンチパターン | ユーザーインタビューに関して訓練を受けていないスタッフが実施しており、仮説に対して誘導的すぎたり、クローズドクエッションが多くなったりしている。 |
DESIGN-3-7 | アンチパターン | インタビュー結果が具体的な次の一手(異なる仮説の構築や、具体的な機能反映)につながらずに実施したまま放置されている。 |
DESIGN-3-8 | アンチパターン | 仮説をもたずにインタビューを設計しており、インタビューイの要望をそのまま拾い上げたり、サンプルの少ないインタビュー結果をそのままセグメント全体問題としてとらえてしまっている。 |
4.デザインシステムの管理
なぜ、重要か。
UIデザイナーとフロントエンドエンジニアの連携の良さは高速なアプリケーション開発にとって重要な要素です。 また、フロントエンドエンジニアとバックエンドエンジニアの連携のしやすさも課題になります。このようにデザインの反映も自動化していくというサイクルが質を生み出していきます。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-4-1 | メトリクスの計測 | デザインシステムを用いて、デザイナーの介在なしにフロントエンド開発の5割以上が達成できている。 |
DESIGN-4-2 | 学習と改善 | 利用頻度の高いコンポーネント等をまとめたデザインシステムを構築し、継続的に棚卸するなど陳腐化することなく改善できているか。 |
DESIGN-4-3 | プラクティス | プロダクトに関わるUIパーツは、動作するライブラリとしてまとめられているか。 |
DESIGN-4-4 | プラクティス | UIデザイナーが作成したデザインをソースコードに自動的に反映するためにツールを利用しているか。 |
DESIGN-4-5 | プラクティス | プロダクトに関わるUIパーツには、OOUIなどの抽象的な情報設計に基づいた共通のポリシーがあり、それらがドキュメント化されているか。 |
DESIGN-4-6 | アンチパターン | フロントエンド開発とバックエンドが密結合しており、APIモックサーバーなどを用いて、バックエンド開発と並行して開発をすすめることができない。 |
DESIGN-4-7 | アンチパターン | 各プラットフォーム(iOS/Android/Web)などで過度に統一の体験を設計しようとしすぎてしまい、それぞれの流儀にそぐわないUIとなってしまっている。 |
DESIGN-4-8 | アンチパターン | 各画面やパーツごとに組み込まれた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素がガイドラインに組み込まれていない。 |
5.デザイン組織
なぜ、重要か。
デザイナーは、開発者と同じように希少な人員になるため、プロジェクトやサービスの専任ではなく兼務や時間的・心情的なコミットメントが成約されやすい職種です。 一部の工程だけではなく、全体の工程に溶け合いながら関わることで相互理解がうまれ、デザインの専門性を事業に反映しやすくなります。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-5-1 | メトリクスの計測 | 事業に必要なUI/UXデザインの過半数を内製化できているか。 |
DESIGN-5-2 | 学習と改善 | デザイン組織のリーダーは、自社戦略に必要なデザイナーの人事戦略を自ら立案しており、採用・育成についての権限と責任を負っているか。 |
DESIGN-5-3 | プラクティス | 全社のクリエイティブや顧客体験デザインを担う専門知識を持った経営幹部がいるか。 |
DESIGN-5-4 | プラクティス | 内製のデザイン組織を持ち、ガイドラインなどを用いて、内製化すべきことと外部の専門家集団を活用することを明確にしているか。 |
DESIGN-5-5 | プラクティス | 事業責任者は顧客体験やデザイン思考のトレーニングを受けているか。 |
DESIGN-5-6 | アンチパターン | デザイナーがプロジェクトを横断して派遣され、兼務が多くなったり関わる期間が短くなるため、各プロダクトにおけるユーザーへの共感や事業価値の理解が弱くなっている。 |
DESIGN-5-7 | アンチパターン | 個別のプロダクトや事業チームごとに専任で配置されるのみとなっており、デザイナーとしてのキャリアやスキル向上のサポートが乏しい。 |
DESIGN-5-8 | アンチパターン | デザイナーがプロジェクトの意思決定に関われなかったり、デザイナーに情報を伝えるのが遅いため、カスタマージャーニー全体に対する価値が発揮しづらくなっている。 |
6.プロトタイピング
なぜ、重要か。
マーケットの不確実性の高い現在では、サービスや製品を完成させてから評価する手法は不向きです。 一度、中核価値の部分だけを雑に作成し、それを評価し直して、再度完成品を作り直すというサイクルが重要になります。 失敗をできるかぎり早めるためにどのような投資をしているかをチェックします。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-6-1 | メトリクスの計測 | 少なくとも四半期に1回以上の戦略仮説に向けたサービスプロトタイプを作成しているか。 |
DESIGN-6-2 | 学習と改善 | 一年に一度以上の頻度で経営幹部も参加するプロトタイプづくりのワークショップを行っているか。 |
DESIGN-6-3 | プラクティス | ある課題の発散のフェーズでは、プロトタイプは極端な仮説に基づいて複数個つくられているか。 |
DESIGN-6-4 | プラクティス | デザイナーやプロダクトオーナーはプロトタイピング専用ツールを使うことができるか。 |
DESIGN-6-5 | プラクティス | 作ったプロトタイプは、一度破棄してから製品用の設計を行っているか。 |
DESIGN-6-6 | アンチパターン | プロトタイプを作るために、プレゼンや大きな稟議が必要になり、プロトタイピングの前に頓挫することが多い。 |
DESIGN-6-7 | アンチパターン | MVPを特定せずに、プロトタイピングに製品版の完成度を求めてしまう。(プロトタイプはどれだけ雑に仮説検証が達成できるかが重要である。) |
DESIGN-6-8 | アンチパターン | 一度のプロトタイピングで、中止や製品化を判断してしまう。 |
7.ユーザビリティテスト
なぜ、重要か。
顧客の使い勝手の評価を、数値的に裏付けを持って改善することで、思い込みをもってしまいやすいデザインの分野においても数値による評価を行うことができます。 ユーザー調査と異なり、ニーズの検証ではなく。ある程度動作する製品やプロトタイプに対しての使いやすさ・使いごこちを評価していきます。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-7-1 | メトリクスの計測 | ユーザビリティパフォーマンステストを行い、タスク達成率などを継続的または周期的にトラッキングしているか。 |
DESIGN-7-2 | 学習と改善 | 新規・既存顧客について継続的にユーザビリティの変化がないか示すメトリクス(タスクの成功率など)を計測し、それをもとに改善を行っているか。 |
DESIGN-7-3 | プラクティス | 重要機能のタスク成功率/タスク実施時間/学習効率などを計測しているか。 |
DESIGN-7-4 | プラクティス | 実際のリリース後も入力エラーやタスク時間などを計測しているか。 |
DESIGN-7-5 | プラクティス | 自己申告メトリクスなどを用いて、印象を含めた満足度のテストをおこなっているか。 |
DESIGN-7-6 | アンチパターン | ユーザー調査(何が課題かの発見)とユーザビリティテスト(使い心地が良いか、どのような印象を抱いたか)を区別せず同時に行ってしまう。 |
DESIGN-7-7 | アンチパターン | 事業KPIとの関連の薄い些細な項目ばかりに時間を使ってしまう。 |
DESIGN-7-8 | アンチパターン | 3名以下の少なすぎるユーザビリティテスト対象者の結果に振り回されてしまう。 |
8.プロダクトマネジメント
なぜ、重要か。
プロダクトマネージャという役職は、プロジェクトマネージャとは異なり、継続的に顧客と繋がり続けるようなサービスのビジョン、仕様決定、マーケティングまでを行うような専門職です。 事業に応じて、多様な専門性と直感が必要になるため、育成の支援とフォローしあえる体制構築が鍵となります。
Name | PointOfView | Criterion |
---|---|---|
DESIGN-8-1 | メトリクスの計測 | 権限を持ったプロダクトマネージャという役職が存在し、1サービスに専任の1名以上が任命されているか。 |
DESIGN-8-2 | 学習と改善 | 幹部人材に対して、プロダクトマネジメントのスキルについての継続的な学習機会を提供できているか。 |
DESIGN-8-3 | プラクティス | プロダクトへの要求をユーザーストーリーなど開発チームと合意したバックログアイテムの単位で明文化し、その優先順位をつけることができているか。 |
DESIGN-8-4 | プラクティス | 事業フェーズに応じて、プロダクトマーケティングや詳細な要求分析、UX評価など適切な分業体制を引くことができているか。 |
DESIGN-8-5 | プラクティス | プロダクトの仮説をバリュープロポジションキャンバスや、仮説キャンバスなどで明文化した上で機能定義を行っているか。 |
DESIGN-8-6 | アンチパターン | プロダクトマネージャがソフトウェアプロダクト開発やデザインに関する知見や関心が薄く、チームの関係性が悪化している。 |
DESIGN-8-7 | アンチパターン | プロダクトマネージャとビジネスプロセスやマーケット部門との関係性が薄く、それ起因の実運用によるトラブルが、ほぼ毎回発生している。 |
DESIGN-8-8 | アンチパターン | プロダクトマネージャという役割に予算執行の権限と責任がない。 |