実践的なユーザビリティ

ペルソナの力

Dr. Charles B. Kreitzberg および Ambrose Little

目次

認知的視点
ペルソナの作成方法
ペルソナが役に立つ理由
ペルソナがサポートする推測の種類
ペルソナの数
ペルソナと画面の結合
ペルソナに含める情報
ソフトウェア的視点
感情移入
機能とその優先順位の明確化
実現方法の明確化
コミュニケーション
ペルソナのショートカット
まとめ

認知的視点

Dr. Charles B. Kreitzberg

UI を設計するなら、ペルソナを作成して設計の指針にすることをぜひ検討してください。ペルソナは、ユーザー エクスペリエンス (UX) 設計のための基本的なツールの 1 つです。ペルソナとは、開発中のソフトウェアのユーザー セグメントを代表する架空の人物についての記述です。もちろん、人物は架空であっても、その記述は架空ではありません。記述はできる限り現実に基づいていなければなりません。

図 1 に、金融機関向けに作成された簡単なペルソナの例を示します。Bill (と彼の妻 Sue) は、ある銀行が顧客に対して行ったインタビューに基づいて作成した架空の人物です。インタビューとその他の調査結果から、その銀行の顧客を、目標、関心事、およびインターネットの利用習慣ごとに分類すると、多数の対象セグメントに分かれることが判明しました。特定のセグメントを代表するペルソナを作成すれば、設計上の質問を策定し、それに答えるのが簡単になります。

ペルソナは、この例に示したものより、ずっと長く詳細なものになることもあります。以下に、同じプロジェクト向けに作成した長いペルソナの例を示します。[Mark Singer の pdf へのリンクを挿入]

ペルソナを作成することは厳密な科学的手法ではなく、ペルソナが実際にどの程度ユーザーを反映しているのか確認することも困難です。ペルソナは架空の行為によって作成されるため、その価値を根本的に疑問視する人もいます。こうした批判は、ペルソナはデータから作られるが、データはその性質上完全ではないため、ペルソナも完全なものにはなり得ないという事実を忘れないようにするという意味では価値があります。しかし、そうした点を認めたとしても、ペルソナはきわめて有用です。ペルソナの主な利点は次のとおりです。

• 設計者が対象セグメントにおけるニーズと要望を推測できる
• ユーザーの特徴を簡潔かつわかりやすい方法で伝えることができる
• 利害関係者が自分の利益のために対象セグメントの定義を変えてしまうのを防ぐことができる
• UI 設計の対象ユーザーに顔を付けることができる

図 1 簡単なペルソナ

ペルソナの作成方法

大半のデザイン要素と同様、ペルソナも反復作業によって作成できます。また、大半のデザイン要素と同様、ペルソナを共同で開発することにも利点があります。関係者やチームの他のメンバが参加することによって、ペルソナの正確さが向上し、ユーザーに対して一定の認識が生まれ、結果としてチームのユーザーに対する認識が統一されます。チーム メンバは、ペルソナに慣れるにしたがって、実在のユーザーであるかのようにペルソナについて話すようになります。こうした状態になると、開発者にとって価値のある視点が得られるようになります。

ペルソナは簡単なものでも十分に役に立ちます。筆者は通常、営業担当者や顧客サービス担当者など、対象ユーザーをよく知っている人たちとの会話に基づいてペルソナの簡単な概要を作成することから始めます。このようなペルソナは、実際のデータに基づいていないため "推測によるペルソナ" と呼ばれます。

場合によっては、時間やリソースが制限されているため、このようなペルソナしか作成できないこともありますが、より良い方法は、ユーザーにインタビューし、収集したデータを使用してペルソナを検証したり改善したりする方法です。ときには、組織が、さまざまな民族学的な調査手法を駆使して、データ収集と分析を徹底的に実行し、高度に洗練されたペルソナを作成する場合もあります。

徹底した調査に基づいてペルソナを作成する方法もすばらしいのですが、推測による簡単なペルソナをいくつか組み合わせただけでも、有用な設計ツールになります。

