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

Slides:



Advertisements
Similar presentations
CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ!」: teamB 要求定義をどう捉えるか ● 要求定義とは何か? 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。
Advertisements

応募方法 STEP_1 新規事業提案シー ト 作成 所定のシート (P.4-P.9) を利用し、新規事業提案シートを作成してください。 適宜 P.10 以降の記入方法補足を参照してください。 STEP_2応募申込み 下記の応募申込フォーム URL より所定項目入力の上、ご応募してください。 ※共同(チーム)提案の場合は、代表者の方のみご応募ください。
システム開発におけるユーザ要求の 明示的表現に関する一検討
プロジェクトとは.
「家族」 モバイル部門 企画書 テーマ タイトル 校名 グループ名 [文書のタイトルを入力してください] [学校名] モバイル部門の概要
本日のスケジュール 14:45~15:30 テキストの講義 15:30~16:15 設計レビュー 16:15~16:30 休憩
東京工科大学 コンピュータサイエンス 亀田弘之
   Webサイトの       ROIについて 理工学部 情報学科 吉田 克己.
機能実現期間の測定による プログラマ能力の実験的評価
OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月)  場所: 本社5階.
1日目 10:25 【演習】 情報の収集とチームプレイの基本 -オリエンテーション- 松本 亜希子 障害者支援施設 虹の家.
Ⅱ 訪問介護サービス提供プロセスの理解 Ⅱ 訪問介護サービス提供プロセスの理解.
神戸大学大学院国際文化学研究科 外国語教育論講座外国語教育コンテンツ論コース 神戸 花子
ユーザインタフェース 情報システム学科 島川 博光.
 授業を設計する(その4) 情報科教育法 後期5回 2004/11/6 太田 剛.
4.「血液透析看護共通転院サマリーVer.2」 の説明
経営学部 キャリアマネジメント学科 宮前 駿史
ビジネスパターンに基づく クラウドシステムのサービスレベル設計
「ICT社会におけるコミュニケーション力の育成」 研修モジュール C-1:パネルディスカッション
ヒューマンインターフェース ~ウェブサイト評価~
Designing for Behavior Change
卒業論文 最終発表 WWW情報検索 ナビゲーションシステムの設計と実装
Ⅲ.サービス開発の方法.
卒業研究 先輩の経験談に基づいた就職活動の目標管理方法
【会議の進め方】会議の定義:問題を解決する場であり情報を共有する場ではない 作成:増永寛之
「教育工学をはじめよう」  第2章     学会発表に向けて     プロポーザルを書く 発表 菊池 陵  皂 智樹.
~企画~ GO,桑田,ヒルズ.
ユースケース オブジェクト指向の要求分析のためのモデル。 スウェーデンのイヴァー・ヤコブソンが1990年代前半に開発。
「21世紀型コミュニケーション力の育成」研修モジュール
患者とかかわる際に 行うこと・行わないことの指針
スライド資料 C4 ICT機器を活用した授業づくり ④特別支援学校における ICT活用 兵庫教育大学の小川です。一応作者です。
Chapter7 constructing the environment
高等学校(工業) 工業高校におけるキャリア教育 品質管理とは 品質管理の意味を説明することを伝える.
卒論の書き方: 参考文献について 2017年9月27日 小尻智子.
WEBアプリケーションの開発 2002年度春学期 大岩研究会2.
「元気な社会」 モバイル部門 企画書 テーマ タイトル 校名 グループ名 [文書のタイトルを入力してください] [学校名]
~新たなソフトウェア開発の手法~ 発表 土屋俊介
ユーザ・インタフェース 小テスト 第5回.
平成19年度青年部会「第2回~第4回研修会」(人材育成研修会)実施計画書
「人生100年時代」に求められるスキル 【OS】 【アプリ】 人生100年時代の働き手は、【アプリ】と【OS】を
第151回 リフレクションの簡素化-ゲーミフィケーション的な感じで-(仮)
All Rights Reserved, Copyright © 2004, Kobayashi
シリーズ:著者の回答  質問 (韓国 K社、L.Y氏 開発・設計 )
シナリオを用いたレビュー手法PBRの追証実験 - UMLで記述された設計仕様書を対象として -
早稲田大学大学院 基幹理工学研究科 情報理工学専攻 後藤研究室 修士1年 魏 元
生活支援 中央研修 H26.9.4(木)~5(金) 品川フロントビル会議室 H26.9.6(土)~7(日) JA共済ビルカンファレンスホール
Virtualizing a Multiprocessor Machine on a Network of Computers
第一回 情報セキュリティ 05A1027 後藤航太.
生産性向上 現場のビデオ映像 OTRSは現場映像から、各種シミュレーションを提供し、組織の生産性向上をサポートしています。
1業務の実施方針等に関する事項 【1.1調査内容の妥当性、独創性】
プロジェクト演習 知能情報学部 新田直也.
本日のスケジュール 14:45~15:30 講義 15:30~16:15 企画書レビューシート記入 16:15~16:30 休憩
人を幸せにするアプリケーションの開発 2004年度春学期 大岩研究プロジェクト2 2004年4月8日(木) 発表:武田林太郎.
企業システム戦略を成功させる! ドキュメント・レビュー実践法 企業システム戦略家 青島 弘幸.
資料提出の際には本ページを削除してください。 プレゼンテーション、およびプレゼンテーション資料に関する注意点
1日目 10:25 テキストp.◯ 【演習】 情報の収集とチームプレイの基本 -オリエンテーション- 松本 亜希子 障害者支援施設 虹の家.
製品またはサービスの販売 サブタイトル.
演習1に関する講評 ~ 業務仕様を書く難しさ ~
自然言語処理2015 Natural Language Processing 2015
データ中心システム設計方法論“DATARUN” 
平成31年度 自動運転技術を活用したビジネスモデルの構築に関するプロジェクト 企画提案書
チームワークによる成功 第二副地区ガバナー研修.
マーケティング.
プログラムの一時停止時に 将来の実行情報を提供するデバッガ
テクニカル・ライティング 第4回 ~文章の設計法「KJ法」について~.
情報処理の概念 #0 概説 / 2002 (秋) 一般教育研究センター 安田豊.
一問一答式クイズAQuAsにおける学習支援の方法
オブジェクト指向メトリクスを用いた 開発支援に関する研究 --- VC++とMFCを用いた開発を対象として ---
第6分科会 商品コンセプト開発の研究 要旨 2013年度テーマ 商品開発手法「キーニーズ法」(ニーズアプローチ)の有効性検証 1.研究の目的
顧客志向〇〇セミナーに参加して 吉川智也・2018年〇〇月〇〇日(○曜日).
Presentation transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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