ユーザビリティに関する研究 2006MI005 青木宏幸 2006MI036 池田大樹 2006MI164 杉山雄弥

Presentation on theme: "ユーザビリティに関する研究 2006MI005 青木宏幸 2006MI036 池田大樹 2006MI164 杉山雄弥"— Presentation transcript:

1 ユーザビリティに関する研究 2006MI005 青木宏幸 2006MI036 池田大樹 2006MI164 杉山雄弥
ユーザビリティと開発効率の向上 2006MI005 青木宏幸 2006MI036 池田大樹 2006MI164 杉山雄弥

2 発表のシナリオ ・研究理由 ・ユーザビリティを考慮する必要性 ・ユーザビリティとは ・ユーザビリティを考慮したシステム開発をする上での問題点
・ユーザ中心設計 ・ユーザ中心設計の基本プロセス ・今後の方向性 ・参考文献

3 研究理由 背景 現在、様々な物がシステム化され、私たちの暮らしは便利で快適になっている。
しかしその反面、ユーザビリティへの配慮が足りない事から便利なシステムを使いこなせていないユーザが存在する。ユビキタス社会の真の実現のためにはユーザビリティの向上が解決策の一つとして挙げられる。　　　　　　　　　　　　 背景 エピソード 私の祖母が旅行の際に宿泊宿のホームページから予約を試みたが、そのページの内容が見づらく予約をすることができなかった。結果、雑誌を買って電話して予約をしました。　　　　　　 Ｗｅｂページのインタフェースに問題があるのでは？ 研究理由 私たちはそういったユーザが抱える問題をユーザビリティという観点に着目して解決したいと考えました。そこでユーザビリティを向上させるためにはどういった考え・手法が必要なのか、そもそもユーザビリティとは何なのかといったところから研究していき、実際の開発現場で活かしていきたいと考えました。

4 ユーザビリティを考慮する必要性 ユーザビリティを考慮しなくても 使いにくいだけで問題ないんじゃない？機能自体は動くわけだし‥‥
開発者 　このＷｅｂサイトすごく見づらいし使いづらい！！ 　違うＷｅｂサイトを利用しよう‥‥ ユーザ システムの機能が正常に動くとしてもシステムを使うのはあくまでユーザであり、そのユーザが使いづらくて不満を感じ、そのシステムを利用しなくなれば、 そのユーザにとってそのシステムは使用不可能であるといえる このようなユーザをなくすためには‥‥ ユーザビリティの考慮はシステムを設計する上で必要不可欠である

5 ユーザビリティ(Usability)とは
1998年にISO 9241が定義 特定のコンテキストにおいて、特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際の、効果、効率、ユーザの満足度の度合い。 効果(Effectiveness) 　　　ユーザが指定された目標を達成するうえでの正確性、完全性 効率（Efficiency） 　　　ユーザが目標を達成する際に、正確さと完全性に費やした資源 効果（効率、満足度）とは・・・です。 例えば・・・ つまり祖母にとってそのＷｅｂサイトは・・・だったといえます。 インターネット上？？→あるＨＰで 効率→目標を達成するために、費やした時間、労力の度合 満足度→いかに快適に利用できる 満足度(Satisfaction) 　　　製品を使用する際の、不快感のなさ、および肯定的な態度 これらの３つの要素を全て満たしてこそ、 ユーザビリティが高い製品であるいえる

6 ユーザビリティを考慮したシステムを開発する上での問題点
開発者はユーザビリティを＋αのポイントと考える傾向がある。 開発者は設計する段階で自分の価値観、考えを元に勝手なユーザ像を定義してしまいがちである。 設計する際、一人一人ユーザに対する考え方にずれが生じる。 ① ② ③ 実際の開発現場ではユーザビリティを考慮する優先度は下がり、 ユーザの事を議論し尽くさずに開発が行われてしまう。 ユーザの事を考えてシステムを設計したつもりでも ユーザのニーズと食い違っている可能性がある。 チームでの意見がまとまらない。結果、リーダーなどの意見が 通り、ユーザのニーズを探る話し合いができない。 問題点① 開発者は、限られたコスト、納期の中で、求められた機能、品質を作らなければならない為、 ＋αのポイントと考える。 問題点② 例）高齢者に対する認識のずれ→ユーザビリティに対する考慮が不十分になる。 ①ユーザビリティを第一に考える ②ユーザのニーズを確実にくみ取る ③ユーザを定義する 為の設計手法が必要である。

