book cover You can get the Just Ask book from www.uiAccess.com/accessucd/print.html

Just Ask: デザインプロセスを通じて取り組むアクセシビリティ

「Just Ask: Integrating Accessibility Throughout Design」の一部スポンサー:

Adobe   hp logo (invent)   RNIB   MITSUE-LINKS

ユーザー中心設計におけるアクセシビリティ: ユーザビリティ・テストの計画

「アクセシビリティの評価 」のページでは、標準のレビュー、ヒューリスティック評価、設計ウォークスルー、および障害のあるユーザーによる非公式の評価を含め、アクセシビリティを一般的な評価方法に含めるためのガイダンスを示しています。ユーザビリティ・テストのセクションは、障害者が参加するユーザビリティ・テストの概要です。

ユーザビリティ・テストの計画に障害者を参加させる場合、次のことを考慮する必要があります。

参加者の特性の判断

「何人の障害者をユーザビリティ・テストに参加させるべきか？」、および「どのような特性を持つ人を参加させるべきか？」などの疑問点に対して、決まった答えはありません。状況によって異なるからです。本セクションでは、特定の状況においてこれらの疑問点の解決に役に立つ要因に関して説明します。

課題の理解

ユーザビリティ・テストに参加させるべき人数は、ユーザビリティの専門家の間で議論のテーマとなっています[1]。いくつかの研究では、数多くの参加者をテストに参加させても、最初の参加者がほとんどのユーザビリティの問題を発見するため、少人数の参加者によるテストよりも多くの情報を得られるとは限らないと結論付けています [2][3]。さらに、いくつかの研究では、製品をほぼ同じ方法で使用する同じようなユーザーがいれば、ユーザビリティの問題の85%を発見するためには5人の参加者で十分であることが示されています。複数の非常の異なるユーザーグループがいる場合は、他のユーザーでもテストする必要があります[4]。

製品の使用方法は、障害者によって異なります。したがって、徹底的なアクセシビリティのユーザビリティ・テストを行うためには、5人以上のユーザーが必要です。(次のセクションでは、参加する障害者が5人未満の場合のガイダンスを示しています。)異なる種類のユーザーグループがいる場合、1つの方法として、各グループから3人のユーザーを参加させる方法が薦められます[4]。しかし、障害者を、製品の使い方の観点から分類することは簡単ではありません。

慎重な分類

障害は、視覚障害、聴覚障害、身体障害、認知障害の4つに大きく分類されることがあります。しかし、各分類においても、さまざまな多様性があります。たとえば、視覚障害のある人の中には、生まれたときから視力が悪く、画面拡大表示ソフトウェアを使い慣れた中年の女性、網膜色素変性を患い最近になって完全に目が見えなくなり、スクリーン・リーダーを使い始めたばかりの若い男性、加齢黄斑変性症で視力が低下してきているが、支援技術を使用していない高齢の女性、まだ色覚障害と診断されていない男の子、といった人たちがいます。

各分類におけるこのような多様性は、製品の設計および評価において重要です。たとえば、視覚障害は通常一つに分類されていますが、同じ製品でも、目の見えない人にとっては使いやすくて役に立っても、視力が低下した人にとってはまったく使い勝手が悪く使い物にならないことがあり、その逆の場合もあります。

われわれは、以前、スクリーン・リーダーのユーザーにとっては素晴らしいWebサイトを評価しました。しかし、そのサイトは、視力が低下して、スクリーン・リーダー以外の適応手段を使用している人や、ある種の認知障害のある人にとっては、ひどいものでした。

製品の扱い方は、障害が先天性か後天性か、後天性でも発症が若いときか年を取ってからか、障害が一時的か恒久的か、症状が進行しているかいないかあるいは後退しているか、どのような適応手段や支援技術を本人が使用しているか、ということによって異なります。

各分類におけるこのような多様性により、障害を4つに分類するだけでは（視覚、聴覚、身体、認知)、ユーザビリティ・テスト参加者の特性の分類としては十分ではありません。

