マイケルコーエン「音声ユーザーインターフェイスデザイン。」 2004 [翻訳。 フラグメント]

欧米の音声アプリケーション業界の全盛期は、音声インターフェースの使いやすさに関する多くの研究につながっています。

この分野の古典的な研究は、マイケルコーエンの本であるVoice User Interface Design （2004）です。

habracutの下で、VUIを設計する際に特定の要因を考慮する必要性に関するこの本のある章の翻訳。 モバイルアプリケーションと音声メニュー構造の開発者、インターフェイスオプティマイザー、および音声技術とユーザビリティに関心のある人にとって興味深いものです。

マイクコーエンは、音声技術の分野で認められた権威であり、70以上の作品と多くの特許の著者です。 スタンフォード大学の教授。
1994年、彼はNuanceの創設者の1人になりました。Nuanceは、今日では音声ソリューションを提供する大手西洋企業です。
2004年以来、CohenはGoogleの専任研究員であり、Speech Technology Groupを率いています。

したがって、 「精神的努力の減少」の章

*注意：大きくて深刻なテキスト

PS 読む時間がない場合は、このテキストをダウンロードして合成ポッドキャストとして聞くことができます。


認知とは、外界からの情報を処理することです。 知覚、注意、パターンとの比較、記憶、言語処理、意思決定、行動が含まれます。 精神的努力は、上記のタスクを実行するために必要な精神的リソースの組み合わせです。

すべてのユーザーインターフェイスには、ユーザーの精神的な努力が必要です。 ユーザーは、システムを使用するための特別なルールを習得し、新しい用語に精通し、この情報を短期記憶に入れる必要があります。 システムがどのように機能し、どのように使用できるかを理解する必要があります。 聴覚のみのインターフェースを使用するシステムは、それらの情報が部分的に断続的に送信されるため、人間の記憶と注意にとって重大な問題を提示します。 ユーザーインターフェイスの設計を成功させるには、人間の精神的な努力の制限を遵守する必要があります。 インターフェースの設計で、ユーザーがあまりにも多くの概念を覚えたり、新しいコマンドの複雑さ全体を理解したりする必要がある場合、そのような設計は失敗したと見なすことができます。 この章では、ユーザーが（モバイルまたは固定電話から）音声アクセスインターフェイスにアクセスする際の精神的ストレスを軽減するためのいくつかの基本原則について説明します。

デザインを設計する際に心に留めておく必要がある精神的ストレスに関連する3つの問題があります。

1. 概念的な複雑さ 。 新しい概念に対処するために発信者がどれだけ努力しなければならないか。 新しい概念は、ユーザーがすでによく知っている概念と手順にどのように対応しますか？
2. メモリ負荷 。 ユーザーが短期記憶に保存する情報量。 新しいデータ（コマンド、プロシージャなど）をどれだけ記憶すべきか。
3. ご注意 発信者が最も重要な情報を認識するのは簡単です。 ユーザーの注意が散漫になるかどうか。 ユーザーが一時的に気が散っている場合（例えば、車輪の後ろ）、システムに戻って、ユーザーと自由にやり取りし続けることができます。

次の章では、これらの潜在的な問題のそれぞれについて説明し、その解決策のガイドラインを提供します。

9.1。 概念的な複雑さ
概念的な複雑さは、とりわけ、ユーザーが習得しなければならない新しい概念の量と、固有の複雑さです。 ただし、概念的な問題の考慮は、概念の単純な計算とその複雑さの測定にとどまりません。 概念の複雑さの問題は、一般に人間の能力を理解すること（これは困難であり、人間の知覚にとって何が簡単か）、およびユーザーが行動するコンテキスト（たとえば、このアプリケーションが既存の知識、スキル、期待、メンタルモデルとどのように相互作用するか）の問題でもありますユーザー）。

この本では、個々の設計決定の難しさを正確に予測する理論的基礎を考慮していません。 現時点では、そのような理論を作成することは十分な知識ではありません。 ここでは、ユーザーの精神的な努力を軽減するのに役立つ一連のガイドラインのみを紹介します。

このセクションでは、次の原則について説明します。