7 ユーザ中心設計（UCD） システム開発におけるユーザビリティの高いシステムを作る事を目的とした設計。
開発者がエンドユーザーのニーズを正しく理解する事ができる。 ウォーターフォールモデル ●要求分析 ●設計 ●開発 ●実装 ●テスト ●運用 ユーザ中心設計に沿った要求分析・設計のメリット ・品質、機能優先ではなくユーザビリティを第一に考えた 設計を行うため、ユーザビリティに十分な考慮ができる ・ユーザを定義する事ができる為、 　チームでのミーティングが円滑に進む。 ・開発者のユーザに対する勝手な思い込みを 　排除する事ができる ・正確に、ユーザのニーズを引き出す事ができる ユーザ中心設計の考え方は開発工程の要求分析、設計のフェーズで活かされます。

8 ユーザ中心設計の基本プロセス ウォーターフォールモデル ● ユーザ調査 ユーザの利用状況の把握 （インタビューetc） ● ユーザニーズ分析
●　　ユーザ調査 　　　ユーザの利用状況の把握 　　　（インタビューetc） ●　 ユーザニーズ分析 　　　ユーザの潜在的ニーズの分析 　　　（シナリオ、ペルソナ法etc） ● プロトタイプの作成 　　　ユーザニーズ分析を元に、プロトタイプを 　　　作成してユーザに利用してもらう 　　　（ペーパープロトタイプ、パワーポイントetc） ● ユーザビリティ評価 　　　ユーザによるプロトタイプの評価 　　　（インスペクション、ユーザテストetc） ●要求分析 ●設計 ●開発 ●実装 ●テスト ●運用 評価によって明らかになった問題点を上流工程にフィードバックし、 ユーザのニーズを引き出した設計ができるまで繰り返します。 ユーザビリティ評価の結果を上流工程にフィードバックし、プロセスを繰り返す

9 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ユーザの提案を当てにしてはいけない
・ユーザは遠回りして目標に達成しても気づかない ・問題点に気づいてもユーザは原因を正しく分析できない ユーザに提案されるのではなく、ユーザに提案し、 ユーザが気付いていないユーザのニーズをくみ取る必要がある ユーザに提案するためにはユーザの行動を分析する必要がある。 ユーザの提案：既にユーザ自身が分析したデータ ユーザの行動：また分析されていないデータ　 調査というと、どういったインタフェース、デザインにしてほしいかをユーザに、提案や意見を求めるイメージがあるかもしれませんが 調査方法として、３つのインタビュー方法を紹介します。 ＜調査方法＞ インタビュー フォーカスグループインタビュー コンテキスト調査法

10 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜調査方法＞ ・インタビュー
・１対１でユーザに質問する事 ・座談会形式のインタビューの事 ・調査目的に応じて、性別、年代経験、ライフスタイルなどで切り分けた グループを設定 ・6名程度の参加者＋司会者（モデレータ） ・2時間 ・議論の仮定を記録、分析する事でテーマに対する多面的見方ができる ・フォーカスグループインタビュー そこで、コンテキスト調査法という方法を紹介したいと思います。 ・参加者の発言はユーザの意見にすぎない ・参加者は無意識に要点をまとめて話す ・参加者は無意識に話を誇張する（フォーカスグループインタビュー） ユーザの要約されてしまった意見、断片的な体験を聞く事はできる。 しかしユーザの行動を分析する事ができない

11 ユーザの行動を分析し、利用状況を把握する事ができる
UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 コンテキスト調査法 ・ユーザが師匠、インタビューアが弟子となり、師匠の体験を弟子に継承する方法 基本プロセス ①インタビューアはユーザに弟子入りする ②ユーザ（師匠）は仕事を見せながらインタビューア（弟子）に説明する ③インタビューア（弟子）は、不明な点があればその場でどんどん質問する ④ひと通り話を聞いたら、インタビューア（弟子）は理解した内容を ユーザ（師匠）に話して、間違っていないかどうかチェックしてもらう 要約された結論だけでなく、ユーザの体験を順次立てて説明させる事ができる ユーザの行動を分析し、利用状況を把握する事ができる 《大原則》現場に行って話を聞く事 しかし インタフェース設計のプロジェクトで訪問調査はあまり実施できない そこで役に立つのが・・　　コンテキストインタビュー