ペルソナとその構造について理解するための優れた書籍として、John Pruitt と Tamara Adlin の共著『The Persona Lifecycle: Keeping People in Mind Throughout Product Design』(Morgan Kaufmann、2006 年) があります。

ペルソナが役に立つ理由

ペルソナでは、人間が持つ基本的な能力、つまり、他人がどのように反応するかをその人のメンタル モデルに基づいて推測する能力をうまく利用しています。親しい友人や家族が特定の出来事に対してどのように反応するかを正確に推測し、その推測に基づいて行動を決定することはよくあります。

親しい友人や家族については、メンタル モデルを豊富かつ (通常は) 正確なものにするさまざまな過去の経験があります。しかし、人間は、比較的少量のデータからでも他の人を推測できるのです。たとえば、だれかが歩くときの態度や姿勢を見ただけで、通りを横断する気になることがあります。

もちろん、ある状況での人の行動についての仮定は間違っていることがありますし、推測を誤ることもよくあります。それでも、他の人の行動を正しく推測する能力は生きていく上で必要不可欠であり、人は事実認識に基づいて、それができる十分な資質を備えています。ペルソナが強力なツールとなるのは、そうした人の持つ能力のおかげです。対象ユーザーのモデルを作成することによって、自分の選択した設計に対するユーザーの反応を推測することができます。

ペルソナがサポートする推測の種類

ペルソナを使用すると、さまざまな点で設計プロセスが容易になります。ペルソナでできることは次のとおりです。

• 複数の選択肢の中から、対象ユーザーが選択する可能性が最も高いものを推測する
• ユーザーのニーズとあった方がよい機能を区別することで、検討中の機能の優先度を設定する
• ユーザーの注意を引くものを確認する
• ユーザーの気分を害したり、不信感を招くものを確認する
• 単一の UI ですべてのユーザーに対応できるのか、複数の UI を作成する必要があるのかを調べる

もちろん、可能であれば、ユーザビリティ テストやユーザーとの直接の対話を通じて、選択した設計が適切かどうかを確認する必要があることは言うまでもありません。

ペルソナの数

大半の対話型製品には、複数の対象セグメントが存在します。ということは、ペルソナも複数作成する必要があることになりますが、あまり多くのペルソナを作成しても、プロセスが複雑になるだけです。目安として、大半のプロジェクトでは、3 ～ 4 人のペルソナを作成すれば十分です。作成しようとしているペルソナが 5 ～ 6 人より多くなったら、再検討してください。

多くの専門家は、1 つのペルソナを主要ペルソナとして指定し、その他のペルソナは補助的なペルソナとして扱うのがよいとしています。デザインの意志決定は主要ペルソナを念頭に置いて行い、(思考実験による) テストで補助的なペルソナを使用するようにします。そして、補助的なペルソナのニーズが満たされていない場合は、満たされるようにデザインを追加します。主要ペルソナと補助的なペルソナの両方の要求を満たすデザインを作成できない場合は、それは複数の UI を検討する必要があることを示唆しています。

ペルソナと画面の結合

ユーザーと対話型製品のやり取りは、2 つのモデルを交差することによって決まります。1 つは、UI のデザイン モデルです。このモデルには、ナビゲーション、対話デザイン、および情報アーキテクチャが含まれます。もう 1 つは、メンタル モデルです。対話には、ユーザーのメンタル モデルが反映されます。ユーザーのメンタル モデルには、ユーザーのシステムに関する知識、コンピュータ全般に関する知識、製品の分野に関する専門知識が含まれます。

すべての対話は、ユーザー側の目標から始まります。ユーザーは画面を見て、実行可能なアクションの選択肢を確認し、目的に近づくためのアクションを選択します。ペルソナは、ユーザーのメンタル モデルを把握するのに役立つという点において、デザイン開発の有効なツールとなります。

