「苦悩からユーザビリティテストに希望を託すまでの道のり」と題してプレゼンしたので、資料を公開します

Posted by & filed under いろいろ, 開発.

このエントリーをはてなブックマークに追加
Bookmark this on Digg

苦悩からユーザビリティテストに希望を託すまでの道のり

井上誠一郎

アリエルネットワークCTO

自己紹介の代わりに著書紹介

  • 「P2P教科書」
  • 「パーフェクトJava」
  • 「実践JS サーバサイドJavaScript入門」
  • 「パーフェクトJavaScript」

目次

  • ユーザビリティ改善の苦悩の歴史
  • ユーザビリティテストの教養
  • ユーザビリティテストの実践

ユーザビリティ改善の苦悩の歴史

  1. プログラマを信じた時代
  2. アジャイル開発を信じた時代
  3. 救世主の到来を信じた時代
  4. ユーザビリティテストを信じる時代(< --今ここ)

プログラマを信じた時代

  • アリエルはプログラマだけで創業
  • とりあえずコード書いた
  • ソフトウェア動いた
  • 自分たちで使った(ドッグフード)
  • 使いにくいと感じたら、自分を信じて直した
  • なぜなら、自分たちが製品を一番よくわかっているから
  • (と信じていたから)

プログラマを信じた時代(結果)

  • ユーザから「使いにくい」「難しい」と言われた
  • 散々言われた

アジャイル開発を信じた時代

  • ユーザから、使いにくい部分、難しいと感じる部分を個別具体的に指摘してもらい
  • (ある程度)そしゃくした上で改善を続けた
  • 小さな改善を継続すれば、(部分最適化のリスクはあっても)今より悪くはならないと信じて直した

アジャイル開発を信じた時代(結果)

  • むしろ悪化?
  • 色々なユーザの意見を聞きすぎて機能過多?
  • (工数の都合で)古い操作方法が残ったりして、全体として一貫性がなくなった?
  • だんだん、個別意見が信じられなくなってきた
  • そのユーザ、本当に普通のユーザを代表してるの?

救世主の到来を信じた時代

  • 世の中にはUXデザイナという救世主がいるらしい
  • 採用に向けて、募集して面接した

救世主の到来を信じた時代(結果)

  • Webサイトのデザイナは大勢いても、WebアプリのUXデザイナは希少すぎて見つからない
  • いたとしても、その才能を見極める目がこちらにない

ユーザビリティテストを信じる時代

  • 救世主の到来は待ちつつも、今、できることをやりたい
  • 現実解としてのユーザビリティテスト

ユーザビリティテストの教養

ISO/IEC 9241-11

  • ISO/IEC 9241-11 (1998) Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11 : Guidance on usability
  • 古典
  • エルゴノミクス: 「人間工学」と訳される
  • 位置づけの参考: http://www.usabilitynet.org/tools/r_international.htm
  • ISO/IEC 9241-11から学べること: 「ユーザビリティ」の用語を(とりあえず)定義した(CIFに合わせて後ページで解説)

CIF: Common Industry Format

  • ISO/IEC 25062:2006 Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Common Industry Format (CIF) for usability test reports

CIFの主なレポート項目

  • 製品概要とテスト目的
  • 被験者の一覧(性別、年齢、etc)
  • テスト環境
  • テストシナリオ
  • 結果
  • 分析

ISO/IEC 9241-11とCIF

ISO 9241-11のユーザビリティの定義:

  • Effectiveness + Efficiency + Satisfaction

CIFの評価方法例:

  • Effectiveness: タスクの成功率、エラー率、ヘルプやドキュメントの参照率
  • Efficiency: タスク完了までの時間
  • Satisfaction: アンケート

アンケート手法(参考)

リッカート尺度(Likert scale):提示された文に回答者がどの程度合意できるかを回答する

  1. 全く同意できない
  2. 同意できない
  3. どちらともいえない
  4. 同意できる
  5. 非常に同意できる

SD法(semantic differential scale):相対する意味の言葉を用意し、その間を何段階かに分けて回答する

ISO 13407

  • ISO 13407:1999 Human-centred design processes for interactive systems ISO/TR 16982:2002 Usability methods supporting human-centred design

ユーザビリティ評価手法

  • 思考発話プロトコル法
  • 共同作業による問題発見
  • 質問プロトコル
  • ロギングツール
  • 作業状況の自己申告
  • 写真による記録
  • NEM(Novice Expert ratio Method):設計者の操作時間を 1 とした場合に一般のユーザーの操作時間がその何倍になるかの比)
  • SUMI:Software Usability Measurement Inventor

ユーザビリティテストの実践

  1. とりあえずやってみた
  2. 課題と改善
  3. 残る課題

とりあえずやってみた

参加者:

  • モデレータ(ひとり)
  • 被験者(ひとり)
  • 観測者(複数)

手法:

  • 思考発話プロトコル法:ソフトをさわりながら被験者に何でも思ったことを口に出してもらう
  • 観測者は絶対に話してはいけない

とりあえずやってみて感じた課題

  • 被験者の緊張感をどうほぐすか
  • 人間の観測問題
  • 観測者のメモが間に合わない

改善

  • モデレータを女性にする
  • 「テスト」の用語を使わない
  • 撮影する(スマートフォン操作の撮影は大変ですが)
  • 最初に被験者に声出しの練習をさせる
  • 最初に被験者に自由にさわらせる時間を作る
  • インタビュースクリプトを事前に作成する(汎用的に作ったので改変自由で公開予定)
  • シナリオライターとモデレータを別の人にする(客観的にするため)

手順

  • step1.被験者に意図を伝える
  • step2.どんなアプリかを伝える
  • step3.ソフトをさわりながら声を出す練習をしてもらう
  • step4.個別指示を出してソフトを操作してもらう
  • step5.感想や意見の聴取(観測者も含めたフリーディスカッション)

残る課題

  • 人間の観測問題との闘い(たぶん解決不能。cf. ホーソン効果)
  • ソフトウェアを改善した後、同じ人で試すべき?

最後に

某CTOいわく「CTOの主責務は、仕事を作って誰かに引き渡すこと」

  • 継続してくれる人募集
  • (次回以降のありえるえりあ勉強会、UXに興味があるとコメントして参加してください)

関連文書:

  • 関連文書は見つからんがな

Comments are closed.