最近ペルソナとかシナリオ法とかについて調べているのでおぼえた事や考えたことを書いてみます。

ペルソナ／シナリオ法ってなんだ？

ペルソナとは仮想ユーザーのことです。ただし勝手に想像した仮想のユーザー像ではなくて、アクセスログ、市場調査、顧客ニーズのなどから分析するのです。
つまりその調査データを元にユーザーのプロフィールや行動に見られるパターンを統合した架空のユーザー像のことなのです。
このペルソナ（ユーザー像）をもとにそのユーザーがどんな行動をするのか（webの場合はどんなふうにアクセスしてサイト内を閲覧していくのか）を具体的にするために、

• 名前（山田太郎さん とかじゃなく存在してそうな名前の方がよい）
• 年齢
• 住所
• 職業
• 家族構成
• 趣味（すごく具体的に）
• 年収・勤務先やどんな仕事をして、どんな不満を持っているのか
• 休日の過ごし方や、最近感じていること
• よく読む雑誌
• インターネットをする時間や場所・・・

これらのようなデモグラフィックデータを詳細に設定します。
この時点でのデモグラフィックデータはあくまでも仮説。仮説でＯＫなので詳細にします。ここの設定が詳細であれば詳細であるほど、その後のシナリオの精度が上がります。この目的は、

• コンテキスト（ユーザー行動の文脈）が再現しやすくなる
• 状況を厳密に描写できる（誰が、何を、どうした）
• 関係者全員がイメージしやすいので、ユーザーイメージを共有できる

ユーザの姿を精緻につくりあげることでより具体的に想像力が働くようになり、より多くの具体的なニーズを抽出することができるのです。
ただし注意しなければいけないのは、想像力が働くあまり「こうだったらいいな」ということを入れがちになってしまうこと。
例えば、

• ターゲットが独身のキャリア女性なので、都心のリッチなマンションに住んでる（はずだ）
• リッチなマンションにはチワワとか小型犬を飼っている（はずだ）
• オフタイムはエステやネイルサロンでリラックスする（はずだ）

どうでしょう？（はずだ）という想像を入れていくとだんだん「独身のキャリア女性」というよりも「人気キャバ嬢」になってきましたね。
こんなＯＬはいません（たぶん…いるかも知れないがあんまりいない…)。

こうなるとだんだん実際のユーザー像とかけ離れてしまうので、調査データと照らしあわせる事が大事なのです。

ユーザーテストをしてみる

上記でつくったペルソナ/シナリオから画面デザインを作るのですが、実際にそのユーザーがサイトを操作してみたときどうなのよ？というのを実験する。それがユーザーテストです。
これは制作者が仮説でやるわけにはいかないので、実際にそのユーザーに近しい人を用意してテストします。実際のユーザーに近しい人に操作してもらうので作り手側では気づかなかった問題点が発見できるのです。
ここでの目的は、

これについては、「仮説から打ち立てたデザインをユーザに検証してもらうこと」です。

これについてはこちら参照。
未経験者がユーザーテストを行う際の10のポイント – livedoor ディレクター Blog

1. 被験者は友人か知り合いでいい
専門会社に依頼すると、サイトのターゲットに近い属性をランダムに抽出してくれますが、友人で狙いに近い人がいれば、それにこしたことはありません。まずは社内で探してみることをオススメします。

2. 被験者は5人でいい
基本、ユーザーは似たことをいいます。6人目ぐらいから「これは以前聞いたな」という意見が多くなり、5人までで8割の意見はとれると思います。

3. カンタンなゴールを与えよう
被験者には、前もって操作をする目的を伝えます。コマースサイトなら、「買いたいと思っている商品を探して購入してください」や、「商品のなかから、自分に合いそうな物を探してください」とかが目的になります。コミュニティサイトなら、「このサイトを通じて、友人をひとり作ってください」というのも目的になります。とにかく、サイトのジャンルにあったカンタンなもので十分です。

4. 椅子は相手よりさげよう
相手が優越感を感じ、しゃべりやすくなる状況をそろえましょう。さまざまな方法がありますが、自分の椅子の高さを相手よりさげておいて「相手が自分を見下すようにしておく」という方もいました。

基本的には、自分がバカっぽいと相手はしゃべりやすくなります。相手が自分の知っていることをしゃべっても、初めて知ったことにしましょう。ただ、被験者が友人の場合のほうが話しやすいので、友人をつれてきたほうが早いです。

5. プロトタイプは紙芝居でもいい
リニューアルの場合、すでにあるサイトをテストに使えばいいだけですが、新規構築の場合は「どの程度のプロトタイプをテスト用に用意するか」という問題があります。というのは、リリース直前にユーザーテストを実施して意見を反映しようにも、いまさら変更できないからです。

手っ取り早いユーザーテストのひとつとして、紙芝居があります。主要画面のデザインができた段階で、それを紙にコピーしてユーザーに見せ、紙に印刷されたボタンをクリックしたらクリックした先に対応した画面の紙を差し出す、という紙芝居です。さらに前段階でやりたい場合は、構成を紙に書いてやる方法もあります。この場合、手書きの方が被験者が意見を言いやすくなるので、わざと汚く書くという方もいました。