各画面について、ユーザーがその画面から到達できる目標を列挙してください。そして、ユーザーが使用可能なオプションを処理して、正しいアクションを選択するために必要な情報がすべてデザインに含まれているかどうかを確認します。欠けている情報がある場合は、ユーザビリティに問題があるため、デザインのやり直しが必要になります。

ペルソナに含める情報

大半の人は、一見、開発中の製品には無関係に思えるような個人情報でもペルソナにどんどん取り込むことが重要であると感じています。そのようにして多くの情報をペルソナに取り込むことによって、ユーザーに関するストーリーを語ることができるようになり、そうしたプロセスによってペルソナの価値がさらに向上するというわけです。

この主張は正しいのですが、それでも取り込むべき情報と、取り込むべきではない情報を判定する必要はあります。そうしたときに役に立つツールとして、George Olsen 氏が開発したペルソナを作成および使用するためのツールキットがあります。このツールキットは、Interaction by Design のページでダウンロードできます。

Olsen 氏は、ペルソナの記述に含めるかどうかの検討対象となるあらゆる要因のリストを作成しました (このリストは圧倒されるくらい膨大なものです)。このリストはあまりに膨大すぎてすべてを反映させることはできませんが、ペルソナの作成プロセスを考えるための開始点としては優れていると思います。

筆者は、一般に、次の要素をペルソナの記述に含めるようにしています。

• ペルソナの名前と写真
• 個性を表す引用やモットー
• 人口統計情報 (性別、年齢、婚姻関係の有無、家族、住所)
• 学歴
• 職業
• ライフスタイルと人生の目標
• コンピュータの操作能力と使用状況
• 考え方や価値観

こうした記述をベースにして、開発中の製品のコンテキストで意味をなす要素を追加していきます。たとえば、バンキング システムを開発しているなら、金融資産、金融に関する専門知識、主な出費、お金に対する考え方などを含めます。さらには、直接には関連しないものの、信頼に関する問題や、製品の設計に影響を与えるようなアドバイスを受けたり、感情的な要素や心構えを形成する場所としての金融機関との付き合い方も含めることを検討します。

基本的なペルソナができ上がったら、好きなものやいつも感じている不満など、個人的な要素を取り込んでいきます。インタビューを実施する場合は、好きなテレビ番組、読んでいる雑誌、話に肉付けするためのその他の個人データなどを質問します。

ペルソナは強力なツールです。非科学的だと思う人もいるかもしれませんが、ペルソナを作成することで、設計プロセスを支援すると同時に、ユーザーに関するデータを取りまとめて、開発チームと関係者との間でユーザー像を統一することができます。

ソフトウェア的視点

Ambrose Little

ペルソナは、適切な人たちが作成プロセスに参加すれば、作成するだけでも大いに価値があります。実際、ペルソナを作成するプロセスは組織に大きな価値をもたらすと言われています。しかし、ペルソナは、完成した後は価値がなくなるというわけではありません。使う時期と方法さえ理解すれば、完成した後も十分に価値はあります。

ペルソナの概念に詳しい大半の開発者は、Alan Cooper 著『The Inmates Are Running the Asylum』(Sams—Pearson Educatio、2004 年) を読んで、その知識を習得しています。Cooper 氏は、一般に、ソフトウェア開発にペルソナの手法を持ち込んで広めた人物として知られています。彼は、インタビュー取材に応じて、ペルソナについて「明るい光の下で設計が行える。ユーザーの目線で見るための強力で柔軟性のあるツールである」と言っています。この説明は、私が聞いたことがある説明の中で最も的を得たものです。

