現在、ラインワール応用科学大学（ドイツ）で修士課程のユーザビリティエンジニアリングの 2番目の学位を取得しています。
このプログラムは、完全にユーザビリティとHCDに専念しているドイツで唯一のプログラムです。 さらに、 Samsung 、 Siemens 、 Wargaming 、 Porscheなどの企業で働くユーザビリティの専門家は、通常、教師として行動します。 さらに、一部の教師は、ユーザビリティに関するISO標準ワーキンググループのメンバーです。
この記事と後続の記事では、トレーニングの一環として受け取る知識の一部を共有する予定です。
なぜこれらすべての標準を知る必要があるのですか？
標準の使用には、いくつかの重要な利点があります。
- リソースの節約 -車輪を再発明する必要はありません。
- 予測可能な結果 -標準で使用されている概念は、実際に何度もテストされています。
- コミュニケーションの簡素化 -チーム全体に単一のビジョンがあり、最も重要なことは、用語の単一の語彙があることです。
- 概念的見解 -ほとんどの標準は、「どうやってそれをするのか？」という質問には答えず、代わりに「なぜ？」と「何を考慮する？」に焦点を合わせます。
- 互換性 -異なるシリーズのISO標準は相互に互換性があると想定されます。
- 「販売」のシンプルさ -国際基準に依存している場合、リーダーシップに自分の考えを伝えるのが簡単になります。
- 認証 -ISO 9001などの規格に関連。
これはすべてごく当たり前のことです。 Usabilltyの用語とアプローチのほとんどが十分に確立されていないことが判明するまで。 「アフォーダンス」と呼ぶものもあれば、記号表現と呼ぶものもあります。 多くのメソッドにはいくつかの名前があります。 多くの概念（たとえば、人の概念）が必要に応じて使用されます。 したがって、この規格により、業界の秩序を何らかの形で復元することが可能になります。
ISO規格9241-110
標準のISO 9241-110 （対話を整理するための原則）について話す場合、それは標準のISO 9241 （人間工学と人間とコンピューターの相互作用）の一部です。 ISO 9241-110規格の主な目的は、ダイアログの分析、開発、評価（テスト）に関する推奨事項を提供することです。
同時に、この標準は、ダイアログでの一般的な間違いを防ぐことを目的としています。
- 現在の問題を解決するために必要ではない追加の不必要な手順 -ユーザーは無料サイトに登録され、カード番号を入力するよう求められます。
- ダイアログ内の矛盾する情報 -ユーザーは「残り1分」という碑文で1時間瞑想していました。
- ダイアログの情報不足-GPSナビゲーターは到着予定時刻を表示しません。
- インタラクティブシステムからの予期しない応答 -MicrosoftのWebサイトで「ログアウトを押してログインする」を見たことがあります。
- 無効なエラー回復 -最後のアクションを取り消すボタンのないMS Wordを想像してください。
- ナビゲーションの制限 -ユーザーはホテルを予約する予定で、すでに支払い段階にあるため、日付を変更したいことに気付きます。 ユーザーは戻りたいが、戻るボタンはありません。 ユーザーは別のサイトに移動します。
問題を解決するために、規格では7つの原則の使用が提案されています。 GOSTからの翻訳を括弧内に示す英語名を使用します。
- タスクの適合性 （制作タスクのダイアログの適用可能性）;
- ユーザーの期待との適合性 。
- 自己記述性 （情報提供）;
- 学習への適合性 。
- 可制御性
- エラー許容度（エラー許容値）;
- 個別化への適合性（ユーザーの個々の特性への適合性）。
1.タスクへの適合性
最も重要な原則。 クールなアプリケーションを作成しても、ユーザーのタスクが解決しない場合は、時間を無駄にしています。
標準によれば、ダイアログは、ユーザーが最小限の労力で問題をうまく解決できる場合、問題を解決するのに適しています。 ユーザーのタスクが何であるかを見つける方法は、別の記事のトピックです。 ここでは、ユーザーがどのような目標を追求しているかを既に知っていると考えています。
推奨事項：
- デフォルトで一般的な値を使用可能にします -ユーザーが鉄道駅でチケットを購入する場合、これを出発地として指定するのが賢明です。
- 必要な手順と情報のみ -スマートホーム用のシステムを開発しました。 誰かが家の蛇口を閉めるのを忘れるたびに、彼女はリマインダーをユーザーに送信します。 ユーザーはリマインダーを必要とせず、タップを自動的に閉じるだけです。
- 物理的なドキュメントとの互換性を確保します -アプリケーションが紙のドキュメントから情報を入力する場合、製品のフィールドが元のドキュメントのフィールドの場所と意味と一致することを確認します。
2.ユーザーの期待との適合
標準によれば、アプリケーションは「ユーザーのコンテキストのニーズと一般に受け入れられている規則」に準拠する必要があります。
このフレーズの意味をよりよく理解するには、コンテキストとは何かを理解する必要があります。 ISO 9241-11によると、使用のコンテキストは、ユーザーの特性とそのタスク、および組織的、技術的、物理的環境の組み合わせです。
明らかに、ペアでゆっくりと移動している学生ユーザーの期待と、緊急通報中の救急隊員の期待は大きく異なる可能性があります。 同じタブレットコンピューターを使用している場合でも。 したがって、設計ではこれらの違いを考慮する必要があります。
推奨事項：
- ユーザーの経験、知識、およびスキルを考慮してください。たとえば、高齢者はアプリケーションでより大きなボタンとテキストを期待できます。
- おなじみの用語を使用します -各業界には独自のスラングがあり、開発時にはこれを考慮してください。
- 製品を全体的にする -「OK」ボタンが緑色の場合、アプリケーションのすべての画面で緑色にします。
- ユーザーに予期しないことをする場合は 、事前にユーザーに警告してください（ 「このアクションの完了後、次のシステムブートには約1時間かかることがあります」 ）。
3.自己記述性
それは第二の原理から直接流れます。 ユーザーは、自分がどこにいるか、なぜここにいるのか、次に何をすべきかを常に理解する必要があります。
推奨事項：
- 現在のステータスに関する情報を提供します -ほとんどのコンピューターゲームでは、プレイヤーはいつ死亡したかを常に把握しており、ジャンプやランニングができないことに驚いていません。
- フィードバックを提供する -ユーザーがボタンをクリックした場合、プログラムがこのクリックを認識したことをユーザーに知らせます（ さまざまな種類のフィードバックを使用できます：サウンド、形状の変更など ）。
- ユーザーはマニュアルを読みません 。実際のユーザーでデザインをテストしてください。 ユーザーが何をすべきかを理解していることを確認してください。
- 期待を説明します -多くの場合、ユーザーが特定の形式（たとえば、日月年）でこの情報またはその情報を入力することを期待します。 この場合、必要な形式に関するヒントを明示的に提供することをお勧めします。
4.学習への適合性
対話はユーザーをサポートし、学習を促進するものでなければなりません。
特に重要な原則は、「未来を発明する」ことであり、製品がユーザーの期待を満たしておらず、情報価値がない場合です。
推奨事項：
- 「ゲームのルール」を説明してください -良い例はキックスターターです。 彼らの製品が新しいことを知って、彼らはクラウドファンディングとは何か、そしてKickstarter内でそれを実装する方法をユーザーに理解させるために可能な限りのことをしようとしました。
- 適切なサポートを提供する -ユーザーがどのような状況にあるのか、ユーザーが何をしているのか、何を達成しようとしているのか、ダイアログから期待することを考えてください。
- ユーザーは同じではないことに注意してください。ユーザーは異なる速度で学習できます。一部のユーザーはより近いテキストを使用し、一部の写真を使用できます。
5.可制御性
ユーザーは、相互作用を管理できるだけでなく、相互作用を開始できる必要があります。
推奨事項：
- 中断の可能性を想定 -ユーザーがダイアログを中断したい場合はどうなりますか？ 突然の再起動によってダイアログが中断された場合はどうなりますか？
- アクションのキャンセルを許可 -これは、ctrl + zと、戻るボタンを押して前のダイアログ画面に戻る機能の両方に適用されます。
- 入力デバイスについて考えます -ユーザーがキーボードとマウスを使用している場合はどうなりますか？ キーボードだけなら？ 彼が声をコントロールしたら？ 彼はプロのグラフィックタブレットを使用する必要がありますか？
6.エラー耐性
ユーザーは、調整なしで（または最小限の調整で）目標を達成できる必要があります。
推奨事項：
- ユーザーがエラーを検出して回避できるようにします -たとえば、エントリが正しくない赤いフィールドをハイライトします
- システムの「予期しない」状態を防止します -理想的には、ユーザーの操作がシステムの異常な状態や故障につながるべきではありません。
- 積極的なサポートを提供する -エラーが検出された場合は、ユーザーに通知し、可能な解決策を説明します。
7.個別化への適合性
非常に物議を醸す原則なので、私は最後にそれを置きます。
古典的な推論：完全にカスタマイズ可能なインターフェースを作成したため、ユーザビリティについて心配する必要はありません-ユーザー自身が彼にとってより便利なものを知っています。 きれいに聞こえますが、2つのポイントがあります。 まず、ユーザーはあなただけでなくあなたの製品も知りません。 第二に、ユーザーは人間工学とデザインの専門家ではありません。 したがって、ユーザーフレンドリーなインターフェースを作成するのはあなたの仕事です。
推奨事項：
- 身体障害を持つユーザーを考えてください -この種の個別化は通常、ダイアログの利益のために機能します。
- ユーザーが言語を選択できるようにします -また、安全なカスタマイズ。
おわりに
結論として、標準の使用についていくつかの言葉を述べたいと思います。
第1に、この標準は本質的に助言であり、リフレクションのチェックポイントのリストと見なすことができます。 たとえば、非常事態省向けのインターフェイスを作成している場合、標準に従って、インターフェイスをカスタマイズする可能性を検討してください。 おそらく、あなたは緊急事態のためにソフトウェアをカスタマイズすることの不適切さを決定するでしょう。 それでも、この決定を作業文書に明示的に反映することをお勧めします。
第二に、この標準は、新しいソリューションを開発するときだけでなく、古いソリューションのコンプライアンスをチェックするときにも使用できます。
この記事がおもしろく、時間の価値があることを願っています。 最後に、簡単な調査。