横浜デジタルアーツ 2008情報デザインC K10

各チームが検討して来たプロトタイプ(Flashによるラピッドプロトタイプ)のユーザ評価に参加させていただきました。

本日は後期授業のハイライト「ユーザ評価」の日です。
2008　情報デザインC K10

細かい部分まで含めるとテストしきれないので、主要なタスクをテストとして設定。タスクってどんな風に設定すればいいの？という所で戸惑ったチームもありました。でもここまでの検討でみっちりペルソナとシナリオをつくっているので、要点を聞くとすぐにシナリオに沿ったものに修正できてました。

被験者がタスクによって達成される目標を自分のことのように理解してもらうことが重要なのでシナリオが活かせます。

タスクの内容が適切であっても、唐突に「この携帯電話でメールを送信してください」などといわれてもユーザはとまどってしまいます。本当の利用場面ならば、ユーザ自身に具体的な理由や目的がありますが、テストではそれはありません。動機がないと、ユーザは自発的に行動が起こせず、指示待ちの姿勢になってしまいます。
そこで、仮の状況(コンテキスト)を追加して、タスクを物語風に脚色します。
“ユーザビリティエンジニアリング”樽本徹也 著

■授業メモ
・プロトコル分析とは、もっとも一般的に行われているユーザビリティテストの一つ
・プロトコル分析の本質はリアルタイムで観察すること。
・アンケートでは事実はわからない。
・アウトプットについて何を持って成功とするかと聞くと良かったか悪かったかアンケートを取りたいという人が多いが、それでは真実はわからない。
・なぜなら、例えばハロー効果（ある対象を評価をする時に、顕著な特徴に引きずられて他の特徴についての評価が歪められる現象のこと）を引き起こす記憶などが真実を引き出す邪魔をするから。
・人間は一問一答で形式で聞いても真実を答えない／答えられない。

・「５人のユーザでテストすれば、ユーザビリティ問題の大半(約85%)を発見できる」(ヤコブ・ニールセン博士)
　＝＞同じ割合の問題をアンケートでとろうとすると、何百人のデータが必要。

・人はいきなり発話しながら触ってくださいといっても話せないので、タスクを読み上げてもらったり、適当な文を読んでもらってスムーズに話せる準備をさせるのもポイント
・書き起こしは慣れてくると観察しながら人の心を読むのがおもしろくなってくる人もいる。


それにしても皆いつの間にかすごいチームワークが形成されていました。役割分担もさっと決めてテストしてましたね。しかも横でテストしながら、前のテストで見つかった問題点をその場で修正してプロトタイプの改善を行っているチームもありましたね。この手の早さはすごい！

休み時間もそっちのけで書き起こしや分析。
僕も全部は回れなかったけど所々乱入してテストさせてもらいました。ありがとうございました。


■おまけ
じつは電車の中で↑この本を眺めていたんですが、いろんな立場からの批判を俯瞰してプロトコル分析で何が言えて何が言えないのかをまとめてある良書だと感じました。精読してみよう。