12 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ペルソナ法とは
ペルソナ(persona)の目標を満足させるシステムを設計させる手法 ペルソナ：本物の人の代りとして作られる仮想ユーザの事 メリット 従来 設計者が考えるユーザの定義がばらばらな為、話をしても水かけ論になってしまう 設計者が勝手なユーザ像を想像してしまう ペルソナ法 ペルソナを作り、話をする事で、ユーザを定義する事ができる為、 設計者がユーザについて語る共通言語を作り上げる事ができる プロダクトチームの協調性を高める事ができる ユーザのニーズに合った製品を作る事ができる

13 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ペルソナの作り方、使い方
①1対1のインタビュー調査を実施する ②同じような目標、ニーズをもっているユーザをグループ化する ③ユーザのグループごとに代表的なユーザ像を定義する ④それぞれのユーザ像に“もっともらしい”個人情報を付加する ②（3～7グループが標準） ③ユーザ像（ライフスタイル、ITスキル、製品利用の目的etc） ④個人情報（名前、年齢、性別、顔写真etc） ⑤ペルソナに優先順位をつけて、最も優先度の高い主要ペルソナを明らかにする ・設計チームはこの主要ペルソナの要求を満たすことを目標として 　インタフェースを設計する。 ・他のペルソナの要求は主要ペルソナ程重視されない。 ・目標としないユーザである負のペルソナを設定するプロジェクトもある。

14 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 シナリオ法
シナリオとはユーザーを主体とした、システムや製品を使用に 関するエピソード。 シナリオの記述例 ･ユーザーのプロフィール ･システムや製品の使用環境 ･目的を達成するまでにシステムや製品の使用するためのプロセスと その結果 メリット 池田 (ユーザーの体験談をシナリオにすることで) 箇条書きとは違い、一連のプロセスを詳細に記述することができるため、コンテキストを失わない。 シナリオでは主語や目的語が明確であるため、読み手によって解釈が異なることがなくなる。 物語で書かれたシナリオであるため、だれでも理解できる。

15 UCDの基本プロセス 分解する 分析する 検討する ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価
シナリオ分析 シナリオを分解し分析することで、シナリオを偏ることなく網羅的に、シナリオのどの部分も同じような詳細で分析することができる。 シナリオを文脈に沿って段落やセンテンス単位に 分解する 分解する 池田 段落やセンテンスからユーザーが何を要求しているのかを分析する 分析する 検討する ユーザーの要求を満たすための妥当な解決案を検討する

16 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 メリット
シナリオを分析することで、ユーザーの意見に左右されることなく、ユーザーの要求を見つけ、解決案を導くことができる。→ユーザーはシステムに関しては『素人』であるためユーザーの意見を利用する必要はない。 プロトタイプのテスト結果が芳しくなかった場合、シナリオまで戻り、解決案を策定した過程を再検証することで、どこでユーザーを誤認したのかを追及することができる。 池田

17 UCDの基本プロセス プロトタイプ ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価
ユーザ調査とユーザ分析から得た情報を元にプロトタイプ（試作品）を作成する プロトタイプ 本物のインタフェースとの近似度によって分けられる ・ローファイ（大ざっぱ） ・ハイファイ（本物そっくり） ハイファイなプロトタイプの方が当然ユーザが試しやすい しかしハイファイなプロトタイプを作るには多大な時間とコストがかかる 本物と程遠いインタフェース よって一般的には、ローファイなプロトタイプが推奨されている でもローファイなプロトタイプではユーザは見づらいのでは？ それではユーザからの評価は曖昧なままではないのか？

18 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 紙に手書きで作成したもの ＨＴＭＬによって作成されたホームページ 本物と程遠いインタフェース ローファイ ハイファイ