上記は、ユーザーテストを計画するときのポイントでしたが、下記は、実際のユーザーテストを行う際のポイントです。

6.「今何を考えていますか？」と聞こう
ユーザーテストの教科書などでは、まず被験者に「自分の考えていることを口に出してしゃべってください」とお願いするとあります。しかし実際には、被験者は操作に夢中になっているわけで、問いかけなければしゃべってくれません。なので、被験者が何かを迷っていたり、考えていたら「今何を考えていますか？」または「今何をしようとしていますか？」と常に聞きましょう。

7. 「そこをクリックすると、どうなると思いますか？」と聞こう。
ユーザーがなにかをクリックしようとすると、いったんそれを止めて「そこをクリックすると、どうなると思いますか？」と聞きましょう。意外なものを想定していたりします。または「その先は、どんな画面だと思いますか？」と聞くときもあります。声をかけるのが遅れてしまい、ユーザーが次の画面に移った場合は、「想像していたものと、違いはありますか？」と聞けば問題ないでしょう。

ユーザーテストは基本、ユーザーから見てどのようにウェブサイトが映っているかを探るものです。なので、質問は前述の「今何を考えていますか？」と「そこをクリックすると、どうなると思いますか？」のふたつでほとんどが済みます。

8. やたらうなずこう
前述のふたつの質問にユーザーが答えたら、やたらとうなずいて肯定しましょう。被験者は、自分の操作がヘタだと思われたり、自分の頭が良くない、と思われることを恐れています。その恐れをなくすため、相手が言ったことはすべて肯定し、恐れが見えるようであれば、「このテストは、あなたをテストしているのではなく、サイトがどのように映るか、というサイトのテストです」と“あなたを評価しているわけではない”ことを繰り返し言いましょう。ただ、被験者が友人の場合は、バカにして場を軽くしたほうがいいこともあるかもしれません。

9. 誘導しない
被験者がうまく操作ができなかったり、サイトを理解できない場合、ついつい答えを導こうと自分が発言してしまうときがあります。これは、サイトを作っている人がテストをやっている場合、ついやってしまいがちです。自分が発言する際には、絶えず「この発言は誘導ではないか？」と自分に問いかけてから発言しましょう。といってもやってしまいがちですが。

10. 関係者全員で見よう
ユーザーテストは、できるだけサイトに関わっているスタッフ全員で見学しましょう。というのは、サイトを作っているスタッフが「ユーザーがサイトを使うのを間近で見る」という経験はあまりないからです。そのため、作っている人それぞれが「自分の視点がもっとも一般的だ」と思ってしまい、意見が食い違って話しが進まないときがあります。そのような思い込みをなくすためだけにでも、参加する価値があります。

このエントリーでは「被験者は友人か知り合いでいい」「被験者は5人でいい」とありますが、実際のユーザーの方が良いです。こちらが想定しなかったニーズが発見できるかも知れないからです。人数も5人と言わずもっと多くても良いです（予算と時間があえば）。
ユーザーの方とやるときは緊張されてることも考えられるので「8.やたらうなずこう」は大事です。

被験者は、自分の操作がヘタだと思われたり、自分の頭が良くない、と思われることを恐れています。その恐れをなくすため、相手が言ったことはすべて肯定し、恐れが見えるようであれば、「このテストは、あなたをテストしているのではなく、サイトがどのように映るか、というサイトのテストです」と“あなたを評価しているわけではない”ことを繰り返し言いましょう。

あと僕が個人的に気をつけるのは「被験者を名前で呼ぶ」「被験者の会話のペースに自分の話すスピードを合わせる」「悩んでいる、こまっているサインを見逃さずにタイミングを見計らって声をかける」とかも大事ですね。

ユーザーテストの注意点

ユーザーテストから結論を導く場合にテスト結果をすべて信用するのは危険です。
ユーザに協力してもらっている場合は被験者がどんな人かを考えましょう。顧客リストから公募した被験者であればその時点で「その会社を認知している属性」というフィルタリングがかかっているのです。テスト結果をそのまま信用すると、「認知属性（＝ファン）の意見を反映させただけ」になります。それでは一部のユーザーの改善要望に応えただけです。

また、問題の原因が被験者にある場合も想定しなければなりません。その被験者の行動が全てのユーザーの行動を代表しているか、というと荘でない場合があります。もしかしたらその被験者ならではの理由があっての行動かもしれないです。
（例：いつもインターネットをするのが会社の昼休みだけなのでまずはザッとブラウジングだけする。という人もいるかもしれません）

「仮説から打ち立てたデザインをユーザーに検証してもらうこと」が目的なので、テスト結果はデザインやインターフェイスの精度の良し悪しではなく仮説と照らし合わせた上でのテスト結果の有用性を分析して、ペルソナ（ユーザー像）の精度アップを行い、より具体化したペルソナ（ユーザー像）をデザインに落とし込んでブラッシュアップすることが重要になります。