「誰でも使える」設計が招く失敗パターン
Web制作や新サービスの立ち上げ時に「幅広い層に使ってほしい」「誰でも使えるものにしたい」という方針が打ち出されることがある。この言葉自体に悪意はない。しかし設計の観点からは、ターゲットユーザーを無定形にする最も危険な表現の一つである。
あるBtoB向けのポータルサイト構築プロジェクトでは、クライアントが「経営者から現場担当者まで全員に使いやすく」という要件を設定した。結果、トップページには経営者向けの高次の意思決定情報と、現場担当者が日次で参照する運用マニュアルが同居することになった。経営者にとっては細かすぎるページ、現場担当者にとっては抽象的すぎるページが混在し、どちらのユーザーにも「使いにくい」と評価された。
別のケースでは、地域コミュニティ向けのアプリを開発するプロジェクトで「20代から60代まで幅広く使える設計に」という方針が取られた。20代が直感的に操作できる最小限のUI設計を採用すると60代が使いにくくなり、60代のアクセシビリティを優先すると20代に「古くさい」と敬遠された。機能追加のたびに「誰向けの機能か」で議論が発散し、リリースが6ヶ月遅延した。
これらの問題に共通する構造は「制作の判断基準となるユーザー像が存在しないこと」である。デザインの選択、機能の優先順位付け、コンテンツの粒度、ナビゲーション設計のいずれも、最終的に「誰かが主観で決める」状態に陥る。その結果、決定が属人化し、後から参加したメンバーが判断根拠を理解できず、方向転換のたびに大きな手戻りが生じる。
ペルソナ設計はこの構造問題を解消するための手法である。「誰のために作るのか」を特定の一人として定義することで、制作に関わる全員が同じ基準で判断できる状態を作り出す。
ペルソナ設計とは何か：定義と役割
ペルソナとは、ターゲットユーザーを代表する架空の人物像である。名前、年齢、職業、行動パターン、価値観、情報収集習慣、課題などを具体的に記述した「特定の一人」の像として定義される。
「30代会社員」という記述はペルソナではない。「田中麻衣、32歳、東京都品川区在住、中規模IT企業のプロジェクトマネージャー。毎朝通勤電車の中でスマートフォンでニュースとSlackの確認を済ませる。業務上の学習意欲は高いが、まとまった時間が取れないため、5〜10分で読めるコンテンツを好む。同僚の推薦を意思決定の重要な参考情報としている」という記述が、実務で機能するペルソナに近い。
ペルソナの本質的な目的は「判断基準の共有」にある。デザインを選択するとき、「一般ユーザーにとってどちらが良いか」ではなく「田中さんにとってどちらが使いやすいか」という問いに変換することで、議論が具体的になる。機能の優先順位を付けるとき、「ユーザーが必要な機能」という曖昧な基準ではなく「田中さんが通勤中に5分で完了できるか」という検証可能な基準で判断できる。
ここで注意が必要なのは、ペルソナをマーケティングのセグメントやユーザー属性の統計と混同しないことだ。「30〜40代、年収500万円以上、都市部在住」というセグメント定義は、広告出稿のターゲティングには有効だが、UXや設計判断の基準としては抽象度が高すぎる。ペルソナは統計的代表性より「制作チームが具体的にイメージできる特定の人」としての鮮明さを優先する。
また、ペルソナは「作って完成」のドキュメントではない。制作の各フェーズで参照され、更新され、チームメンバー間の対話の起点として機能して初めて価値を持つ。
実務で機能するペルソナの作り方
ペルソナを「壁の飾り」にしないためには、調査データに基づいて作ることが最低条件である。仮説のみで作成したペルソナは制作者の思い込みを強化するだけで、ユーザーの実態から乖離するリスクが高い。ただし、大規模なリサーチ予算が常に確保できるわけではない。ここでは最小限のリサーチで有効なペルソナを作るための手順を示す。
ステップ1：既存データの収集と分析
まず手元にあるデータを整理する。アクセス解析ツールのユーザー属性データ、問い合わせフォームへの記入内容、既存顧客へのアンケート結果、サポート窓口への相談内容などが活用できる。これらを「誰が・何を求めて・どんな状態で接触してきたか」という観点で読み直す。
既存データが全くない新規プロジェクトの場合は、類似サービスのレビューサイト（App Store評価、GoogleマップのレビューなどTargetユーザー設定に参考になる一次データが含まれる）や、SNSでの関連ハッシュタグ・コミュニティの発言を収集する。
ステップ2：ユーザーインタビューの実施（最低3名）
可能であれば実際のユーザーや潜在ユーザーに対して30〜60分程度のインタビューを行う。最低3名から共通パターンが抽出できる。インタビューで重点的に確認すべき項目は次の通りだ。
- 対象の問題・課題をどのタイミングで認識するか
- 解決策を探すとき、どのような情報源を参照するか
- 判断・意思決定のプロセスで誰が関わるか（特にBtoB）
- 現在の解決方法に不満を感じているポイント
- 製品・サービスを選ぶときの決め手となる要素
ステップ3：ペルソナの必須フィールドを定義する
インタビューと既存データをもとに、以下のフィールドを埋めてペルソナを作成する。
| フィールド | 目的 | |-----------|------| | 氏名・年齢・居住地・職業 | チームがリアルに想像できる具体性を持たせる | | 1日の行動パターン | コンテキストに応じた設計判断の根拠にする | | 情報収集の習慣・利用デバイス | チャネル設計とUI優先度の根拠にする | | 主要な課題・不満 | 機能優先度と価値訴求の根拠にする | | 意思決定の影響要因 | コンテンツ設計と導線設計の根拠にする | | 目標・達成したいこと | 設計全体の方向性の基準にする |
フィールドを細かく設定しすぎると管理コストが増し、更新が停滞する。必須フィールドに絞り、A4一枚に収まる密度にすることが運用継続の条件である。
ステップ4：仮説を明示してレビューサイクルを設定する
調査データが不十分な部分は仮説として明示する。「通勤時間にスマートフォンで閲覧する」という記述が実データに基づく場合と、仮説の場合では判断の重みが異なる。仮説部分をラベリングし、プロジェクト進行中のユーザーテストや追加インタビューで検証・更新するサイクルを設定しておく。
ペルソナが「壁の飾り」になる典型的な失敗
ペルソナを作成することで「ユーザー視点に立った設計をしている」という安心感が生まれやすい。しかしペルソナが実際の意思決定に機能していないプロジェクトは多い。「壁の飾り」になるパターンには典型例がある。
失敗パターン1：キックオフ時に一度作って以後参照されない
プロジェクト開始時にワークショップでペルソナを作成したが、その後の制作会議でペルソナが参照されることはなかった、というケースは頻繁に起きる。ペルソナが意思決定の文脈から切り離されると、単なる手続き上の成果物になる。
対策として、デザインレビュー・仕様確認・コンテンツ選定の場で「これはペルソナの○○さんにとってどうか」という問いを発することをチームのプロトコルとして設定する。
失敗パターン2：全員が合意できる「平均的なユーザー」に収束する
チームでペルソナをワークショップ形式で作成すると、意見の相違を避けるために「誰も否定できない属性の塊」になりやすい。その結果、実在感のない中間的なペルソナが生まれ、設計判断の基準として機能しない。
良いペルソナは具体的であるがゆえに「このプロジェクトには合わない」と反論が出るものである。反論が一切出ないペルソナは抽象度が高すぎる可能性が高い。
失敗パターン3：ステークホルダーの「自分像」が投影される
発注者側の責任者が「私がユーザーの典型だ」という前提でペルソナに自分の価値観や行動パターンを投影するケースがある。特に創業者や経営者は製品・サービスへの思い入れが強いため、実際のターゲットユーザー設定と乖離した像を「正しいペルソナ」として主張することがある。
ユーザーインタビューのデータを示して合意形成するか、「私たちはユーザーではない」という原則をプロジェクト開始時に明示的に宣言することが有効だ。
失敗パターン4：ペルソナが承認文書になる
ペルソナの記述が詳細になるほど、承認に時間がかかり、一度承認されると更新が困難になるケースがある。ペルソナは制作判断の道具であり、承認を得て固定するドキュメントではない。「仮説の明示」と「定期更新」を前提とした軽量な運用設計が重要だ。
複数ペルソナの選定とプロジェクトへの組み込み方
多くのプロジェクトでは、調査を行うと複数のユーザー像が浮かび上がる。「全部のペルソナに対応しなければ」という発想が、再び「誰でも使える設計」の罠に引き込む。複数ペルソナが生まれた場合の対処法を示す。
プライマリペルソナの選定
まず一人のプライマリペルソナを選定する。選定基準は「このプロジェクトで最も価値を届けたいユーザー」である。売上規模・契約数・利用頻度などのビジネス指標と、「この人が満足する設計がプロダクト全体の品質を担保する」という設計難易度の両面から判断する。
プライマリペルソナに向けて最適化された設計が、他のユーザーにとっても概ね受け入れられる状態を目指す。
セカンダリペルソナの扱い
プライマリペルソナの次に重要なユーザー像をセカンダリペルソナとして定義する。セカンダリは「プライマリのための設計を壊さない範囲で配慮する」という位置づけであり、同等の優先度で扱わない。
例えば、プライマリが「30代のスマートフォン中心ユーザー」の場合、セカンダリとして「60代のデスクトップ利用者」を設定するなら、スマートフォンの操作性を犠牲にしない範囲で文字サイズや色のコントラスト比を調整する、という判断になる。
ペルソナの制作フェーズへの組み込み
ペルソナが有効に機能するには、制作の各フェーズで具体的な参照場面を設計する必要がある。
- 情報設計フェーズ: サイトマップやナビゲーション構造の選択肢を並べたとき、「田中さんが初めてアクセスして3クリック以内に目的の情報に到達できるか」を評価基準として使う
- ビジュアルデザインフェーズ: 配色・フォント・余白の選択肢を提示するとき、ペルソナの利用コンテキスト（移動中・明るい環境か暗い環境か、視認性への感度）を判断根拠として使う
- コンテンツ制作フェーズ: 見出しの表現や本文の長さ・粒度を選択するとき、「田中さんは5分で読めるか、この表現で伝わるか」を基準として使う
- ユーザーテストフェーズ: 可能な限りペルソナに近い属性のユーザーを招集し、「ペルソナが直面する課題を解決できているか」を検証軸として使う
ペルソナは「誰のために作るのか」という問いへの答えを、プロジェクト全体を通じて維持するための装置である。作成すること自体が目的ではなく、制作の判断基準として機能し続けることが目的だ。その認識を制作チーム全員が持ち、意思決定の場で繰り返し参照する習慣を作ること — それがペルソナ設計の本質的な価値を引き出す唯一の方法である。
参考文献
About Face 4: The Essentials of Interaction Design (2014)
Personas: Study Guide (2024)
Persona Types: Lightweight, Qualitative, and Statistical (2022)