ユーザテストのために『ユーザビリティエンジニアリング』を読んで、まとめる
Webの開発者ですが何つくるべきかわかりてえと言っていたらデザイン部に転属になりました。とはいえ肩書きが変わっただけではサービスデザインができるようにはなりません。ので何かしら動かなければいけません。ちょうど手元に出来立てほやほやのWebアプリがあるので、ユーザテストをやってみることにしました。
さて何かやるなら前提知識として一冊くらいは本読んでおかねばな、という気持ちでこちらの本を読みました。
結論読んどいてヨカッターと思います。体系的に知識がまとめられている本は、ネット上の断片情報を自分で切り貼りするのに比べればずっと信頼できますよね。
以下にわたしにとって必要な知識（ユーザ中心設計ていうのは何なの、ユーザテストをするには何を準備してどこを見なけりゃならないの）をまとめました。
ユーザ中心設計（UCD）
ユーザ中心設計ていうのは何なの
作り手の勝手な思いこみを排除して、真にユーザが求める製品を実現するための設計思想のこと。
ユーザ中心設計のプロセス
①調査：ユーザの利用状況を把握する。
②分析：利用状況からユーザニーズを探索する。
③設計：ユーザニーズを満たすような解決案を作る。
④評価：解決案を評価する。
⑤改善：評価結果をフィードバックして、解決案を改善する。
⑥反復：評価と改善を繰り返す。
ユーザ中心設計のプロセス毎に代表的な手法
①調査：ユーザインタビュー
②分析：ペルソナ
③設計：ビジネスモデルキャンバス、リーンキャンバス、プロトタイプ、カードソート
④評価：ユーザテスト
（あ〜なんか聞いたことあるしたぶんどれかのプロダクトではやってるのだろうがこういう位置感、手法のひとつってことね〜）
ユーザニーズ≠ユーザーの意見
ユーザ中心設計は、ユーザの「こんな機能が欲しい」「この部分を変更して欲しい」というような要求や不満に対応することではない（！）。設計者はユーザインタビューや実際の利用履歴、ユーザテスト結果を分析することによってユーザニーズを探索する。
ユーザビリティ評価
「総括的評価」と「形成的評価」
評価には「総括的評価」と「形成的評価」の2種類がある。
総括的評価：達成度合いの測定。例）TOEICのスコア
形成的評価：理解度の改善のためのフィードバック。例）英会話教室での発音添削
これはユーザ評価でも同様。
総括的評価：例）ユーザテストでのタスク達成度。評価点式のユーザアンケート
形成的評価：例）思考発話法を使ったユーザテスト
総括的評価しか行わないのならば、それは全く無駄な投資になる。形成的評価抜きの評価結果からは具体的な改善策が得られないため。（昔社内の他プロジェクトでNPSスコア出してたのって…）
ユーザテスト
ユーザテストの目的
「この製品はユーザブルである」という仮説の反証。使いやすいか。
観察のポイント
①効果：ユーザが独力でタスクを完了できるか
②効率：無駄な操作を行ったり、戸惑ったりしないか
③満足度：不満を覚える部分はないか
思考発話法
ユーザテストのデファクト手法。ユーザには操作しながら「今、何を考えている」「次にどうしようと思う」「なぜそうしようと思ったのか」を全て言葉にしてもらう。これによって、ユーザが製品のどの部分に注目して、それをどう解釈して、どんな行動をとったのかを詳細に把握する。
ユーザテストの準備
①タスクの設計：網羅する必要はなく主要なタスクのみでok、スタートとゴールを定義する。
②インタビューガイドの作成：タスクの定時順序や時間配分、インタビュアが話す内容をまとめる。
③ツールの準備：ダミーの個人情報などユーザがタスクを実行する上で必要な情報を渡せるように作っておく。アプリにダミーデータを入れておく。
④パイロットテスト：実際にユーザテストを行う前に、社内の人間に対してテストのテストを行う。
インタビューガイド例
1. イントロ（数分）：撮影/録音の許可、NDAへのサイン
2. 事前インタビュー（5-15分）：ユーザのバックグラウンド
3. 事前説明（数分）：思考発話の依頼、機器の操作練習
4. タスク実行観察（30-45分）：タスクの提示と観察
5. 事後インタビュー（5-10分）：感想、主観的評価、要望
ひとこと
とまあそんなわけで、わたしはユーザテストのために、テストタスク設計とインタビューガイド作成をやる必要があることがわかりました。組織がユーザ中心設計をやっていくために、はじめの一歩的な活動として既存プロダクトのユーザテストから始めるというのはそう間違ってはない、らしいです。