われわれは、インターネットユーザーに関する正式な研究の参加者をリクルートするために、失明についての定義を必要としていました。われわれは、トップクラスの視覚関連の研究所の専門家に尋ねたところ、世界保健機関(WHO)でも失明の定義に関する合意が得られていないという答が返ってきました。この専門家は、失明の定義ではなく、潜在的な参加者がどの支援技術を使用しているかに基づいて、参加者をリクルートすることを提案しました。この提案は、その研究、および視力が低下した人に関するその後の研究において、素晴らしいアドバイスであることが証明されました。われわれがリクルートした参加者の1人は、米国における失明の定義によると法律上目が見えない人と分類されていましたが、わずかに視力が残っており、通常、本人はスクリーン・リーダーではなく画面拡大表示ソフトウェアを使用していました。つまり、この参加者は、目の見えないユーザーに関する研究ではなく、画面拡大表示ソフトウェアを使用しているユーザーの研究の対象としてのほうが相応しいということです。

参加者の現実的な範囲の見極め

さまざまな障害を抱える人が参加し、徹底的なユーザビリティ・テストを実施するのに、十分な時間と資金のあるプロジェクトは稀です。特定のユーザビリティ・テストに参加させる障害者の数は、通常、プロジェクトの限られたリソースによって決まります。限られたリソースを最大限に活用し、どの参加者の特性をユーザビリティ・テストに含めるかに関しては、下記の点を考慮すると良いでしょう。

アクセシビリティとユーザビリティには重複する点があることを理解してください。参加させる障害者の数を決定する場合、障害のあるユーザーは、障害のないユーザーを含めたすべてのユーザーに影響を与える一般的なユーザビリティの問題に直面することを考慮してください。したがって、障害者が参加するユーザビリティ・テストでは、アクセシビリティの問題と一般的なユーザビリティの問題の両方を見極めます。多くの場合 一般的なユーザビリティの問題は、障害のある参加者によるテストにおいて増幅するため、すべてのユーザーに影響する問題を発見することが簡単になります。

障害のあるユーザーが一般的なユーザビリティにどのように対応しているかを説明することで、ユーザビリティ・テストおよびプロジェクト全体を通して障害のあるユーザーを参加させるため、より多くの時間と予算を確保するのに役に立つことがあります。

最初に、標準のレビュー、ヒューリスティック評価、設計ウォークスルー、およびスクリーニングテクニックを行います。最初に他の評価方法を実施することにより、障害者を参加させる前に解決できる多くのアクセシビリティの問題を発見することができます。また、他の評価方法を実施することは、実際の障害者が参加するテストで最も重要なことに集中する上でも役に立ちます。

スクリーニングテクニックを用いることが、障害者によるテストの有効な補足となる場合もあります。たとえば、誰でも携帯電話を片手で使用することが可能であり、そのために障害がなければならないということはありません。しかし、スクリーニングテクニックでは、いくつかの点において効果的な評価ができないこともあります。たとえば、スクリーン・リーダーの使用経験が少ない場合、製品を効果的に評価することはできないでしょう。

様々なユーザビリティ・テストに様々な特徴を含めるようにしてください。製品の設計では、ユーザビリティ・テストを数回繰り返すのが理想的です。場合によっては、あらゆる特性を代表する障害者をすべてのテストに参加させるのではなく、1回のテストに異なる特性の障害者を参加させることもできます。

対象ユーザーに的を絞ってください。対象ユーザーの中に、特定の障害を持つ人の割合が多くなる場合、関連する特性に的を絞ってください。たとえば、主に高齢者に販売する製品に関するユーザビリティ・テストには、年齢に関わる障害を持つ高齢者を参加させるべきであり、糖尿病に関する情報を含むWebサイトに関するテストには、視覚障害のある人を参加させるべきです。下記の重要な注意事項を参照してください。

影響が最大となることに的を絞ってください。製品の中には、他の障害と比較して、特定の障害を持つ人への影響が大きいものがあります。製品の性質や状況によっては、特定の特徴を持つ障害者を参加させる必要はないかもしれません。たとえば、音声を発しない製品を設計する場合、難聴の参加者を積極的にリクルートすることはしないでしょう。また、イントラネット(社内のWebサイト)を設計していて、会社の基準が特定のスクリーン・リーダーに決められている場合、他のスクリーン・リーダーを使用する参加者を含めることはないと思われます。下記の重要な注意事項を参照してください。

重要な注意事項

「分析段階」の章の「個々人の違い」で説明したように、1人の参加者がすべての人を代表しているという落とし穴に陥らないでください。