• 定数の設定 。 コンテキストに関係なく、ユーザーが常に使用できる定数またはユニバーサルコマンドを作成します。 システムを使用する際にトラブルから抜け出すため、またはヘルプを得るために、ユニバーサルコマンドをユーザーに提供する必要があります。
• 類推を設定する 。 アプリケーション全体で同様のタスクに対して同様のソリューションを作成します。 たとえば、発信者が大規模なポータルアプリケーションでさまざまな種類のリストを知るようになるたびに、同じコマンドセットを作成します。 これにより、ユーザーが学習する必要がある新しい教材の量が減ります。
• コンテキストの形成 。 ユーザーのコンテキストを作成します。 システムが特定のアクションを実行する理由をユーザーに理解させます。 新しい要素をより明確にするために、以前の経験とユーザーの期待に訴える。

9.1.1。 定数を設定する
グラフィカルユーザーインターフェイスは、コンピューター画面に情報を（一度に大量に）表示する機能を使用します。 たとえば、多くのGUIはパネルの形式で実装され（ 図 9.1を参照）、通常は画面の上部に配置されます。 これは通常、さまざまなアクションを表すアイコンで構成されるツールバーであり、選択したアクションとそれらを開始する方法を視覚的に思い出させるものです。

ツールバーは固定されています。ツールバーは画面に残りますが、アイコンは変わりません。 ツールバーの不変性により、ユーザーが多くのアクションやコマンドを覚える必要が少なくなります。

音声ユーザーインターフェイス（VUI）でも同様の一貫性を実現できます-コンテキストに関係なく、常に使用可能な音声コマンドの小さなセットを作成します（5.2.2章を参照）。 ユーザーはユニバーサルコマンドを覚えると、その後の呼び出しでいつでも使用できるようになります。 実際、これらのコマンドは、常に利用可能なアクションのメンタルパネルになります（ 図 9.2を参照）。


図 9.1。 固定されたアイコンを表示するグラフィカルユーザーインターフェイス


図 9.2。 音声コマンドの 思考パネル

ユーザーが多数のユニバーサルコマンドを習得することを期待するのは不合理です。 ただし、音声テクノロジー業界のユニバーサルチームの普及と適用性により、その数はまだわずかに増加する可能性があります。 ユニバーサルコマンドの数を少なくする必要があるため、ユーザーが問題を解決するために使用できる機能にコマンドを関連付けることをお勧めします。たとえば、追加のヘルプや指示を取得したり、アプリケーションの別のレベルに移動したり、ライブオペレーターに切り替えたりします。 このような普遍的なチームをうまく活用することで、運用、自動化、ユーザー満足度のパフォーマンスが向上するはずです。

普遍的なチームの場合、直感的で覚えやすいフレーズ（「 ヘルプ 」など）を選択する必要があります。 チームは、発音のタイミングに関係なく、同じ意味を持つ必要があります。 たとえば、「 ヘルプ 」コマンドは、リクエストが行われるメニューのレベルに関係なく、ユーザーが実行できることに関する詳細な指示を受け取りたいことを意味します。 ユーザーが受け取る応答は現在のコンテキストに関連するという事実にもかかわらず、そのようなコマンドは常に利用可能であるべきです。

2つの標準化委員会がユニバーサルチームの問題を調査しました-電話音声規格委員会（TSSC 2000）と欧州電気通信規格協会（ETSI 2002）。 両方の委員会は、ユニバーサルコマンドを使用して既存のインターフェイスと経験を調べました。 ユーザーの行動パターンに最も近い普遍的な用語の要素を見つけるための実験が行われました。 両委員会は同様の予備調査結果を提供しました。

以下のリストは、すべてのアプリケーションに推奨されるユニバーサルコマンドのセットです。 括弧内の単語またはフレーズは、呼び出し元が使用するコマンドを意味します。 私たちのリストは、2つの標準化委員会の研究結果と、音声アプリケーションの実装における私たち自身の経験に基づいています。 将来、特定の標準が採用された場合、それをサポートします。 音声業界全体、そしてもちろん、特定のユニバーサルチームが標準化されている場合にのみユーザーにメリットがあります。

ユニバーサルコマンドの指定：
[ help ]：ダイアログの現在のセクションでヘルプまたは追加の指示を提供します。
[ repeat ]：最後のメッセージを繰り返します。

ユニバーサルナビゲーションチーム：
[ メインメニュー / 先頭に戻る ]：ユーザーをアプリケーションの先頭に戻します（アプリケーションの任意のレベルから）。
[ 戻る ]：1ステップ戻ります。

最終的な汎用コマンド：
[ operator ]：ユーザーをオペレーターに切り替えます。
[ さようなら ]：ユーザーが対話を中断できるようにして、通信を便利に終了できるようにします。

