Transcript 第1回発表(5/12)
ユーザビリティに関する研究 2006MI005 青木宏幸 2006MI036 池田大樹 2006MI164 杉山雄弥 発表のシナリオ ・研究理由 ・ユーザビリティを考慮する必要性 ・ユーザビリティとは ・ユーザビリティを考慮したシステム開発をする上での問題点 ・ユーザ中心設計 ・ユーザ中心設計の基本プロセス ・今後の方向性 ・参考文献 研究理由 背景 現在、様々な物がシステム化され、私たちの暮らしは便利で快適になっている。 しかしその反面、ユーザビリティへの配慮が足りない事から便利なシステムを使い こなせていないユーザが存在する。ユビキタス社会の真の実現のためにはユーザ ビリティの向上が解決策の一つとして挙げられる。 エピソード 私の祖母が旅行の際に宿泊宿のホームページから予約を試みたが、そのペー ジの内容が見づらく予約をすることができなかった。結果、雑誌を買って電話し て予約をしました。 研究理由 私たちはそういったユーザが抱える問題をユーザビリティという観点に着目して 解決したいと考えました。そこでユーザビリティを向上させるためにはどういった 考え・手法が必要なのか、そもそもユーザビリティとは何なのかといったところか ら研究していき、実際の開発現場で活かしていきたいと考えました。 ユーザビリティを考慮する必要性 ユーザビリティを考慮しなくても 使いにくいだけで問題ないんじゃない？ 機能自体は動くわけだし‥‥ 開発者 このＷｅｂサイトすごく見づらいし使いづらい！！ 違うＷｅｂサイトを利用しよう‥‥ ユーザ システムの機能が正常に動くとしてもシステムを使うのはあくまでユーザであり、 そのユーザが使いづらくて不満を感じ、そのシステムを利用しなくなれば、 そのユーザにとってそのシステムは使用不可能であるといえる ユーザビリティの考慮はシステムを設計する上で必要不可欠である ユーザビリティ(Usability)とは 1998年にISO 9241が定義 特定のコンテキストにおいて、特定のユーザによって、ある製品が、特定の目標 を達成するために用いられる際の、効果、効率、ユーザの満足度の度合い。 効果(Effectiveness) ユーザが指定された目標を達成するうえでの正確性、完全性 効率（Efficiency） ユーザが目標を達成する際に、正確さと完全性に費やした資源 満足度(Satisfaction) 製品を使用する際の、不快感のなさ、および肯定的な態度 これらの３つの要素を全て満たしてこそ、 ユーザビリティが高い製品であるいえる ユーザビリティを考慮したシステムを 開発する上での問題点 ① 開発者はユーザビリティを＋αのポイントと考える傾向がある。 実際の開発現場ではユーザビリティを考慮する優先度は下がり、 ユーザの事を議論し尽くさずに開発が行われてしまう。 ② 開発者は設計する段階で自分の価値観、考えを元に勝手なユーザ像 を定義してしまいがちである。 ユーザの事を考えてシステムを設計したつもりでも ユーザのニーズと食い違っている可能性がある。 ③ 設計する際、一人一人ユーザに対する考え方にずれが生じる。 チームでの意見がまとまらない。結果、リーダーなどの意見が 通り、ユーザのニーズを探る話し合いができない。 ①ユーザビリティを第一に考える ②ユーザのニーズを確実にくみ取る ③ユーザを定義する 為の設計手法が必要である。 ユーザ中心設計（UCD） システム開発におけるユーザビリティの高いシステムを作る事を目的とした設計。 開発者がエンドユーザーのニーズを正しく理解する事ができる。 ウォーターフォールモデル ●要求分析 ●設計 ●開発 ●実装 ●テスト ●運用 ユーザ中心設計に沿った要求分析・設計のメリット ・品質、機能優先ではなくユーザビリティを第一に考えた 設計を行うため、ユーザビリティに十分な考慮ができる ・ユーザを定義する事ができる為、 チームでのミーティングが円滑に進む。 ・開発者のユーザに対する勝手な思い込みを 排除する事ができる ・正確に、ユーザのニーズを引き出す事ができる ユーザ中心設計の基本プロセス ウォーターフォールモデル ●要求分析 ● ユーザ調査 ユーザの利用状況の把握 （インタビューetc） ● ユーザニーズ分析 ユーザの潜在的ニーズの分析 （シナリオ、ペルソナ法etc） ● プロトタイプの作成 ユーザニーズ分析を元に、プロトタイプを 作成してユーザに利用してもらう （ペーパープロトタイプ、パワーポイントetc） ● ユーザビリティ評価 ユーザによるプロトタイプの評価 （インスペクション、ユーザテストetc） ●設計 ●開発 ●実装 ●テスト ●運用 ユーザビリティ評価の結果を上流工程にフィードバックし、プロセスを繰り返す UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ユーザの提案を当てにしてはいけない ・ユーザは遠回りして目標に達成しても気づかない ・問題点に気づいてもユーザは原因を正しく分析できない ユーザに提案されるのではなく、ユーザに提案し、 ユーザが気付いていないユーザのニーズをくみ取る必要がある ユーザに提案するためにはユーザの行動を分析する必要がある。 ユーザの提案：既にユーザ自身が分析したデータ ユーザの行動：また分析されていないデータ ＜調査方法＞ インタビュー フォーカスグループインタビュー コンテキスト調査法 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜調査方法＞ ・インタビュー ・１対１でユーザに質問する事 ・フォーカスグループインタビュー ・座談会形式のインタビューの事 ・調査目的に応じて、性別、年代経験、ライフスタイルなどで切り分けた グループを設定 ・6名程度の参加者＋司会者（モデレータ） ・2時間 ・議論の仮定を記録、分析する事でテーマに対する多面的見方ができる ・参加者の発言はユーザの意見にすぎない ・参加者は無意識に要点をまとめて話す ・参加者は無意識に話を誇張する（フォーカスグループインタビュー） ユーザの要約されてしまった意見、断片的な体験を聞く事はできる。 しかしユーザの行動を分析する事ができない UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 コンテキスト調査法 ・ユーザが師匠、インタビューアが弟子となり、師匠の体験を弟子に継承する方法 基本プロセス ①インタビューアはユーザに弟子入りする ②ユーザ（師匠）は仕事を見せながらインタビューア（弟子）に説明する ③インタビューア（弟子）は、不明な点があればその場でどんどん質問する ④ひと通り話を聞いたら、インタビューア（弟子）は理解した内容を ユーザ（師匠）に話して、間違っていないかどうかチェックしてもらう 要約された結論だけでなく、ユーザの体験を順次立てて説明させる事ができる ユーザの行動を分析し、利用状況を把握する事ができる 《大原則》現場に行って話を聞く事 しかし インタフェース設計のプロジェクトで訪問調査はあまり実施できない そこで役に立つのが・・ コンテキストインタビュー UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ペルソナ法とは ペルソナ(persona)の目標を満足させるシステムを設計させる手法 ペルソナ：本物の人の代りとして作られる仮想ユーザの事 メリット 従来 設計者が考えるユーザの定義がばらばらな為、話をしても水かけ論になってしまう 設計者が勝手なユーザ像を想像してしまう ペルソナ法 ペルソナを作り、話をする事で、ユーザを定義する事ができる為、 設計者がユーザについて語る共通言語を作り上げる事ができる プロダクトチームの協調性を高める事ができる ユーザのニーズに合った製品を作る事ができる UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ペルソナの作り方、使い方 ①1対1のインタビュー調査を実施する ②同じような目標、ニーズをもっているユーザをグループ化する ③ユーザのグループごとに代表的なユーザ像を定義する ④それぞれのユーザ像に“もっともらしい”個人情報を付加する ⑤ペルソナに優先順位をつけて、最も優先度の高い主要ペルソナを明らかにする ・設計チームはこの主要ペルソナの要求を満たすことを目標として インタフェースを設計する。 ・他のペルソナの要求は主要ペルソナ程重視されない。 ・目標としないユーザである負のペルソナを設定するプロジェクトもある。 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 シナリオ法 シナリオとはユーザーを主体とした、システムや製品を使用に 関するエピソード。 シナリオの記述例 ･ユーザーのプロフィール ･システムや製品の使用環境 ･目的を達成するまでにシステムや製品の使用するためのプロセスと その結果 メリット (ユーザーの体験談をシナリオにすることで) 箇条書きとは違い、一連のプロセスを詳細に記述することがで きるため、コンテキストを失わない。 シナリオでは主語や目的語が明確であるため、読み手によって 解釈が異なることがなくなる。 物語で書かれたシナリオであるため、だれでも理解できる。 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 シナリオ分析 シナリオを分解し分析することで、シナリオを偏るこ となく網羅的に、シナリオのどの部分も同じような詳 細で分析することができる。 分解する シナリオを文脈に沿って段落やセンテンス単位に 分解する 分析する 段落やセンテンスからユーザーが何を要求し ているのかを分析する 検討する ユーザーの要求を満たすための妥当な解決 案を検討する UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 メリット シナリオを分析することで、ユーザーの意見に左右され ることなく、ユーザーの要求を見つけ、解決案を導くこ とができる。→ユーザーはシステムに関しては『素人』で あるためユーザーの意見を利用する必要はない。 プロトタイプのテスト結果が芳しくなかった場合、シナ リオまで戻り、解決案を策定した過程を再検証すること で、どこでユーザーを誤認したのかを追及することがで きる。 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ユーザ調査とユーザ分析から得た情報を元にプロトタイプ（試作品）を作成する プロトタイプ 本物のインタフェースとの近似度によって分けられる ・ローファイ（大ざっぱ） ・ハイファイ（本物そっくり） ハイファイなプロトタイプの方が当然ユーザが試しやすい しかしハイファイなプロトタイプを作るには多大な時間とコストがかかる よって一般的には、ローファイなプロトタイプが推奨されている でもローファイなプロトタイプではユーザは見づらいのでは？ それではユーザからの評価は曖昧なままではないのか？ UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ 紙に手書きで 作成したもの ユーザビリティ評価 NISEについて | 新着情報 | メンバ | 研究活動 | 年次研究リポート | 論文・著作 | 学会活動 | 共同研究プロジェクト | ソフトウェア工学コンソーシアム | 講義 | 所在地･交通・問い合わせ | 航空とIT技術 | 旅の記憶 | リンク | English >> パーソナルコンピュータとインターネットの急速な発展，普及に伴い，ソフト ウェアも身近で日常的になってきました．今や，至る所にソフトウェアが働いて い るといっても過言ではないでしょう．さらに，今後，ソフトウェアに対する需要 は質量ともに高まると思われます．また，ハードウェアのコストダウンに伴い， ソフトウェアの飛躍的なコストダウンも求められると思われます． これまで，ソフトウェア開発の生産性や品質を向上するために多大な研究開 発が行われ，様々な分野で成果を挙げてきました．しかし，ソフトウェア開発は 依然として人手に頼っており，生産性，品質，開発期間などの面で多くの改善 を必要としています． NISE(Network Information and Software Engineering)はこのようなソフトウェア 工学の課題を，ネットワーク，情報，ソフトウェア工学の融合体としてとらえ，私 たちの生活とソフトウェ ア技術のあり方を考えます． 研究室のご紹介 ＨＴＭＬによっ て作成された ホームページ NISE(青山研究室)を志望する学生へ[2008年10月:研究室紹介プレゼンテーショ ン(1.4MB)] NISEのご紹介[2008年4月: PDF(700KB)] 隣の研究室 第5回 「NISEチャレンジ！」(PDF 750KB) 学生誌「スラパラ」2006年7 月寄稿 らぼなびの紹介(2006年12月) 主な研究テーマ[詳細は研究活動のページをご覧下さい] ペルソナを中心とするユーザ指向要求工学 サービス指向アーキテクチャ(SOA)とサービス指向ソフトウェア工学(SOSE) 組込みソフトウェア工学と自動車ソフトウェア工学 ソフトウェア進化工学 Team NISE ローファイ ハイファイ UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ローファイなプロトタイプ≠全てが大ざっぱ 全体を大ざっぱに作るのではなくユーザが目的を達成するために 必要最低限のインタフェースに絞って作る事である その考え方として‥‥ Tプロトタイプという考え方がある 水平プロトタイプ Webページのトップページと第一 層のページだけを用意する。 実際にその機能は利用できない 垂直プロトタイプ Webページのトップページとそこか ら特定の機能をもったプロトタイプ だけを用意する UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜ユーザビリティを評価するための代表的な方法＞ ①ヒューリスティック評価法 専門家が経験してきた法則によってインタフェースを評価し、 ユーザビリティの問題点を見つける手法 ②ユーザテスト 被験者がタスクを達成する過程を観察し、 被験者の行動、言動からインタフェース上の問題点を見つける手法 ③ガイドラインレビュー これまで得られた知見に基づき、作成されたリストに従って設計仕 様上の問題点を抽出する手法 ④インスペクション法 操作仕様書や紙プロトタイプを使いながら その使い勝手を検証することにより、問題点を把握し、改善策探る手法 ⑤観察 ユーザを訪問し、邪魔をしないように自然に観察する手法 ⑥アンケート あらかじめ質問事項を用意し、被験者にアンケート形式で調査する手法 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜ヒューリスティック評価法＞ ヤコブ・ニールセン博士が数多くのユーザビリティの問題を分析して、 その問題の背後に潜在する原則を10ヒューリスティックとして抽出した この10ヒューリスティックを反していないか見つける手法 ①システム状態の可視性 システムは常に、妥当な時間内に適切なフィードバックを提供し、 今何をしているのかユーザに知らせる必要がある ②システムと実世界の調和 システムは、システム志向の言葉ではなく、ユーザが普段から目にし たり、使うような言葉で話さなければならない ③ユーザコントールと自由度 ユーザがシステムの機能を間違えたときに、 その不測の状態から抜け出すための明確な非常出口を必要とする UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ④一貫性と標準化 異なる言語、状況、行動が同じ事を意味するかどうか、 ユーザが疑問を感じるような環境を作るべきではない ⑤エラーの防止 ユーザが問題を起こす前に、問題の発生 を防止することが重要である ⑥記憶しなくても、見ればわかるように オブジェクト、動作、オプションを可視化する ユーザが次の動作に移る際に、前の動作での情報を 記憶しなくてもいいような環境をつくる ⑦柔軟性と効率性 ショートカット機能やカスタマイズ機能のようなアクセラレータ 機能は上級ユーザのタスク終了速度を上げる ユーザが頻繁に利用する動作は独自に調整できるようにする UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ⑧美的で最小限のデザイン 関連のない情報やめったに必要としない情報を含めるべきではない 余分な情報は関連する情報と競合して、相対的に視認性を減少さ せる ⑨ユーザによるエラー認識、診断、回復をサポートする エラーメッセージは簡単な言葉で表現し、 問題を的確に指し示し、現実的な解決策を提案しなければならない ⑩ヘルプとマニュアル マニュアルやヘルプをユーザの作業の焦点に当てた内容で 具体的に提示して提供することで、簡単にすべきである これら10項目を反していないかで問題点を抽出する 今後の方向性 ・ユーザ中心設計についての研究 （各プロセスについて詳しく調べる） ・実際にユーザ中心設計に沿った設計を行う （ユーザ調査、ユーザニーズ分析、プロトタイプ作成、ユーザ評価） ・新しい手法の提案 ・現在存在する問題点の発見、解決案の提案 参考文献 ・ユーザビリティエンジニアリング ユーザ調査とユーザビリティ評価実践テクニック 樽本徹也（著） ・ペルソナ戦略 マーケティング、製品開発、デザインを顧客志向にする ジョン・S,プルーイット（著） ・ペルソナ作ってそれからどうする？