障害者はある製品を使用できない、あるいは使用しない、といった推測は避けてください。たとえば、目の見えない人について、ドライブスルーのATMを使用しない、インターネットで自動車を検索しないあるいはナンバープレートを更新するためにキオスクを使用しないなどと決め込まないでください。目の見えない人は、運転しなくても、空港までタクシーに乗っていてドライブスルーのATMを使用したいことがあるでしょうし、もうすぐ大学を卒業する子供への贈り物としてインターネットで車を検索したいこともあるでしょうし、車を運転する配偶者と共同で登録しているナンバープレートを更新するためにキオスクを使用することもあるでしょう。この注意点の詳細に関しては、ユーザーグループのプロフィールの「ユーザーグループのプロフィールに関するアクセシビリティへの配慮」のセクションを参照してください。

私のある友人は、目が見えませんが、運転免許を取得する手続きに関して娘と話をするために、オーストラリアの交通局のWebサイトでその要件を調べたいと思っていました。

支援技術(AT)

支援技術(AT)は、参加者の特性の判断、特にソフトウェアおよびWeb製品の場合に、大きく異なります。異なる支援技術は、製品により動作が異なる場合があります。たとえば、スクリーン・リーダーが異なれば、同じアプリケーションでも動作が異なります。したがって、通常、評価には、複数のスクリーン・リーダー、および同じスクリーン・リーダーの複数のバージョンを含めることがベストです。

支援技術の中には、複雑で学ぶのが難しいものがあり、特定のATに関する参加者の経験とスキルがユーザビリティ・テストに影響します。十分なスキルがないユーザーは、ATを効果的に使用する方法を知らないため、テストする製品を使用するのではなく、ATの使い方で悩んで多くの時間を費やすこともあります。また、発見された問題は、製品の欠陥ではなく、参加者がATを効果的に使用できないために生じたという可能性もあります。逆に、ATを使い慣れたユーザーは、平均的なユーザーが対処できない問題を克服するための一般的でない回避策を知っている可能性もあります。

あるケースでは、非常に知識の豊富なスクリーン・リーダーのユーザーが、WebページのHTMLのコードをチェックして、アクセシビリティの障壁を回避する、ということがありました。

どのユーザー評価でもそうですが、初心者、平均的なユーザー、上級ユーザーのいずれかを参加させるかは、対象とするユーザーによって決まります。たとえば、社内の会計士が使用するアプリケーションを開発している場合では、上級のATユーザーが望ましいかもしれません。また、障害者給付の申請に用いる公的なWebサイトであれば、初心者のATユーザーの参加が望まれるでしょう。ほとんどのユーザビリティ・テストにおいては、中級から上級のATスキルを持つユーザーを参加させてください。潜在的な参加者の支援技術に対する体験とスキルのレベルを判断するための質問に関しては、本資料の末尾近くの「参加者のリクルート条件」に記載しています。

われわれが経験豊富であると判断したあるユーザーは、確かに長期間使用してはいますが、使用する機能は限られていることが後で分かったこともありました。このような場合では、それ自体が役に立つテストケースとなる可能性もありますが、われわれの場合は、既に十分な数の初心者ユーザーをリクルートしていたので、そうではありませんでした。現在、われわれは、経験ではなく、技能レベルに基づいてリクルートしていますが、それでも、ユーザーが自分のスキルを過大評価しているのをよく見受けます。

障害を持つ参加者のリクルート

ユーザビリティスペシャリストは、障害者のリクルートが難しいと考えていることが多いですが、ちょっと努力すればかなり簡単であることが分かります。

追加リクルートの準備。どのユーザビリティ・テストでも、参加者の要件が具体的であればあるほど、リクルートに時間がかかります。たとえば、Macを使用する35～55歳の医師をリクルートする場合、参加者の要件が単に35～55歳の人である場合よりも時間がかかります。同じことは、障害者のリクルートにも言えます。障害の種類や支援技術の使用など、特定の参加者の要件を追加する場合、リクルートにさらに時間と労力がかかる傾向にあります。

逆に、リクルート活動は、障害者のコミュニティ内の「口コミマーケティング」により、通常よりも短い時間で済むこともあります。

他の人と比較して、より多くの障害者が、より素早く、そしてより粘り強く募集広告に反応してきました。われわれは、一般に障害者は、特に製品をアクセシブルにするための研究には、積極的に参加したいと考えていることを発見しました。また、多くの障害者が失業状態であるため、標準的な謝礼金を出したことが誘引にもなったようです。

要となるコンタクト先を確保してください。障害のある参加者を見つける場所として、下記の場所が挙げられます。

「障害者組織」をインターネットで検索すると、複数のリストへのリンクが見つかります。近くの組織を検索する場合は、国、州、あるいは場所を指定してください。

組織によっては、ニュースレターやメールリストを配信しているところもあり、それを利用して募集広告を送信することができます。

