ユーザビリティとは & ユーザインタビューの設計、振り返りについて
以下の書籍を読んだ。
ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―
- 作者:樽本 徹也
- 発売日: 2014/02/26
- メディア: 単行本(ソフトカバー)
購入自体は数ヶ月前に行っていたが、電車内の移動時間等の隙間時間でちょぼちょぼ読んでいても内容が頭に入らないため、 年末に腰を据えて一気に読むことを決意した。 導入部分とユーザインタビューの章が今の業務で悩んでいることと近く、学びも多かったので、ここを私的に要約した。
ユーザビリティ
- ユーザーの満足を得るために保証しなければならない『利用品質』
- 「使いやすさ」ではない。ユーザビリティが損なわれた製品は「使いにくい」で済むどころか、そもそも使えない
- そもそもユーザビリティ自体、特定のコンテキストにおいて、特定のユーザがある目的を達成するために製品を用いた時の効果、効率、満足度の度合いを指す
- つまりコンテキストやユーザが設計されてない時点で論外(実際の現場だと結構見るような気もする)
- 以下を全て満たして初めて『ユーザブル』
- 効果...ユーザが目標を達成するための機能があること
- 効率...なるべく最短経路で目標を達成できること
- 満足度...目的を達成する上でユーザが不愉快な思いをしていないこと
ダメなユーザビリティの製品が出る理由
上記の条件が満たせていないから。
- ユーザ像が無い、もしくは開発陣に最適化された像でしかない
- コンテクストがない、(以下同文
ユーザエクスペリエンス
ユーザビリティが満点でも、製品の評価も満点とは限らない。 コモディティ化を避けたかったら体験までコミットしましょう。
UCDのアプローチ紹介
ユーザエクスペリエンスの設計は表層だけでなく、その下の構造や戦略の土台から考えてないと詰む。(The Elements of User Experience) いきなりアイデア考えたりユーザーの不満を実装するのではなく
- ユーザーの利用状況はなにか、課題(潜在的なものも含めて)はなにか?
- 今から作ろうとしているものは、この課題を効率よくかつ満足度を担保した状態で解決できるか?
を最低限の実装(プロトタイプ)で評価し、OKになるまで実装してはいけない。 この評価はたいてい複数回行われる。見かけの納期は伸びるが、ダメな機能をリリースしてから直すより遥かにマシ。
ユーザインタビュー
よく言われる「ユーザへの弟子入り」が重要。質問は事前に一個用意しておくくらいで十分。 まず教えを請い、わからない部分を根掘り葉掘りし、最後に自分の理解を確認する。終わったら別のことを聞く。
注意点は以下の通り
- ユーザは話を要約しがち
- ユーザの話は時系列に沿ってなかったり抜け落ちがあったりする
- ユーザは例外を無視しがち
アンチパターンの一つとして、「なぜ◯◯しないのですか?」が挙げられる。(結構やりがちだった気がする) これを始めると弟子入りというより議論になってしまう。「◯◯はやってない」→「どれくらい◯◯はやってませんか?最後にやったのはいつですか?」など、あくまでも教えを請う流れを意識する。 なぜ、を考えるのは聞く側が考えるべきこと。
インタビューの設計
- 聞きたいことを整理し、インタビューのテーマ(何を何故知りたいのか)にフォーカス
- 質問をオープン形式に
- 質問の順番を自然な会話風に、プロフィールや普段の仕事の話から、徐々にテーマに移していく
- インタビューガイドを作る(書籍p48参照)
インタビューガイドはかなり役に立ちそう。次回から取り入れる。 「あなた”流”の使い方はありますか?」「◯◯を使っていて、戸惑ったり慌てたり、失敗談はありますか?」「◯◯の機能で、めったに使わない機能はありますか?」 は使えそう。
インタビューの結果を分析する
KJ法が有用。まずはテープ起こしから発言録を作り、これをカード化、グループ化、アウトライン化、最文章化、検証。 p68を参照。
まとめ
- ユーザブルとは「どんなユーザ」が「どんなコンテキスト」で目的を達成する上においていくつかの評価項目が基準値を満たすこと
- 仮にユーザブルでもビジネス的には微妙かもしれない。エクスペリエンスまで考えよう
- ユーザインタビューはUCDにおける調査での一手法。注意点やアンチパターンを踏まないように
- ユーザビリティは即興性が大きいが、とはいえ事前の設計や事後の分析も重要
次はインタビューの事前設計と評価について、深堀りしたい。