送別コマンドがこのリストに含まれているのは、このようなコマンドが対話システムに実装されていることを知らなくても、ユーザーがシステムに別れを告げることを示したデータの分析からです。 ユーザビリティ調査では、多くのユーザーが単にハングアップするのではなく、「 さようなら 」と言ってシステムとの対話を終了することを好むことが示されています。 どうやら、この動作により、システムとの通信セッションが本当に完了したという自信が得られます。

ユーザーにユニバーサルチームの存在を通知する必要があります。 それ以外の場合、それらは使用されません。 アプローチの1つは、システムへの最初のアクセスでこれについてユーザーに通知することです。 他の汎用コマンドの説明は、「 ヘルプ 」メッセージの最後の部分、およびシステムとの通信エラーが発生したときのヒントに含めることができます。 たとえば、銀行への申請時に使用されるアプリケーションでは、次の最初のアピールが可能です。

Western Valley Bankへようこそ。 このサービスの使用に問題がある場合は、「 ヘルプ 」と発声してください。 今何をしたいですか？ -請求書の支払い、残高の確認、または送金？

操作の途中でユーザーが残高証明書を受け取るために「 ヘルプ 」と言うと、システムは次の情報を提供できます。

これが私たちがあなたを助けることができる方法です。 残高情報をリクエストしましたが、問題のユーザーはわかりません。 「 Account 」または「 Account Verification 」と発声できます。 また、いつでも「 メインメニュー 」または「 オペレーター 」と発声できます 。

9.1.2。 類推の設定
また、要素の類似性に十分な注意を払うことにより、ユーザーの精神的な負担を軽減することもできます。 このアイデアは、ユーザーが同じ方法で同じ手順を実行できるようにすることです。 たとえば、アプリケーションの実行中にユーザーに提供されるいくつかのリスト（株式のリスト、未払いまたは支払済みの請求書など）があります。 同じ移動戦略を使用して、ユーザーはスキルをあるリストから別のリストに移します。 同様のシーケンスをさまざまなレベルで適用できます。 また、対話戦略と用語は類似している必要があります。 文法構造も同様でなければなりません。 ある場所で詳細なマネーアカウントシステムを使用する場合は、別の場所で丸めを使用しないでください。

実践が示すように、ユーザーは実行されたすべてのアクションから学びます。 システムとユーザー間の相互作用により、ユーザーの「メンタルモデル」が向上します。 このモデルには、システムの機能、さまざまなタスクを実行するためのコマンド、文法モデルなどの理解が含まれます。 類推の確立は、モデルの同化のプロセスをより効率的かつ効果的にします。 一方、類似した要素の類似性の欠如は、効果のない学習と混乱を招き、システムでの否定的な経験をもたらします。

リスト内でユーザーを移動する例を考えてみましょう。 証券会社との所定の対話では、2つのリストが移動されます。企業の観察された証券のリストと、株式の売買リストによるものです。 ユーザーはこれらの異なるリストで同じシステムコントロールを使用することに注意してください。

（1）
システム ：何をしたいですか？
ユーザー ：証券のリストを表示します。
システム ：International Business Machines-82、1ポイントアップ。 アマゾン、36、下に...
ユーザー ：次へ。
システム ：Ford Motor Company、10ポイント...
ユーザー ：次へ。
システム ：Charles Schwab Corporation、11 ...
ユーザー ：終了。
システム ：次に何をしたいですか？
ユーザー ：入札について教えてください。
システム ：5つの未決注文があります。 ここに最初のものがあります-マイクロソフトの100株を売るために...
ユーザー ：次へ。
システム ：17でシスコシステムズの200株を取得...
ユーザー ：次へ。
システム ：82で国際ビジネス機械の500株を取得...
ユーザー ：終了。
システム ：次に何をしたいですか？

9.1.3。 コンテキストインストール
コンテキストインストールは、音声ユーザーインターフェイスに適用すると、精神的ストレスの軽減に役立つもう1つの重要な概念です（Weinschenk and Barker 2000）。 心理学的研究は、情報が適切なコンテキストで提示されると、人々が情報をより容易に理解し、記憶することを示しています。 たとえば、次の言葉の文章を考えてみてください（Bransford and Johnson 1973）：

「手順は本当に簡単です。 まず、すべてを異なるグループに分けます。 もちろん、必要な量に応じて、1食分で十分です。 施設が不十分で、他の場所に行く必要がある場合、これが次のステップです。 そうでない場合、すべてが順調に進んでいます。 無理をしないことが重要です。 つまり、一度に多すぎるよりも少なすぎる方が良いということです。 最初は、これはささいなことのように思えるかもしれませんが、困難はすぐに増加します。 間違いも費用がかかります。 最初は、手順全体が複雑に見えます。 しかし、すぐにそれは人生のもう一つの小さなものになるでしょう。」

