HCDの理解2011[初級編Vol.3]

6/11（土）
HCDの理解2011[初級編Vol.3]に行ってきました。

適切なユーザー評価をし、問題となる箇所を洗い出して改善案を考えるというWS。
適切なユーザ評価を通じて問題点が明確化され、より精度の高い改善につながる

今回行ったのは、ユーザビリティテスト（プロコトル法）
・タスク設定がキモ。
・NE比によって導かれた問題のある箇所の発話に注目。
・発話にこそ解決策がある
・タスクの設定はうまく行った
・エキスパートテストやNE比の分析、そこからの問題点の洗い出しでミス

【全体の流れ】
前日：事務局より課題となるWEBサイト通知
↓
座学
↓
ペルソナを作り、そのサイトにあったタスクとインタラクションを設定
↓
エキスパートテスト①（パイロットテスト）
↓
エキスパートテスト②
↓
ノービステスト①
↓
ノービステスト②
↓
書き起こし
↓
NE比分析
↓
発表


【前日：事務局より課題となるWEBサイト通知】
送られてきた課題はチームごとに違い、自分宛に来たメールには
「名古屋市科学館のサイトをなるべく細部まで見ておくように」
※その他DVカメラの持込依頼、PCの持込依頼も。




【座学】講師：浅野先生
とにかくこういったWSでは時間がないので、
後で見直すことを念頭においてメモをとることに専念。

今回はHCDプロセスのユーザ評価を学ぶ
HCDではプロセスのドコから始めても構わないがサイトリニューアルの場合はユーザ評価から

「何を評価するのか」
vol.2：特定ユーザによって特定の利用状況下でユーザ調査
vol.3：指定された目標を達成するために用いられる際の有効さ、効率、ユーザの満足度
↓
ユーザビリティ（使いやすさ）

「評価手順」
①何を評価するのかを明確化
②評価方法の選択
評価の専門家
開発者
ユーザ
③評価と分析
形成的評価なのか総括的評価なのか
形成的評価とは：「どこが分かっていないのか」を調べる
└常に実践することが大事

「評価手法」
様々な評価手法があるが特に覚えてきたいものは下記４つ
・エキスパートレビュー
・認知的ウォークスルー法
・ユーザビリティテスト（プロトコル法）
・長期観察
上から実施が易→難
得られる情報は少→多

実際の調査には様々な手法を組み合わせて行う

「エキスパート評価」
評価者がユーザビリティガイドラインに基づいて行う。
ユーザビリティエンジニアが評価。
・ユーザビリティガイドライン
ヤコブ・ニールセンらが開発
ニールセンの10項目

「認知的ウォークスルー法」
検査者自身がユーザの認知的な行動軌跡を推定して問題点を抽出する方法
段階ごとにブレスト
・各段階を可視性、マッピング、良い概念モデル、フィードバック等の
チェック項目をブレストで評価していく。




【ペルソナを作り、そのサイトにあったタスクとインタラクションを設定】
名古屋市科学館が課題ということで、前回のCDWSに続き自分がペルソナモデルに。

ペルソナ：35才　男性
子どもを連れて名古屋市科学館にプラネタリウムを見に行きたいので情報がほしい
車で行く、子供は３才

タスク設定
・車で行く場合の科学館までの交通アクセスを調べたい　なるべく安い駐車場の場所と料金も
・参考にプラネタリウムの、本日の空席情報が知りたい
・竜巻ラボをテレビで知ったので、夏休みの平日における展示時間が知りたい
・プラネタリウムの、夏休み子供向けプログラムが知りたい

インタラクション設定
・交通アクセスに最下部に駐車場の情報と料金が掲載されている
・TOPに大きなボタンが配置されている　プラネタリウムのページからも到達可
・大型展示から到達可能なタイムスケジュール閲覧
・プラネタリウムの「プラネテーマ」から到達可




【エキスパートテスト①（パイロットテスト）】
開発者によるパイロットテスト
ここでタスクの調整を行った。



【エキスパートテスト②】
ここで失敗
情報取得の経路が分かってしまうので、
タスク設定にエキスパートテスト担当者が関与してはいけない
あくまでサイトを良く知っているがタスクは知らない人間がすること
※最終的には同じ課題の他チームに協力してもらって実行した（タスクを知らない人間）
次回からはこうした方が良いのでは？事務局に提案。




【ノービステスト①】
【ノービステスト②】
タスク設定がうまく行ったので、得たい情報がスムーズに得られた。



【書き起こし】
ここで失敗
時間がなく、次の段階に移行。
本来ならば発話にこそ改善策が隠れているのだが、
省いたことでエキスパートの立場からの改善策になってしまった。



【NE比分析】
ここで失敗
NE比を確認したものの、グラフ作成に失敗し、
NE比の高い問題となる箇所を絞り込まなかった。
その為、タスク全体に修正をかけようとしてしまい、
結果的に時間が足りなくなった。
しっかり視覚化できていればチームで共有でき、
もっとスムーズに問題点の洗い出しから
改善策の検討まで進めたと思う。



【発表】
最近別のWSで発表を担当したこともあって、遠慮。
これが結果的に発表した人を犠牲者にしてしまった。
パワポでまとめる作業もメンバーにお願いした。
オフィス系ソフトの熟練も必要なことが浮き彫りになった。




【その他メモ・雑記】
・ペルソナは３人設定し、３種類のタスクを実行させるとそのサイトの問題点はかなり明らかになる
・タスクは明確な行動でなければならない（個人の嗜好を存在させてはならない）
・行動データが取れなかったら発話とインタビューで裏付ける
・インタラクションもしっかり設定する
・発話の記述があると発表に説得力が出る
・アクティビティとインタラクション次第
・三角点法　三角形の中心にこそ真実がある
・セマンティックディファレンシャル法（SD法）
・ペルソナ：シナリオ法ができればユーザ評価は成功する
・タスク設定が難しい
・NE比は操作自体に時間がかかるものがあるので、かかった時間ではなくNE比によって判断材料とする
・サイトリニューアルの場合、HCDプロセスのユーザ評価から始めても良い
・デザイナーはユーザのことを考えてデザインしないが、しっかりとした検証と確認・修正が必要。
・年に一度しか行わない行動と、継続的に行う行動、前提とする行動の種類によってもデザインは変わる
・NE比５倍以内＝放置　５〜１０倍＝修正　１０倍以上＝放置し、リニューアル時に根本的に変更
・従来のウェブサイトの形＝ツリー型、最適な形はそんなに簡単ではない
セミラティス型＝階層にとらわれず行動を元に設計する
・LATCHを学べていない