ペルソナの使い方を知るには、ペルソナの誤った使い方について考えてみるとよいでしょう。Christopher N. Chapman 他著「Quantitative Evaluation of Personas as Information (情報としてのペルソナの定量評価)」という論文で、著者らは、ペルソナは実在のユーザーに関する実際の情報の有効な情報源ではないと主張しています。Chapman 氏らは、実際の顧客属性データベースから疑似ペルソナを生成するデモを行い、生成された疑似ペルソナと元データとの一致率がきわめて低いことを示しました (実質的に、いずれかの顧客属性レコードと一致するペルソナは 1 つも存在しませんでした)。これは、定量分析を行うときの警告として的を得たものです。つまり、ペルソナを実在する個人であると思い込んではならない、本当に数量的なデータをソリューションに与える必要があるときにペルソナで代用してはならないということです (Death to Personas! Long Live Personas! を参照)。また、実データが必要な場合にペルソナを実データとして使用してはなりません。ペルソナは派生的な設計資産であって、実際の顧客データではないからです。

たとえば、製品またはプロジェクトで、サポートするオペレーティング システムを決定する必要がある場合は、ペルソナに依存して決定を下したりしないでしょう。対象顧客ベース全体で各オペレーティング システムがどの程度の割合で使用されているのかがわかる顧客データを参照し、その実データに基づいて決定を下します。あるユーザーが特定の OS を好んで使用しているかどうかはペルソナで把握できますが、定量情報を得た上での意志決定は、実際の数量データに基づいて下す方がはるかに良い判断ができます。

ペルソナは、ソリューションを設計する方法、およびソリューションに取り込む機能について一貫性のある洞察を与えてくれる定性情報ツールとしての方がはるかに有用です。人間中心型の設計の第一人者として有名な Donald Norman 氏は、次のように語っています。「ペルソナは現実的であればよいのであって、現実である必要はない。また、ユーザー ベースの特性を正しく反映していれば、正確である必要さえない」Norman 氏は、ペルソナの主な用途として、コミュニケーションと感情移入の 2 つを挙げています。これはきわめて的を得た指摘だと思います (「Ad-Hoc Personas & Empathetic Focus」を参照)。

機能的要件という観点から考えることに慣れている人は、感情移入と聞くと、極端に感傷的で、少し異質なものと思えるでしょう。しかし、感情移入は、使ってくれる人のために良い製品を作るという観点から見れば、重要な価値観です。つまり、使う側の立場になったつもりで考えるということです。

どのような機能を含めるべきか検討するなら、ペルソナが役に立ちます。機能に優先順位を付ける場合にも役に立ちます。対象ユーザーが特定の目的やタスクを実現する方法について検討するなら、ペルソナは不可欠なツールです。別個のインターフェイスを設計する場合でも、ペルソナを使用すれば、インターフェイスをどのように設計する必要があるのかを想像できるだけでなく、ペルソナの要望が実現されているかどうか設計を再チェックすることもできます。

機能とその優先順位の明確化

設計プロセスにペルソナを含める具体的な方法として、関係者にペルソナの優先順位を付けてもらい、それに応じてソリューション内の各機能を優先度で重み付けする方法があります (図 2 を参照)。

この簡単な表から、対象ユーザーの視点で見た場合、このソリューションにとって、アイテムの表示機能の方が発注機能よりもはるかに重要であることがわかります。重み付けは、マーケティング、販売、製品管理 (ビジネス上の関係者) などの入力時に、事前に設定しておきます。ここで重要な点は、この表はビジネス全体の優先順位付けではないという点です。ビジネス自体のニーズや目標が現れていないからです。

たとえば、会社が予算を割ける現実的なソリューションであるためには、発注機能はほぼ間違いなく必須の機能です。調和のとれたソリューションを実現するには、ビジネス上のニーズとユーザーのニーズのバランスをとる必要があります (バランスがとれない場合、そのソリューションはおそらく成功しません。このことは、ソリューションのアイデアを追求すべきかどうかを単純に評価するうえでのペルソナの価値をよく表しています)。

