ユーザーペルソナの作り方｜UXデザインに生かす具体例

ユーザーペルソナは、ユーザー調査で見つかった行動の傾向をもとに作る、代表的な利用者像です。誰の目的、行動、制約を考えて製品を設計するのかを、チームで共有するために使います。名前、写真、経歴のリアルさよりも、設計上の判断を明確にできるかどうかに価値があります。

作成するときは、まず判断したいことを定め、対象となる利用者から根拠を集め、繰り返し見られる行動を比較します。その中から画面に影響する違いを整理しましょう。重要なニーズを画面、操作、検証課題に結び付けることで、ペルソナをUXデザインに生かせます。どのペルソナにもまったく同じ設計が適しているなら、まだ有用な違いを捉えられていない可能性があります。

ペルソナが表すもの

ペルソナは、インタビュー参加者一人の紹介でも、役職名でも、想像上の理想の顧客でもありません。複数の人に見られる意味のある傾向を、その傾向が重要になる状況とともにまとめたものです。同じ人でも、仕事中、移動中、不慣れな作業をしているときでは、行動が変わります。

NN/gのペルソナ解説（英語）では、調査にもとづいてユーザー群を表し、その特徴を覚えやすくするものと説明しています。詳細な架空の人生よりも、関連する目的、懸念、経験、状況のほうが重要です。個人的な情報を加えるのは、タスクの理解や、有用な違いを覚えることに役立つ場合に限ります。

仮定だけで作った人物像は、調査にもとづくものと区別します。十分な調査を行う前に、想定する利用者をまとめた仮説を「プロトペルソナ」と呼ぶことがあります。調査対象者の募集や質問の検討には役立ちますが、検証済みのユーザー群として扱ってはいけません。AIが作った経歴も、根拠で裏付けられるまでは仮説です。

空欄のテンプレートより、設計で決めたいことから始める

経費申請アプリを改善するチームを例にします。決めたいのは、領収書をどのように取り込み、不足情報を補い、承認へ回すかです。従業員全員の性格を描いたり、支出を予測したりすることが目的ではありません。

フォームの前後にある作業も調べます。いつ領収書を受け取るのか、その時点でどの情報が分かるのか、一件ずつすぐ申請するのか、後で数件をまとめるのか。分類が分からない場合や画像が読めない場合は、誰が解決するのでしょうか。こうした問いから、設計を変えるべき制約が見つかります。

職種のラベルだけでは、重要な違いが隠れることがあります。同じ「コンサルタント」でも、経費の申請方法は大きく違うかもしれません。逆に、営業職と現場のエンジニアが「今はスマートフォンで領収書だけ記録し、詳細は後で入力したい」というニーズを共有することもあります。人物像の名前を決める前に、行動を見ます。

「典型的な利用者」を想像せず、根拠を集めて比較する

最近の申請についてのインタビュー、現在の作業の観察、関連するサポートへの問い合わせ、適切に収集した製品データなどを使います。欲しい機能を想像してもらうのではなく、実際にあった出来事を説明してもらいましょう。「シンプルなアプリが好き」という抽象的な好みより、提出に手間取った領収書の話のほうが、具体的な課題を示すことがあります。

比較用の小さな表を作ります。行には参加者や調査セッション、列には申請頻度、記録する状況、不足情報、他者との調整、失敗からの復帰など、意味のある観点を置きます。観察したことには、個人を特定しない出典を添えます。答えが得られなかった問いは未確認のままにし、印象的な一人の話を全員に当てはめません。

次に、複数の観点を横断して傾向を比較します。申請頻度だけでなく、領収書を後から取り出せるか、同僚との調整が必要かも重要かもしれません。一つの変数から自動的に一人のペルソナを作らず、UXリサーチの情報を統合する手順で、観察、解釈、反対の事例のつながりを保ちます。

経費申請アプリのペルソナ例

以下は、行動を設計へ結び付ける方法を説明するための仮の例です。Pixsoの顧客を調査した結果や、経費申請サービスで測定したユーザー区分ではありません。

