データ駆動型ペルソナをいつ使用し、いつ構成するのですか？
私はHCIを勉強しており、私のコースでペルソナを作成するための焦点は、ペルソナがユーザーの研究データから導出されるべきであるという断固たる決意です。私は昨年、アダプティブパスの集中的な授業にも参加しました。ユーザー調査の日もこのキャンプにありました。しかし最近、私は「それらを構成する」ことは大丈夫だと示唆しているように思われる人々といくつかの会話をしました。
誰がいつどのテクニックを使うのが最善かについての指針はありますか？それは単に予算と時間の制約に帰着しますか？
IMHO結論として、すべてのペルソナはデータ主導型である必要があります。結局のところ、ペルソナは設計/開発プロセスでユーザーを表すためのツールであり、ターゲットユーザーの属性を使用して作成する必要があります。
ただし、すべてのペルソナは「クライアント固有の」データによって作成する必要がありますか？実用的にはそうは思いません。一般的な製品の一般的なペルソナをサポートするのに十分なデータがあります。特に、UCDが設計/開発ライフサイクルにまだ浸透していないため、これで十分な場合もあります。
たとえば、妊娠中のWebサイトにはいくつかのペルソナがあります。
- 妊婦
- 新しい母
- 等.
関連するデータに基づいて説得力のあるペルソナを可能にする十分なデータがWeb上にあると思います。
あなたが狂うことができるところは、物語です。私はそれらを現実のものにするために、装飾するのが大好きです。私はいくつかの画像を使用し、家族を想像し、私のお気に入りのテレビ番組の人々の後にそれらを呼び出す傾向があります。
HTH
マット
pSペルソナを作成するときは、デザインを作成していない人のアンチペルソナを忘れないでください。
すべてのペルソナはデータ主導である必要があると思います。
自分の感情や推測に基づいてペルソナを構築することを主張する場合は、「弾力的なユーザー」トラップに注意してください。
アランクーパーによる「The Inmates Are Running the Asylum」の「elastic user」に関する私のお気に入りの引用は次のとおりです。
「ユーザー」というフレーズを聞くと、「弾力的なユーザー」のように聞こえます。 エラスティックユーザーは曲げたり伸ばしたりして、その瞬間のニーズに適応する必要があります。ただし、私たちの目標は、曲げたり伸張して適応するソフトウェアを設計することです。ユーザーのニーズ。 プログラマーはこの神秘的なエラスティックコンシューマーのために無数のプログラムを作成しましたが、彼は存在しません。
プログラマーが便利でユーザーをWindowsファイルシステムにダンプし、必要な情報を見つけたら、エラスティックユーザーを収容できるコンピューターとして定義します。 -パワーユーザーの読み書き。また、プログラマーが気にせず便利と言って、無知なウィザードでユーザーを困難なプロセスに導いた場合、エラスティックユーザーは義務的でナイーブであると定義します。 、初めてのユーザー。
弾性ユーザーである「仮定」ペルソナは、デザイナーやエンジニアにユーザーの研究なしでやりたいことを許可し、ユーザー中心のファサードを作成するだけです。
ペルソナが実際の使用調査に基づいていることを確認してください。
ところで、私はスティーブポーティガルがこのトピックについて強い意見を持っていると思います。
ペルソナノングラタ
私の経験では、「仮定」ペルソナは、開発チームがそれらを信じていないため、急速に廃れてしまいます。ペルソナをクライアントに提出する前にチェックする7つの項目のチェックリストがあります。
- ペルソナは実際の顧客との状況に基づくインタビューに基づいていますか？
- ペルソナは、名前、写真、製品に関連する説明を含めることで共感を呼び起こしますか？
- ペルソナは、日常的に顧客と接する人々にとって現実的に見えますか？
- 各ペルソナはユニークで、他のペルソナとの共通点はほとんどありませんか？
- ペルソナには、製品に関連する高レベルの目標が含まれており、主要な目標を述べる引用が含まれていますか？
- ペルソナの数は、設計チームがそれぞれの名前を覚えて、ペルソナの1つがプライマリとして識別されるのに十分な数ですか？
- 開発チームは、ペルソナを設計上の決定を行うための実用的なツールとして使用できますか？
学校にいるときは、この方法は役に立たないかもしれませんが、いったん作業を終えると、これは、必要なものの一部を得る方法となり、ユーザー調査の価値について説明する機会にもなります。
利用できる調査はないが、デザインを指示する方法として「ペルソナ」を使用したい場合、私はユーザー「プロファイル」と呼ぶものを作成します。
コンテンツは決して構成されません。代わりに、ビジネスチームからの入力から派生します（これには、販売、カスタマーサービス、コールセンターの担当者などが含まれます）。
これは真のペルソナよりも劣っており、ペルソナは常にユーザーの調査に基づいているだけであることをビジネスチーム/利害関係者に非常に明確にします。また、リスクの概要を説明し、コンテンツが設計チームによる製作からではなく、それらの入力からのものであることを強調します。
多くの場合、これによりビジネスチームは、実際のユーザーのプロファイルを検証してペルソナに変えることができます。 「プロファイル」も忠実度が低く、コンテンツが少ないため、実際のユーザーからの入力がないとコンテンツは制限されます。これは、ビジネスチームがユーザーに関する知識のギャップがある場所を確認するのにも役立ちます。
そのために、私はビジネスチームをグループとしてワークショップを実施しています。これは、彼らが知識のグループとしてどこに立つかについて共通の認識をもたらすために重要です。
空白のプロフィールが壁に掲示されます（例：顔/基本的なタイトルではなく、シルエット画像）残りは空白です。
予想される情報の種類や、どのような質問をする必要があるかについて、手順、サンプル、ウォークスルーが提供されます。
全員に付箋とシャープーのセットが提供されます。
グループはいくつかのプロファイルに分割されます。
グループのサイズに応じて、特定のユーザーについて知っているすべてを書き込み、投稿するために4〜10分が与えられます。次に、各グループが各プロファイルに入力するまで、各グループはさらに4〜10分間回転します。
次に、ファシリテーターは各プロファイルをウォークスルーして、あいまいなメモやわかりにくい付箋を明確にします。
設計チームは入力を受け取り、アフィニティモデル（共通の付箋でグループ化した付箋）を作成して、1つの段落「ストーリー」とユーザー情報 "clouds"（タグクラウドと考えてください。ただし、ユーザーの調査結果の要約が必要です）例「効率が鍵」「時間の制約」「ブランド主導」など.
その後、ビジネスチームと再度会い、調査結果を提示してさらに検証します。これは、ギャップを実証し、設計チームがエンドユーザーと情報を検証できるようにビジネスチームを奨励する機会です。
最悪の場合、設計チームに方向性を提供すると同時に、ユーザーチームの調査が重要である理由をビジネスチームに洞察します。
データ駆動型ペルソナの方が信頼性が高いと私は同意しますが、主観的な入力から利益を得られる状況もあります。
たとえば、クライアントが日常的にエンドユーザーに連絡する従業員の銀行にアクセスする場合（コールセンターの工作員など）。このような場合、このようなエンドユーザーの知識を持ったスタッフの意見を聞くことは有益だと思いますし、情報を得るために「ペルソナワークショップ」を実施する価値はあります。
私は最近、Tamara AdlinによるAd Hoc PersonasのUIEバーチャルセミナーを見ました。 2つのタイプのペルソナが2つの非常に異なる目的で議論されました。 （ http://www.uie.com/events/virtual_seminars/ad_hoc_personas/ を参照してください-プレビュービデオが利用可能です。）
1）データ駆動型のペルソナは、製品設計ツールのようなものであり、実際のユーザー/使用状況データに基づいています。
2）アドホックペルソナは、組織がすでに手元にある情報を使用して作成されます。これらは概念のコミュニケーションツールであり、チームや利害関係者に焦点を合わせ続けるのに役立ちます。また、データ駆動型ペルソナの準備ステップ（検証可能な仮説）としても使用できます。
実際のところ、ほとんどの企業はすでに「ペルソナ」を持っています。つまり、ユーザーベースが誰かというアイデアです。これはデータに基づく場合もあれば、企業の神話である場合もあります。アドリンは「隠されたペルソナは製品に大混乱をもたらす可能性がある」と言い、私も同意します。だからペルソナの共有のアイデアを持っている方がいい。
ウェビナーは素晴らしく、ペルソナ技術を転用し、アドホックペルソナを本当にうまく行うためのいくつかの創造的なアイデアがありました。ペルソナのコンセプトを広げるのにおすすめです。
私はそれが研究に基づいている必要があることに同意します。
あなたがトピックに興味があるなら、私はユーザーが常に非常に良い本であるスティーブ・モルダーとジブ・ヤールから正しいことをお勧めします。
Googleブックスで検索できます または Amazon 。