もちろん、この段落を読んで、あなたが正確に何を意味するかを理解することは困難でした。 しかし、「衣類を洗う」という文脈を持っているので、衣類を洗うというあなたの知識を使って、この箇所で理解できないすべてを解読することができます。 最初の文で言及されている「手順」は衣服の洗濯です。 「すべて」は衣類、「異なるグループ」は異なる色の衣類グループなどです。 さて、このパラグラフを読み直したら、完全に理解する必要があります。 実験の参加者は、コンテンツのアイデアを解読せずに、このテキストからできるだけ多くの考えを思い出すように求められたとき、3つの重要な断片について思い出すことができました。 物語の前に洗濯物だというメッセージがあったとき、実験の参加者は2倍多くの要素を思い出しました。 コンテキストは、人々が新しい情報と既によく知られている概念を組み合わせるのに役立ち、間違いなく精神的な負担を軽減します。

ユーザーインターフェイスでコンテキストを作成する1つの方法は、 メタファーを使用することです。 第4章で説明したように、メタファーは、未知の要素の理解を促進するために使用されるオブジェクトまたは図の記号です。 ショッピングには、デスクトップのメタファーまたはショッピングカートのメタファーを使用できます。

この比phorが音声インターフェイスのユーザーに本当に役立つかどうかを調べるために、ブリティッシュテレコムの研究者は、ショッピング用の3つの自動音声システムを比較した調査を実施しました。 1つのシステムは比phorを使用しませんでしたが、音声メニューにある製品の簡単な説明を表していました。 別のユーザーは、店舗のメタファーを使用しました。ユーザーは、仮想エレベーター（対応する音響効果付き）を使用してフロアからフロアへ移動し、購入を選択しました。 3番目のシステムは、カタログジャーナルのメタファーを使用しました。 ユーザーは、メタファーをまったく使用しないシステムよりも、ストアのメタファーを使用するシステムを評価しました。 カタログジャーナルのメタファーを持つシステムは中央にあります。 さらに、メタファーを使用したシステム要素を介して、ユーザーはより簡単にナビゲートできました。 これらの調査結果は、メタファーを使用したコンテキストコミュニケーションがユーザー満足度とシステム効率の割合を高めることを示唆しています。

9.2。 メモリ負荷
発信者は一度に大量の新しい情報を学習することはできず、新しい情報を覚えていません。 メニューの作成、クエリの作成、ユーザーの記憶への負荷を軽減するための指示を作成する方法はいくつかあります。

9.2.1。 メニューサイズ
有名な記事「マジックナンバー7、プラスまたはマイナス2」で、Miller（1956）は、7つのプラスまたはマイナス2つの要素を格納できる人間の短期記憶の構造を説明しました。 多くの場合、この記事は、メニューアイテムで使用するアイテムの数に関するデザイナーのガイドとして役立ちます。 それでも、聞き取った文から情報を抽出するタスクは、ミラーの実験中よりも複雑であることがわかりました。 私たちのタスクでは、いくつかの文を聞き、各文の最後の単語を覚えておくことが提案されている実験がより適しています（Daneman and Carpenter 1980）。 この完全なオーディオマニアのアプローチ（文の理解も重視）を使用した実験では、平均して、人々は3つの要素について覚えています。

人間の記憶に関する別の研究では、人々は自然に要素をトリプルにグループ化することが示されており、要素をトリプルまたは4にグループ化するときに想起が最適である（Broadbent 1975; Wickelgren 1964）。 したがって、これらの調査の全体は、ユーザーの記憶への負荷が非常に小さいことを示しています。 合理的な制限は、メニュー項目を3〜4要素のレベルに減らすことです。 Gardner-Bonneau（1992）とSchumacher、Hardzinski、Schwarz（1995）の研究者も、4つ以下のメニュー項目の使用を推奨しています。

9.2.2。 記憶力
ユーザーがクエリで使用できる式で構成されるヒントを作成するときは、最後に聞こえるように文の最後に配置します。 たとえば、「リストをもう一度聞くには、「 リストを繰り返して 」と言います」-「リストをもう一度聞いて」と言う「言う：」 リストよりも良いです。 最初のケースでは、ユーザーのメモリ電圧が低下します。なぜなら、 彼が聞いた最後のフレーズを覚えるだけです。 この効果は、多くの場合「メモリ効果」と呼ばれます。 このようなシーケンス（最初の割り当て、次にアクション）は、トーン電話システムの標準から継承されました（Balentine 1999）。 しかし、文の終わりにそのような表現のより好ましい配置を示す言語的な理由もあります。 これらの理由については、第10章で説明します。

9.2.3。 チーム
優れた機能を備えたアプリケーション、特に再利用を伴うアプリケーションには、多くの場合、システムを使用するトレーニングモードが含まれています。 多くの場合、電子メールに送信されるか、プロンプトのリストとして投稿されるコマンドのリストは、あまり効果的ではありません。 ほとんどのユーザーは、システムを使用する前に指示を読みません。 したがって、アプリケーションは自給自足でなければなりません。 経験の浅いユーザーが最初にサービスを使用するときに必要なすべての支援を受ける機会を提供する必要があります。 以下では、2つのアプローチを検討します。

チュートリアル
一部のシステムは、オンラインレッスン 、 デモ 、または両方の組み合わせを提供します。 通常、音声ガイドオプションは、音声システムを使用する最初のステップで音声システムに存在します。 このアプローチは通常、サブスクリプションサービスまたは繰り返し使用するように設計されたサービス（個人の日記、銀行のディレクトリ、証券会社など）で使用されます。 ガイドには、システムの基本機能を使用するための段階的な手順が含まれています。 デモは、架空のユーザーとシステム間の記録されたダイアログで構成されます。 システムの音声プロンプトは、サービスの実際の使用中に再生されます。

システムとのユーザーインタラクションのデモンストレーションであるマニュアル（CCIR-4 1999）、およびインタラクティブなトレーニングレッスン（Kamm、Litman、およびWalker 1998）は、システムの新しいユーザーに対するニーズを見出しました。 ただし、ユーザーにとって、情報が多すぎるマニュアルとデモの両方を習得することは非常に困難です（Balogh、LeDuc、およびCohen 2001）。 ガイドラインに関する2つの重要なルールがあります。

1. 少数の概念のみを説明してください。
2. ガイドをインタラクティブにします。 ユーザーがシステムと対話できるようにします。

タイムリーなチーム
多数の機能を説明する必要がある場合、マニュアルやデモンストレーションに完全に頼ることはできません。 第一に、ユーザーがさまざまな機能の長い説明を知覚することは困難です。 第二に、関数がすぐに使用されない場合、その値はすぐに忘れられる可能性があります。 原則として、特に問題の解決に役立たない場合、ユーザーは長い指示を聞くのに忍耐強くありません。

「タイムリーなチーム」という概念は、トレーニングマニュアルに固有のこれら2つの制限を取り除きます（Cohen 2000）。 アイデアは、特定のタスクに直面したときにユーザーに指示を直接提供することです。 適切なタイミングで提供される新しい情報の量は少なく、すぐに適用されます。

たとえば、幅広い機能を備えた個人的な日記を考えてみましょう。 システムを初めて使用するときに詳細なマニュアルを聞く代わりに、ユーザーはシステムに最初にアクセスしたときにシステムの機能について通知されます。 たとえば、ユーザーが最初にルートと渋滞に関する情報を要求すると、次のメッセージが表示される場合があります。

場所の名前を発音することで、市内の主要な高速道路で車の正確なスケジュールを取得できます。道路や主要な高速道路の名前、または目的地の名前を呼び出すことで時間を節約することもできます。たとえば、「サンフランシスコのハイウェイ101」と言うことができます。

タイムリーなチームは、ユーザーが最初に新しい機能に出会ったときに提供できます。さらに、システムの使用中に多くの問題（頻繁なエラー、認識の問題、タイムアウト制限の超過など）に遭遇したユーザーにコマンドを提供できます。また、ユーザーがシステムのすべての機能を使用しない場合（たとえば、クイックジャンプを使用しない、または要求されたときに意図的にスピーチを貧困にする場合）にも、タイムリーなコマンドが可能です。

次の2つの例では、2つの命令配信アプローチを比較します。例（2）では、最初のアクセス時にユーザーにマニュアルが提供されます。ガイダンスは長く、大量の情報を網羅しています。ユーザーが聞いたことの多くを思い出せるかどうかは疑わしいようです。例（3）はタイムリーなコマンドを使用しています。同じ素材が対象です。この例では、相場と株のリストのチームのみを示しています。それにもかかわらず、この情報がユーザーにとって適切で有用な場合、システムは短いコメントを提供します。

(2)
: Princeton Brokerage. , , , . , . , « », , . , , , : « ». , « ». , « » « » , , . , : « Intel » « Apple ». , : « ». , : « ». , .

(3)
: Princeton Brokerage. , , , . ?
: .
: , , .
: IBM.
: International Business Machines .
: Cisco.
: Cisco 17.25.
: .
: , – . , . . : « ». , ?
: Cisco.
: ? : « ».
: IBM.
: : « ».
: Intel.
: ?
: America Online.
: ?
: < >
: , ? < > : « ».
: .
: . , , : « ». , : « ». ?

9.3。注意

注意は、多くの同等の主題（Preece、Rogers、およびSharp 2002）に集中する主題を選択するプロセスです。情報がユーザーに配信される方法は、ユーザーが関心のある情報にどれだけ簡単に集中できるかに大きく影響します。

旅行を計画できるアプリケーションでフライト情報を読み取る例を見てみましょう。ユーザーが「今日の午後」にニューヨークからボストンまでの飛行機に関する情報を要求したと想像してください。システムがデータベース内で検索条件に一致する4つのフライトを検出し、その結果をユーザーに通知するとします。次の4つの可能なフライトのリストを提示します。

（4）
システム：ユナイテッド航空47便は、ニューヨークケネディ空港から13.00、レーン36を出発し、13.45にボストンローガンに到着します。レーン22。ユナイテッド航空243便は、ニューヨークケネディ空港から14.15、レーン12を出発し、ボストンローガンに15.00に到着します。レーン47。ユナイテッド航空260便は、ニューヨークケネディ空港から15.45、レーン15を出発し、16.30にボストンローガンに到着します。レーン42。ユナイテッド航空52便は、ニューヨークケネディ空港から17.00に出発し、レーン38から17.45にボストンローガンに飛びます。レーン31。どのフライトを選択しますか？

フライトの1つが要件を満たすことができるという事実にもかかわらず、情報は、注意を完全に分散させ、正しい選択をさせることができないような混乱の中で表示されます。次に、代替案を想像してください。

(5)
: 13.00, 14.15, 15.45 17.00. ?
: 14.15?
: 243 United Airlines - Kennedy Airport 14.15, 12 Logan 15.00; 47. ?

この場合、ユーザーには本当に関心のある情報のみが提供されるため、意思決定が非常に容易になります。アプリケーションに複雑な情報が含まれている場合は、アプリケーションの要件を作成するときにこれに注意する必要があります。潜在的なユーザーを選択するための目標、優先順位、および基準を確実に理解する必要があります。この場合、情報を正確に提供することができ、データの全量でユーザーを過負荷にすることはありません。

場合によっては、注意の分散が避けられないことがあります。たとえば、ユーザーが運転しているときに、道路への注意を完全に移す必要がある状況が発生する場合があります。車での使用を目的としたシステムは、この相互作用の特徴を考慮に入れ、対話のペースを制御できなければなりません。ユーザー自身も、たとえばpause / resumeコマンドを使用してシステムを制御できる場合があります。または、ユーザーがシステムとの対話を継続できるように、システム自体がダイアログの継続を確認する必要があります。 （注：ドライバーのVUI設計の問題は、慎重な研究が必要な別の研究分野です。例は単なる説明であり、真剣な研究の結果ではありません。）

必要な情報を継続的に提示する必要がある場合があります。あなたの声とメールを読んでいる個人的な日記を想像してください。読み取り時に新しいメッセージを受信した場合、アプリケーションは現在の文字の読み取りを中断せずに、音声メッセージで配信を通知できます。 「新しいボイスメールを受信しました」という音声メッセージは注意をそらすことはありません。

要約すると、ユーザーの注意を引くための最初のステップは、ユーザーの目標と優先順位を理解することです。この後、関連情報のみがユーザーに提供されるような対話モデルを作成することが可能になります。同時に、システムはユーザーのニーズに適応することができ、システム自体を超えた情報やイベントにユーザーの注意を向けることができます。

9. 4.結論
この章では、精神的努力、記憶負荷、注意などの精神的課題の基本原則を検討しました。他のすべての規定と同様に、それらはもちろん注意して特定のコンテキストで適用する必要があります。次の2つの章は、会話中に期待について議論することに専念します。言葉遣いのための第10章を議論のオプション（「ことを待っている時間中にシステムに指示します」）、および音のための11章を議論のオプション（「どのように」システム言った待ち時間の間に）。