ある障害者組織は、すべてのメンバーにeメールを送信し、われわれのリクルート条件を満たす人に私へ連絡するように頼んでくれました。

多くの国内および国際的な組織は、現地の参加者を支援するために地域の連絡先を用意しています。

われわれは、障害者組織の連絡先に対して、自分たちの活動に関して簡単に説明する場合、通常は非常に積極的な対応を受け、それがリクルートに役に立ちます。また、われわれが、障害者の研究参加を始めた当初、「研究に参加する人に快適に感じてもらうのに何か提案はありませんか」と質問したことで、非常に役立つヒントが得られました。

組織内で協力してくれる人が見つかると、多くの時間を節約することができます。

私は、近くのある高齢者センターのサービスコーディネータに連絡して、プロジェクトに関して話をしました。彼女からは積極的な協力が得られ、われわれが探している特性を持つ参加者となりそうな人を推薦してくれました。彼女の協力で、リクルートのための多くの時間と労力を節約することができました。

パイロットテストはリクルートツールと捉えてください。障害者の中には、積極的にアプリケーションの情報を配布しているネットワークに参加している人もいます。ユーザビリティ・テストの実際の参加者の肯定的な意見は口コミですぐに広がり、参加者となりうる人が連絡してくれることがあります。

われわれは、ある研究において、工科大学の障害のある学生向けプログラムから参加者をリクルートしました。われわれは、初日に障害のある学生と2つのテストを実行しました。翌日、さらに2つの予定されたテストを実行するために再度大学を訪れたときには、その話が既に広がっていて、さらに12人の障害のある学生が、参加を希望して並んでいました。

この口コミの募集活動をうまく活かすためには、募集活動の最初の段階でパイロットテストを実施することを検討し、学生組織、高齢者センター、あるいは障害者サポートグループなど、広く尊敬を集め積極的に発言しているコミュニティメンバーを参加者として探してください。リクルート活動をしていることを口コミで伝えるようにお願いしてください。

関連情報を参加者のリクルート条件に追加してください。ユーザビリティ・テストに参加する障害者をリクルートする場合、障害者でない参加者をリクルートする場合と同じパラメータを使用してください。参加者のリクルートにおいて網羅すべき追加情報として、技術の使用、印刷資料の代替フォーマットなどがあります。リクルート条件に追加すべき具体的な質問に関しては、「参加者のリクルート条件」のセクションに示しています。

必要に応じて通訳を手配してください。耳の聞こえない人をユーザビリティ・テストに参加させる場合、一般的には、手話通訳者を探して、手配し、料金を支払います。(身体障害者に個人的な付添い人がいる場合は異なります。その場合は、付添い人が手配を行ってくれます)。

参加者に必要な経費を払い戻してください。障害者に対する基本的な謝礼金は、他の参加者と同じですが、追加コストを考慮しなければならないことがあります。障害のある参加者の場合、交通手段がより複雑でコストがかかる場合があります。通常、アクセシブルなバン型タクシーなどの追加交通費は、払い戻さなければなりません。

参加者によっては、その個人的な付添い人や通訳の時間に対して料金を支払わなければならないことがあります。リクルートプロセスの一環として、参加者の経費について調査し、何について払い戻しをするかについて参加者へ確認してください。

われわれは、最寄りの公共交通機関の停車場所とわれわれのオフィス間の参加者の移動のために、ある法人タクシーサービスを手配しました。そして、参加者が安全かつ快適に移動できるようにタクシー会社と協力しました。

最適な場所の選択

ユーザビリティ・テストは、ユーザビリティ・テスト・ルームで行う場合でも、参加者の職場や自宅やその他の場所など「現場」で行う場合でも、それぞれ長所と短所があります。進行役と参加者が別の場所にいる場合は遠隔評価を用いる人もいます。障害者に参加してもらってユーザビリティ・テストを行う場合、場所を決定するために考慮すべき追加要因があります。

ユーザビリティ・テストの目標を考慮すること。どの場所が最良であるかは、テストの目標および潜在的な利点により決まります。

ほとんどの設計者は、障害者がどのように製品を使用するかを知らず、多くが障害者に囲まれると気詰まりに感じます。ユーザビリティ・テストは、「障害者によるプロジェクトへの参加」の章で説明したように、そのような状況を変える素晴らしい方法です。
自分のテストルームでユーザビリティ・テストを行う場合は、プロジェクトチームのメンバーの多くにとって、セッションを観察し、セッションを記録する機会となります。設計者と参加者間の非公式の対話セッションは、特に役に立ち、正式なテストルームで行う場合と異なり、プロジェクトチームにとって最も便利な場所で行うことができます。