ここで重要なのは、ペルソナを使用する目的は、対象ユーザーの視点から、開発サイクルのさまざまな局面を徹底的に検討し、評価することであるという点です。Elizabeth がアイテムの表示機能を必須だと評価していることを理解するには、実際に彼女の立場に立って、彼女がその機能をどのくらい評価しているのかを考える必要があります。これは、ビジネス アナリストやプロジェクト マネージャ、または開発者にとっても、同じ尺度を使用して、特定の機能の包括的な評価を試みる方法よりもはるかに優れています (筆者はこうした方法が実際に採用されているのを何度も見てきました)。この手法はバグ修正の優先順位付けにも応用できます。つまり、ペルソナを使えば、緊急度や重大度などの一般的な尺度に比べて、はるかに現実的な優先順位付けを行うことができます。

実現方法の明確化

別の例として、あるユーザーが特定のソフトウェアをどのように使いたいと思っているかを徹底的に検討する場合にもペルソナを使用できます。この手法は、何か新しいことを行うときや、既存のソリューションを改善しようとしているときに有用です。もちろん、ユーザー エクスペリエンスに基づいて差別化しようとするときにも有用です。実際、優先順位付けまで行わなくても、ペルソナを使用することで、何を構築すべきかを正しく定式化できます。具体的には、すべての機能の一覧、機能的な要件、正式なユース ケースなどから始めるのではなく (こうしたものを既に用意している場合でも決して遅くはありません。こうしたものも同じような方法で定式化し直すことができます)、各ペルソナの目標と動機という観点から何を構築すべきかという質問を再構成するところから始めます。

ペルソナには 2 つの主要な側面があります。この 2 つの側面は、本当の意味で感情移入による洞察を得るうえで、個々の属性や好みよりも役に立ちます。一度立ち止まって、ある人があなたのソリューションを使用して何かを実行したい理由、および達成しようとしていることを自問してみると、問題点を明確にするのに大いに役立ちます。

同様に、トラブルが発生して (実際、筆者に最近起こったことですが)、設計の至るところで面倒な問題を多数抱えてしまった場合、全体を俯瞰して、ペルソナの視点からまったく新しい方法で問題に取り組むと効果的な場合があります。設計に関する古い考え方から脱却するのは難しいこともありますが、ペルソナを使用すると、自分のアプローチを定式化し直すことができます。筆者の場合、この方法によって、対象ユーザーに対して基本的に同じ機能を提供するのに、大幅にアプローチを変更する必要性が見えてきたことがあります。

ここでの鍵は、何らかの式やテクニックを使用するのではなく、必要なものを構築する方法についての自分の理解を定式化する方法を変更することです。

コミュニケーション

あなたがソリューションの作成にかかわる唯一の人物でない限り、ペルソナは、開発者が実現しようとしていることについて、洗練された共通の言葉を使用し、理解を深めるための優れたツールになります。ドメイン主導型のデザインの中心となる考え方はユビキタス言語です。ペルソナを使用すると、ドメイン、およびドメインに属する人が使う言葉の両方に対する理解が深まり、全員の共通理解が進みます。

ペルソナを形成するための調査は通常、設計プロセスの初期に行われます。ユーザーは忙しく、インタビューなどの形で情報を提供できる時間も限られているためです。以降、実在のユーザーから情報を得ることはできませんが、ペルソナはいつでも必要な場所にいて意見を聞くことができます。

要するに、ペルソナは実在のユーザーに話を聞くことができないときに最高の代役を務めてくれるのです。しかも、気分や気まぐれな考え、あるいは回答をゆがめてしまう可能性のある偏見に左右されることがないため、場合によっては実在のユーザーよりも優れた情報源になります。もちろん、だからと言って常にペルソナの方が優れているというわけではありません。ペルソナの回答は聞き手の解釈しだいで変わるからです。

しかし、解釈する必要があるというのは実は利点にもなります。ペルソナを使えば、何をどのように行うのかについて、批判的な考えの人と議論を経て同意に至ることができます。そうしたことは、開発チームが典型的な顧客の代表としての個人に依存していると起こりません。