この二つを説明するために、架空の年齢、年収、好きなブランド、性格スコアは必要ありません。そうした情報を並べても、フォームをなぜ変えるべきかは明らかにならないからです。短い説明的な名前があれば、違いをチームで話し合えます。

違いがあるからといって、アプリを二つ作る必要もありません。どちらにも正しい合計額と、申請結果の明確な表示が必要です。共通の記録手順に、不慣れな作業向けの案内と、中断しても再開できる下書きを組み合わせられます。ペルソナは、どこに柔軟性が必要かを考える助けになります。

人物像を具体的な画面の判断につなげる

たまに申請する人には、アップロード欄のそばで領収書の必要条件を示すこと、経費分類を短く説明すること、確認者が必要とする情報の例を示すことなどを検討します。一枚の領収書を提出する前に、長い初回ツアーを必ず見せる方法で不慣れさを解消しようとしないことが大切です。

出張が多い人には、「下書きに保存済み」と「承認依頼を送信済み」を明確に分けます。不足している情報を示し、その項目へ戻る経路を用意します。領収書のアップロードが成功しただけで、下書きが提出済みに見えてはいけません。

どちらの人にも、最後の操作によって何が起きたかを示します。確認画面では対象の申請を特定し、承認状況をどこで確認できるか説明できます。領収書のアップロードに失敗したら、入力した情報を保持して再試行できるようにします。違いを示すことに集中するあまり、共通する要件を落としてはいけません。

改善案の横には、判断の理由を書きます。たとえば「この利用状況では記録の中断が起きるため、未完成の項目を残し、簡単に再開できるようにする」と記します。この形なら、レビュー時に根拠が妥当か、提案した対応が適切かをそれぞれ検討できます。

Pixsoで設計に使えるペルソナボードを作る

Pixsoホワイトボードのキャンバスに、各ペルソナの目的、状況、行動、制約、設計への示唆を簡潔にまとめます。調査の参照先は、装飾的な経歴欄の中に埋めず、近くに置きます。参加者の機密情報は、適切にアクセスが制限された調査記録に保管します。

二つの人物像を横に並べ、違いを比較できるようにします。その下に、提案する画面やデザインへのリンクを置きます。たまに申請する人には証憑の案内、出張が多い人には記録と再開の状態を対応させます。コメントでは、画面がそのニーズを本当に扱えているかを話し合います。

共有キャンバスは比較を整理するのに役立ちますが、ユーザーの分け方が正しいと証明したり、調査の分析を代わりに行ったりするものではありません。根拠が変わったら、人物像と関連する設計判断を一緒に更新します。

実際に使って、ペルソナの有用性を確かめる

参加者は、架空の人物の名前や経歴との一致ではなく、関連する行動と制約から募集します。申請頻度が低い人には、不慣れな経費を申請し、必要な証憑を説明してもらいます。移動中に経費を記録する人には、未完成の項目を保存して一度離れ、後で再開してもらいます。提案した画面でどのように行動するかを観察しましょう。

結果は、検証したタスクと結び付けて扱います。下書きから再開できたという結果は、その操作の有効性を支えますが、ペルソナ全体が正しいことを証明するものではありません。状況によって同じ人が二つの行動を行き来するなら、固定的なユーザー分類より、状況別のシナリオを使うほうが適切かもしれません。

人物像から抜け落ちている人も確認します。他の人に代わって提出するアシスタント、支援技術を使う人、意見の食い違う申請を確認する担当者などには、この二つの例で表せない要件があるかもしれません。発表資料を網羅的に見せるためではなく、設計判断が変わるときに人物像やシナリオを追加します。

根拠と設計のつながりを保って更新する

各ペルソナには、調査期間、対象範囲、管理担当者を記録します。製品が変わったとき、対象者が広がったとき、中心的な行動と矛盾する新しい根拠が得られたときに見直します。判断に役立たなくなった人物像は使うのをやめます。見慣れたポスターだからといって、古い仮定を残す理由にはなりません。

経費申請アプリの例で導くのは、「再開できる下書きを明確に残し、入力の場面で必要な証憑を理解できるようにする」という設計判断です。その理由を説明し、次に何を確かめるかを決める助けになってこそ、ペルソナを作る意味があります。