われわれのプロジェクトマネージャーは、障害者参加のユーザビリティ・テストを許可してくれましたが、その価値に関しては納得していませんでした。われわれは、彼女に、セッションのいくつかを観察してもらいたいと思い、彼女にとって便利な場所でセッションを実施しました。

チームが数人規模で、障害者が自らの環境においてどのように製品を使用しているかに関して詳しく学ぶことが目標であれば、現場でのテストがベストです。

対面での対話を行いたい場合、遠隔評価は選択肢となりません。また、遠隔評価は、本人立会いのユーザビリティ・テストと同等の結果は得られません。しかし、遠隔評価が最適となるケースもあります。たとえば、既にアクセシビリティの評価に関して本人との関係が十分築かれている場合、同じ場所まで移動しなくても、一部の評価を遠隔で行っても同等の効果が得られ、そのほうがはるかに簡単なことがあります。

われわれは、何度も仕事を共にしたことのあるスクリーン・リーダーを使い慣れたユーザーと遠隔評価を調整しました。われわれが彼の画面を見るために、彼は自らを「ミーティング・マネージャー」として指定する必要がありました。しかし、ソフトウェアのその部分にアクセシビリティがありませんでした。つまり、スクリーン・リーダーが、その部分を認識することがまったくできなかったのです。ソフトウェアにはキーボードのショートカットがあったため、そのセットアップ方法を伝えることができました。このセットアップが終わった後、他のインターフェースはスクリーン・リーダーを通して使用することができました。その後は、われわれの組織の誰もがログオンして、彼の画面を見て、彼の側にある標準のスピーカーおよびわれわれの側の電話会議ブリッジを使用して、彼の声およびスクリーン・リーダーを聞くことができました。

支援技術のニーズを考慮してください。支援技術は、ユーザビリティ・テストの実施場所を決める重要な要因の1つです。

必要な支援技術をテストルームに持ち込むことは、コストがかかり、複雑で、多くの時間を要することがあります。ソフトウェアやWebベースの製品をテストする場合、参加者によっては、構成もバージョンも異なる支援技術を必要とすることがあります。参加者間でシステム構成を変更することは、難しい場合があります。

ITスペシャリスト、リハビリテーション・スペシャリスト、あるいは家族のメンバーが、支援技術を含め、障害者の自宅やオフィスのコンピュータ・システムを設定するのが一般的です。支援技術の中には、多くの設定を必要とするものがあります。たとえば、画面拡大表示ソフトウェアでは、ズーム、色、コントラスト、カーソルなど、さまざまなオプションが提供されています。参加者は、テストルームにおいて、いつも使用しているように支援技術を設定する方法を知らない可能性があります。

ある研究では、画面拡大表示機能を使用している参加者の多くが、自分自身でソフトウェアを設定することができませんでしたが、いつもはどのように見え、どのように動いているかを説明することができました。われわれは、セッションの最初に参加者がいつも使用しているようにソフトウェアを設定するために、ソフトウェアの設定に詳しい人を手配しました。

参加者の中には、テストルームの中に自分が使用している支援技術を持ち込むことが可能な人もいるかもしれません。たとえば、画面拡大表示ソフトウェアを備えた自分のノートブックPCを持ち込む場合です。これは、手動によるデータ記録により、Webサイトをテストする場合にはうまくいくかもしれませんが、おそらく、自動データ記録ソフトウェアを用いたベータ版のソフトウェア製品の場合はうまくいかないでしょう。

ソフトウェアを参加者のコンピュータにロードしたり、ソフトウェアのダウンロードやインストールをお願いしたりする前に、複雑な問題が起きる可能性があることを慎重に考慮してください。支援技術の中には、他のソフトウェアとうまく併用できないものがあります。参加者のシステムに深刻な問題が起きた責任を取らされるのは嫌でしょう。このようなことは、参加者が自分のノートブックPCをテストルームに持ち込む場合や遠隔評価の場合に問題となります。

交通手段を考慮してください。一部の障害者にとって移動が困難な場合があります。また、アクセシブルな交通手段は、当てにならないことがよくあり、そのような交通手段を利用した参加者が、ユーザビリティ・テスト・ルームでの厳しいスケジュールに対応できない可能性があります。