また、チーム メンバが人間中心型のデザインに熱心に取り組んでいる場合でも、ペルソナを使用すれば、独善的な仕様とはどのようなものかを説明することができます。筆者は、こうしたことが起きるのを何度か経験したことがあります。チームの数人のメンバに理解されないためデザインの仕様が疑問視されるケースです。この数人のメンバは自分たちの直感的とも思える見方でデザインを見ていたのですが、ソリューションはそうしたメンバのために開発しているわけではありません。こうした場合にペルソナは、既知の具体的な基準点を提示して、どうしてそのような仕様になったのかを説明してくれます。これにより、開発しているのは、個々のチーム メンバにとって意味のあるもの (つまりメンバの気に入るもの) ではなく、対象ユーザーにとって意味のあるものであるという方向に議論の焦点が移っていきます。ときには、ペルソナの視点から要件や仕様が疑問視されることもありますが、その場合も、異なる解釈に基づく議論によって、個人が自分の考えだけに基づいて提案するソリューションよりも優れたソリューションを導出できます。

図 3 ペルソナ ベースのストーリー

ペルソナを使用したコミュニケーションの具体例として、シナリオとストーリーによるコミュニケーションがあります。"シナリオ" という用語は多くの意味を含むため、ここでの意味を明確にしておきます。ここでいうシナリオとは、デザインに影響を与える可能性がある特定のコンテキストにおいて、ユーザー (ペルソナが望ましい) と製品の間で行われる一貫性のある対話で構成される説明的な物語のことです。シナリオでは、デザインの詳細には触れず、ソフトウェアを使用するユーザーがどのような体験をするかに焦点を当てます。つまり、シナリオは、デザインの方向性についてのユーザーから見た感じ方とアクションを示します。シナリオの反対の概念が " ストーリー" です。ストーリーは、シナリオの背景を提供する包括的で一貫性のある物語のことで、ニーズ、目標、要望に焦点を当てます。ストーリーでは、理由、つまり人間の動機に重点が置かれます。

まず、ペルソナを基にしてストーリーを作成し、シナリオに分割します。シナリオを直接使用して、ソリューションを設計し、でき上がったデザインを確認および検証できます。ストーリーは、おおむね目標 (この場合はストーリーのコンテキストと動機要因) および対話/作業/アクティビティに対応し、シナリオは、おおむね特定の対話に対応します。図 3 に、架空のソリューションにおけるストーリーの例を示します。

この例は、Scrivener というツールの画面コピーです。Scrivener では、ドキュメントの断片をスタイリッシュなインデックス カード ビューとして表示できます。筆者は、ストーリーとシナリオを簡潔で的を得たものにするために、このビューを使用しています。多忙な人たちが読んで使うものですから、コンパクトにまとまっていなければなりません。図 4 に、このストーリーから導出可能なシナリオを示します。

図 4 ペルソナ ベースのシナリオ

これらのシナリオは、ペルソナ (Sandra) の視点から見た、個別の、しかし一貫性のある対話を表しています。ストーリーは、ペルソナの持つ現実的な目標に基づく既知の内容です。想像力を働かせる必要があるのはシナリオです。この例では、「Sandra は、このソリューションを使用して、どのような方法で自身の目標を達成するつもりなのか」という質問に対して、Sandra が行う内容をあくまで物語として記述したものを回答としています。ストーリーはシナリオからシナリオへと流れているものの、各シナリオの対話はそれぞれ独立したものとして思い描くことができます。つまり、開始点、何らかの対話、明確な終了点が存在し、それがさらに別のアクションへの基盤となります。

これらのシナリオでは、そうした対話を UI として実現する具体的な方法について触れないようにしている点に注目してください。その理由は 2 つあります。1 つは、UI のデザインに早期の時点で制約を与えたくないためです。対話を実現するための UI ソリューションの候補をいくつか用意し、それぞれの候補を繰り返し試してみることができるようにしておく必要があります (各シナリオを繰り返し試してみることができるようにしておく必要があるのと同じです)。もう 1 つは、UI は UI 用語 (ワイヤーフレーム、モックアップ、プロトタイプなど) を使用して設計した方がはるかに効率的かつ効果的だからです。

同じストーリーとシナリオが、単純にユーザー調査から導出されることもあれば、詳細な機能要件とビジネス要件から導出されることもあります。こうしたシナリオは設計プロセスに応じてさまざまな場所に適合させることができますが、重要なのは、最小限の投資で最適なソリューション設計方法を徹底的に検討することができるという点です。

ペルソナのショートカット

図 5 ペルソナのショートカット (不鮮明な画像は意図的)

最後に、Charlie が触れたコミュニケーションの 1 つの側面として、ペルソナ自体を伝達する方法について簡単に説明しておきます。うまい方法はたくさんあります。また、使用環境にもよりますが、偏見を排除する必要があるかもしれません。つまり、SharePoint 上に置いてあるだけの Word 文書や PowerPoint プレゼンテーションなどのデジタル上の存在よりも、ポスター、カード、ボール紙の切れ端、アクション人形、その他の実際の物理的なモノの方が、ペルソナと意思疎通を図り、常に念頭に置いておくにはずっと効果的である可能性が高いのです。開発者はあらゆることをテクノロジで解決しようとしますが、ペルソナも含め、デザインに関しては、テクノロジによらない解決策を選択した方が最善の方法となることが多いのです。

ただし、こうした物理的なモノを用意したとしても、多くの開発者はさまざまな環境 (コーヒーショップや自宅など) で作業するため、そうしたモノをいつも手元に置いておくわけにはいきません。そのような場合は、バックアップ用のコピーを作成しておくと便利です。個人的には、デスクトップ上にペルソナのショートカットを作成することをお勧めします (図 5 を参照)。

この方法なら、リンクをクリックするだけでデジタル版のペルソナ文書をいつでも参照できるだけでなく、ペルソナ自体 (画像と名前) を常に忘れないようにすることができます。それに、何より簡単です。ショートカットを作成し、アイコンをペルソナの顔写真に変更するだけです。これなら出張の多い人でも簡単にペルソナを利用できます。

まとめ

今回は、ペルソナについてかなり詳しく解説しました。最初に、ペルソナの作成方法、具体的には、ペルソナを作成、検証、成長させるためのプロセスと手法について説明しました。この作業には、チーム全体が開発中のソリューションの対象ユーザーに関する理解を深めることができるという大きな利点があります。

次に、ペルソナのいくつかの使い方、ペルソナの誤った使い方、およびペルソナに感情移入することで何をどんな方法で作るのかを伝え対象ユーザーにとって意味のあるソリューションにする方法について説明しました。また、ペルソナが、共通の言葉を使用し、技術的または序列的な言葉ではなく、人間の言葉で共同作業することによって、チーム全員の共通理解を維持するのに役立つコミュニケーション ツールであることについても解説しました。

ペルソナの詳細については、「GUIUI.com のペルソナ関連リソース」および「MSDN のテスト担当ペルソナ」を参照してください。

ご意見やご質問は magux@microsoft.com の Charlie と Ambrose までお送りください。

Dr. Charles Kreitzberg はユーザビリティのコンサルティングとユーザー エクスペリエンスのデザイン サービスを提供する Cognetics Corporation (www.cognetics.com) の CEO です。彼は、製品のビジネス目標をサポートしつつも、ユーザーを魅了し、楽しませる直感的なインターフェイスを作成することに情熱を燃やしています。セントラル ニュージャージー在住で、パフォーミング ミュージシャンとして夜間のアルバイトをしています。

Ambrose Little は、夫人と 4 人の子供とセントラル ニュージャージーで暮らしています。ソフトウェアのデザインおよび開発に 10 年以上携わっており、INETA 講演者であり、Microsoft MVP でもあります。最近は、テクニカル デザインから人々のためのデザインにシフトし、現在は Infragistics 社のユーザー エクスペリエンス デザイナです。