19 UCDの基本プロセス Tプロトタイプという考え方がある ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価
ローファイなプロトタイプ≠全てが大ざっぱ 全体を大ざっぱに作るのではなくユーザが目的を達成するために 必要最低限のインタフェースに絞って作る事である その考え方として‥‥ Tプロトタイプという考え方がある 水平プロトタイプ　　　　　　　　　　　　　　　　　　　垂直プロトタイプ　　　　　　 Ex)外観のデザインを比較するプロトタイプ Ex)ショッピングカートの機能を検証するプロトタイプ Webページのトップページと第一層のページだけを用意する。 実際にその機能は利用できない Webページのトップページとそこから特定の機能をもったプロトタイプだけを用意する

20 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜ユーザビリティを評価するための代表的な方法＞
①ヒューリスティック評価法 専門家が経験してきた法則によってインタフェースを評価し、 ユーザビリティの問題点を見つける手法 ②ユーザテスト 被験者がタスクを達成する過程を観察し、 被験者の行動、言動からインタフェース上の問題点を見つける手法 ③ガイドラインレビュー これまで得られた知見に基づき、作成されたリストに従って設計仕様上の問題点を抽出する手法 ④インスペクション法 操作仕様書や紙プロトタイプを使いながら その使い勝手を検証することにより、問題点を把握し、改善策探る手法 ⑤観察 ユーザを訪問し、邪魔をしないように自然に観察する手法 ⑥アンケート あらかじめ質問事項を用意し、被験者にアンケート形式で調査する手法

21 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ＜ヒューリスティック評価法＞
ヤコブ・ニールセン博士が数多くのユーザビリティの問題を分析して、 その問題の背後に潜在する原則を10ヒューリスティックとして抽出した この10ヒューリスティックを反していないか見つける手法 ①システム状態の可視性 システムは常に、妥当な時間内に適切なフィードバックを提供し、 今何をしているのかユーザに知らせる必要がある ②システムと実世界の調和 システムは、システム志向の言葉ではなく、ユーザが普段から目にしたり、使うような言葉で話さなければならない ③ユーザコントールと自由度 ユーザがシステムの機能を間違えたときに、 その不測の状態から抜け出すための明確な非常出口を必要とする

22 UCDの基本プロセス ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価 ④一貫性と標準化
異なる言語、状況、行動が同じ事を意味するかどうか、 ユーザが疑問を感じるような環境を作るべきではない ⑤エラーの防止 ユーザが問題を起こす前に、問題の発生を防止することが重要である ⑥記憶しなくても、見ればわかるように オブジェクト、動作、オプションを可視化する ユーザが次の動作に移る際に、前の動作での情報を記憶しなくてもいいような環境をつくる ⑦柔軟性と効率性 ショートカット機能やカスタマイズ機能のようなアクセラレータ機能は上級ユーザのタスク終了速度を上げる ユーザが頻繁に利用する動作は独自に調整できるようにする

23 UCDの基本プロセス これら10項目を反していないかで問題点を抽出する ユーザ調査 ユーザニーズ分析 プロトタイプ ユーザビリティ評価
⑧美的で最小限のデザイン 関連のない情報やめったに必要としない情報を含めるべきではない 余分な情報は関連する情報と競合して、相対的に視認性を減少させる ⑨ユーザによるエラー認識、診断、回復をサポートする エラーメッセージは簡単な言葉で表現し、 問題を的確に指し示し、現実的な解決策を提案しなければならない ⑩ヘルプとマニュアル マニュアルやヘルプをユーザの作業の焦点に当てた内容で具体的に提示して提供することで、簡単にすべきである これら10項目を反していないかで問題点を抽出する

24 今後の方向性 ・ユーザ中心設計についての研究 （各プロセスについて詳しく調べる） ・実際にユーザ中心設計に沿った設計を行う
　（各プロセスについて詳しく調べる） ・実際にユーザ中心設計に沿った設計を行う 　（ユーザ調査、ユーザニーズ分析、プロトタイプ作成、ユーザ評価） ・新しい手法の提案 ・現在存在する問題点の発見、解決案の提案

25 参考文献 ・ユーザビリティエンジニアリング ユーザ調査とユーザビリティ評価実践テクニック 樽本徹也（著） ・ペルソナ戦略
　ユーザ調査とユーザビリティ評価実践テクニック 　樽本徹也（著） ・ペルソナ戦略 　マーケティング、製品開発、デザインを顧客志向にする 　ジョン・S,プルーイット（著） ・ペルソナ作ってそれからどうする？