われわれは、テストルームではなく、大学のキャンパスでセッションを実施しました。キャンパスは、公共交通機関を使用している参加者にとって非常に便利であり、リクルート活動も簡単になりました。

潜在的な場所のアクセシビリティを評価してください。アクセシブルであるとされているビルの多くには、障害者がテストに参加するのを難しくするような障壁がある場合があります。たとえば、技術的には車椅子にとってアクセシブルであるとされていたある場所では、カーペットが非常に厚く、手動式の車椅子でのアクセスが困難なことがありました。「ユーザビリティ・テストの準備」のセクションの「アクセシブルな場所の確保」では、場所のアクセシビリティに関して考慮すべき具体的なポイントを示しています。

適切な時間のスケジュール

タイミングを知るためにパイロットテストを行ってください。パイロットテストのための時間を余分に計画し、各ステップにかかる時間を記録してください。

われわれが障害者に行った最初のテストの1つでは、参加者に同意書、Web知識調査、財務知識評価、およびテスト後の調査へオンラインで記入してもらう計画でした。しかし、最初のパイロットテスト参加者でロービジョンの人は、オンラインフォームを記入するために、1.5時間を予定していたセッションで約1時間を費やしました。そこで、われわれは、Webおよび財務調査をテストの対象からはずしました。

特定の障害を考慮した上で計画を立ててください。各ユーザビリティ・テスト参加者セッションの時間は、参加者の障害により左右されるため、セッションを延長したほうが、あるいは短縮したほうがが効果的な場合があります。たとえば、痙攣や運動機能の低下など、身体障害がある人は、ボタンを押すなどの基本的なタスクのステップに時間がかかることがあり、認知障害のある人は、テキスト情報および指示の処理に長い時間がかかることがあります。タスクを完了するために、他の人よりも時間が長くかかる障害者もいます。特に、製品があまり使いやすくない場合や似たような製品を過去に使用していない場合はこれがあてはまります。

セッションとセッションの間の時間を長くとる必要がある場合もあります。参加者によっては、テスト前の事務処理、テストルームへの出入り、そして休憩に時間がかかります。参加者を施設内で付添い人を付けるなど、さらにスタッフを追加することを計画するのも良いでしょう。

参加者には、自分の盲導犬をセッション中に散歩させてほしいと頼んできた人もいます。

活力レベルを考慮してください。障害のある参加者によっては、障害そのもの、薬、そして支援技術を使用するための余分な労力により、疲労が問題となることがよくあります。参加者には、休憩が必要であり、長時間のセッションは辛い、あるいは効果的でない場合があります。リクルートする際に時間および疲労に関して考慮すべきことを参加者に尋ね、それにしたがってセッションを計画してください。質問のサンプルは、「参加者のリクルート条件」に示しています。

画面拡大表示ソフトウェアを使用しているある参加者は、画面を30分見続けると吐き気がするため、30分ごとに短い休憩が必要であるとのことでした。

逆に、障害のある参加者の中には、活力レベルが高く、障害のない人よりも持続力のある人もいます。また、タスクを完了するために時間がかかることに慣れており、タスクをうまく完了するために、強い忍耐力と決意を持っている人もいます。このような人は余分な時間が欲しいでしょう。

支援技術のセットアップを確認する時間をスケジュールしてください。参加者が自分の好む形で支援技術がセットアップされ構成されていることをチェックできるように、各テストセッションの最初に時間を設けてください。

参加者が製品に慣れるまでの時間を確保してください。「分析段階」の章の「ユーザビリティの目標の設定」で説明したように、製品に多少慣れている人を対象にユーザビリティ・テストを行う場合、ユーザビリティ・テストを始める前に参加者が製品を使用する時間をスケジュールに含めると良いでしょう。

次に障害者が参加するユーザビリティ・テストの準備に関して説明します。

参考文献

  1. Spool, J. and Schroeder, W. Testing Web Sites: Five Users Is Nowhere Near Enough. Proceedings of ACM CHI Conference on Human Factors in Computing, 2001.
  2. Virzi, R. A. Streamlining the design process: running fewer subjects. Proceedings of the Human Factors Society 34th Annual Meeting, 1990.
  3. Virzi, R. A. "Refining the test phase of usability evaluation: how many subjects is enough?" Human Factors, 34.4 (1992): 457-468.
  4. Nielsen, J. Why You Only Need to Test With 5 Users. Jakob Nielsen's Alertbox, March 19, 2000.

訳
Mitsue-Links

スポンサー

Thank You Just Ask Sponsors: