実践的なユーザビリティ

実用的なエラー メッセージ

Dr. Charles Kreitzberg および Ambrose Little

コードは MSDN コード ギャラリーからダウンロードできます。
オンラインでのコードの参照

目次

ユーザビリティ面の課題
エラー メッセージの問題
設計段階での重要な考慮事項
エラー メッセージの体裁
プログラミング技法
一貫性のある処理
適切に設計されたエラー メッセージ
フレームワーク
Enterprise Library による例外のカスタマイズ

Charles Kreitzberg

ユーザビリティ面の課題

プログラムのユーザビリティがエラー メッセージによって大きく損なわれてしまうことは珍しくありません。プログラムに何か問題が発生した後の判断をユーザーに押し付けることになるからです。プログラムから生成したエラー メッセージで、どのような問題が発生したのか、また、どうすればそれを解決できるのかをユーザーに伝えることができるのが理想です。残念ながら、多くのエラー メッセージがこの理想から遠くかけ離れているのが現状です。

図 1 のメッセージを見てください。私の PC でブート シーケンスの直後に表示されたメッセージです。あまりコンピュータに詳しくないユーザーがこのメッセージを見たら、どう思うでしょうか。問題が何なのかさえわからないのではないでしょうか。このメッセージを見ると、セキュリティが侵害され、深刻な事態が発生したかのような印象を受けます。しかし、実際には、さほど深刻な状況ではありませんでした。よく調べたところ、エラー メッセージの発生源はビデオ エディタ ソフトウェアであり、まったく問題はないことがわかりました。しかし、このメッセージのデザインには、驚くほど多くの問題があります。

1. エラー メッセージがどのプログラムから生成されたのかがわからない。
2. プログラムを強制終了する理由が説明されていない。
3. メッセージがあまりにも漠然としている。"The security information ..." とありますが、具体的に何の情報かが示されていません。
4. 問題がどの程度深刻なのか、また、ユーザーのコンピュータがリスクにさらされているのかどうかがわからない。
5. 問題の解決方法も、詳しい情報の入手先も書かれていない。ユーザーは当然強制終了などしたくないはずですが、[OK] をクリックする以外に選択肢がありません。

図 1 強制終了を告げるメッセージ

図 2 連絡の取れない場所にいたらどうすればよいのか

わかりづらいエラー メッセージに振り回された経験はありませんか。適切なメッセージの作成方法について一定の基準を定めているマイクロソフトのソフトウェアを使用していても、図 2 のような不親切なメッセージに遭遇することがたびたびあります。

Windows Vista ユーザー エクスペリエンス ガイドは、適切なエラー メッセージの 3 大条件として、次のことを挙げています。

• 発生した問題が明確に示されていること。
• 原因が説明されていること。
• 問題の解決策が示されていること。

また、このガイドラインには、適切なエラー メッセージの表示方法について、次のような推奨事項が書かれています。

• 的確である: ユーザーに関係のある問題を表示するようにします。
• 実用的である: ユーザーが何かの対処を講じたり、操作方法を改めなければならないという自覚を持てるようなメッセージにする必要があります。
• ユーザーの立場に立つ: プログラムの中身ではなく、対象ユーザーに求められる対処や目標という視点で問題を説明する必要があります。
• 簡潔である: メッセージは長すぎても短すぎてもいけません。必要な情報をできるだけ簡潔に記す必要があります。
• 明瞭である: 対象ユーザーが問題とその解決策を容易に理解できるように、わかりやすい言葉づかいを心がけます。
• 具体的である: 問題を説明する際には、あいまいな表現を避け、名前や場所、関連するオブジェクトの値を具体的に示すようにします。
• ていねいである: ユーザーを見下した表現や、ユーザーに責任があるような言い回しは避けます。
• ほとんど発生しない: 的確なエラー メッセージはまれにしか表示されません。エラー メッセージがたびたび表示されるということは、粗悪な設計の表れです。

図 2 のエラー メッセージは、以上のいずれの条件も満たしていません。

エラー メッセージの問題

エンド ユーザーにとって効率は非常に重要です。したがって、情報が正確であるというだけでは質の高いエラー メッセージとは言えません。エラーが発生すると、作業が中断され、ユーザー エクスペリエンスが低下するばかりか、コスト面の代償も伴います。ユーザーのサポートに甚大なコストがかかるケースもあるからです。適切なエラー メッセージは、問題の特定を可能にし、ユーザーを解決へと導くことによって、時間やコストを大幅に削減し、ユーザー エクスペリエンスへの影響を最小限に抑えることができます。しかし、適切なエラー メッセージを作成するのは必ずしも容易ではありません。

エラー メッセージは、文字どおり、プログラムが想定外の状況に遭遇したときに発生します。問題の発生源がエラーの検出されたポイントとはまったく別のところにある可能性もあり、根本的な原因を見極めることができない場合も少なくありません。周囲の実行環境まで制御できるとは限りませんが、きちんと時間をかけて有益なメッセージを設計し、技術的な問題をユーザーの立場に立った、実用的な概念に置き換えて説明することで、状況を改善することは可能です。

設計段階での重要な考慮事項

例外処理の扱い方を考えるときには、次のような点をユーザーの立場に立って考える必要があります。

対象ユーザーはだれか 開発者、トレーニングを受けたユーザー、カジュアル ユーザー、一般ユーザーなど。

どのような種類の例外を報告するか 例外をどのように表示するかなど。

ユーザーが利用できるサポート ヘルプ デスクやサポート技術情報などのサポート体制は整っているか。

ユーザーをいかに解決に導くか 解決につながる実用的な情報も提供せずに、ただ問題の発生をユーザーに告げてもユーザー エクスペリエンスを損ねるだけです。

例外の発生をログに記録したり通知したりする必要はあるか ログ情報の表示、検索、並べ替え、フィルタ、管理の方法、通知の形式や内容をどうするかなど、必要に応じて、ユーザーまたは IT 担当者に対する情報の見せ方を検討する必要があります。せっかくの情報も使い物にならないようでは意味がありません。

対象ユーザーごとに表示方法を変える必要はあるか たとえば、開発者と一般ユーザーで表示方法を変えることを検討します。表示を制御するために外部のポリシー ファイルを使用する場合は、セキュリティ ホールを招くことのないように注意します。

メッセージのユーザビリティを向上させることはできるか ある例外を新たに作成した別の例外の中にラップすることによって、基本的な技術情報へのリンクを維持することもできます。アプリケーションの境界を越えて技術的な情報を受け渡しすることによって、セキュリティのリスクが生じていないか確認します。

以上の事項はプロジェクトの終盤ではなく、早い段階で検討する必要があります。

エラー メッセージの体裁

エラー メッセージで大切なのは、可能な限りわかりやすく、正確で、実用的であることです。次の条件を満たすように努めてください。

• できるだけ全体像がわかるように説明する。
• 発生状況をユーザーにとって意味のある範囲でできるだけ詳しく説明する。
• 推奨される対処法をわかりやすい言葉で説明する。対処に関していくつかの選択肢があるような場合には、それをしたらどうなるかをユーザーが確実に理解できるようにして、ユーザーの不安を少しでもやわらげるように配慮します。

次に、適切なエラー メッセージを作成するための推奨事項を示します。

原因を特定する エラー メッセージの発生源となった場所またはアプリケーションをはっきりと示します。エラーがコード内のどこで発生したかがわかるように、より詳細な情報を出力することも 1 つの選択肢です。ただし、内部的な情報が攻撃に悪用されることもあるので、そのような情報を開示する際には注意が必要です。補足的な診断情報やルックアップ情報は、メッセージ本文とは区別するようにしてください。あまりに専門的でわかりにくい情報はエンド ユーザーに見せないようにします。技術的なバックグラウンドのないユーザーに技術的な理解を強いることのないよう、詳細な情報は、折りたたみ式の領域に表示するなど、ユーザーが必要に応じて表示できるように工夫してください。

わかりやすい言葉を用いる 発生したエラーについて説明する際、技術用語は必要最小限にとどめます。エラーが発生したときにユーザーが何をしようとしていたのかがわからないこともあるので、説明は難しいかもしれません。しかし、エラー発生時に行っていた操作や、使用されていたデータをよりよく把握し、発生した問題との関連性を明らかにすれば、ユーザーは今後、その情報に従って行動でき、状況の解決につながる可能性があります。くどいようですが、攻撃やプライバシーの侵害につながるような情報は開示しないように注意してください。エラーの深刻度のほか、可能であれば、その問題によって生じる影響も説明するようにします。

詳しい情報やガイダンスを提供する "HTML エラー - 500 - 内部サーバー エラー" のように漠然とした例外の場合は、より詳しい情報や具体的なガイダンスを提供するようにします。エラーを解決するためにユーザーが行うことのできる対処法と、それを行った場合の結果を明確に説明するようにしてください。可能であれば、詳細情報へのリンクも提供し、ユーザーを適切な判断へと導きます。サポート窓口に問い合わせる以外に方法がないような場合、連絡先の情報の正確さと更新のしやすさには万全を期してください。

ユーザーを適切に誘導する ASP.NET でカスタム エラー ページを使用する場合は、エラー ページの外観を Web サイトの外観に合わせるようにし、関連するページ (最低でもホーム ページ) にユーザーをナビゲートするようにします。また、追加情報が記載されている Web サイトを案内する場合も、ホーム ページにユーザーを置き去りにして、自分で情報を探すように強いるのではなく、適切なページに直接導くようにしてください。

Ambrose Little

プログラミング技法

エラー メッセージは本当に奥が深いと私も思います。Charles が挙げてくれた推奨事項はいずれもたいへん参考になります。では、それらを実際に自分のコードに実装するにはどうしたらよいかを考えてみましょう。

プログラミングの観点では、エラー メッセージを 2 つのカテゴリに分けて考えることをお勧めします。1 つはプログラム的なエラーです。これは、想定外の状況からコード内で発生した例外を指します。プログラム的なエラーが発生した場合、プログラムを適切に終了する以外に方法はありません。もう 1 つはユーザー入力や検証に関する例外で、ユーザーが問題を解決できる場合があります。この種のエラーでは、エラー メッセージが適切に設計されていることが解決の鍵となります。ユーザー入力や検証のエラーについては別の機会に取り上げることとし、このコラムでは、前者、つまり、プログラム的なエラーに重点を置いて説明しようと思います。

一貫性のある処理

どんなにうまく作成されたプログラムでも、エラーは発生するものです。エラーを処理する最善の方法は、プログラム全体で利用できるような、エラー メッセージ用のクラスを作成することです。あらゆるエラー メッセージ処理を、ある 1 点を通るように道筋を作ることによって、次のことが可能となります。

1. すべてのメッセージを首尾一貫した形式で出力できる。
2. カスタム例外型を使用し、各メッセージに一意のエラー コードを割り当てる。これによって、容易にエラー メッセージのディクショナリを作成したり、追加情報で拡張したり、必要に応じてローカライズしたりできます。
3. エラー メッセージからユーザー向けのサポートを提供する Web サイトにアクセスできるようにする。この Web サイトには、最低限、エラー メッセージについての問い合わせを受け付けるサポート窓口の連絡先を掲載するようにします。
4. ログを作成する。記録されたログを自動的に (またはユーザーの許可を得たうえで) サーバーに送ることによって、問題の分析やソフトウェアの品質向上を図ることができます。

適切に設計されたエラー メッセージ

図 3 および図 4 のダイアログ ボックスは、適切に作成されたエラー メッセージの注目すべき点を示したものです。単純なエラー メッセージであれば、Windows Vista ガイドラインで紹介されている、図 3 のようなボックスを使用できます。ユーザー自身が解決できるエラーには、このようなエラー メッセージが最適です。プログラム的なエラーの場合は、図 4 に示したような、もっと詳しいメッセージが必要となります。

図 3 単純なエラー メッセージの形式

図 4 より複雑なエラーに使用されるメッセージ

MSDN ライブラリの記事「.NET Framework 開発者ガイド: 例外のデザインのガイドライン」には、例外処理に役立てることのできる貴重な情報が書かれています。また、MSDN ライブラリの記事「Exception Handling Application Block」に目を通すこともお勧めします。Exception Handling Application Block の機能を使用すると、発生した例外をラップし、必要な情報を追加したうえで独自に作成した例外の中に閉じこめることができます。たとえば、例外が発生したコンテキストなど、より詳しい情報を捕捉して追加することが可能です。この情報を使用すれば、よりユーザーの立場に立ったエラー メッセージを作成することができます。

セキュリティ面の不安から技術的な情報を伝播させたくない場合は、発生した例外をラップするのではなく、よりユーザーの立場に立った例外に置き換えることができます。また、Exception Handling Block を使用すると、エラーをログに記録しておき、それを電子メール、Windows Management Instrumentation (WMI)、または、それ以外の独自のメカニズムで関係者に通知することができます。

ASP.NET 向けの軽量のエラー ログ機能やレポート機能が必要な場合は、「エラー ログ モジュールおよびハンドラ」(ELMAH) を参照してください。ELMAH には、ログ機能と各種のログ ストレージ オプションのほか、ログを Web ページ、電子メール、RSS 通知などで閲覧できる機能が備わっています。また、dotNetTemplar から無料でダウンロードできるような、EntLib の ELMAH 例外ハンドラを作成することもできます。こうした方法を利用しながら、EntLib のインフラストラクチャと、ELMAH のレポート サービスとを融合することが可能です。

Windows XP または Windows Vista 環境向けのアプリケーションを構築する場合、Windows エラー報告サービス (ワトソン博士) を利用する方法もあります。Windows エラー報告サービスは、ユーザーからクラッシュ データを受け取ると、それに関連付けられているユーザー メッセージが存在するかどうかをチェックし、クラッシュ時点のメッセージを表示します。

これらのフレームワークは、例外処理を管理するという点では非常に優れたソリューションですが、それを使ったからといって、ユーザビリティが保証されるわけではありません。対象ユーザーが有している技術レベルを把握したり、明快で正確かつ実用的なエラー メッセージを構築したりするなど、不断の努力を通じて、ユーザーの視点から状況を見ることはやはり必要です。

それでは、これまで述べてきた概念の例をサンプル コードを交えながら説明していきたいと思います。

Enterprise Library による例外のカスタマイズ

以降、Enterprise Library Exception Handling Block の活用例として、Windows フォーム アプリケーション用に例外をカスタマイズする方法を紹介します。同様の手法は、他の Microsoft .NET Framework UI テクノロジにも利用できます。

まず、図 5 の ExceptionHandling に示したような、例外処理を一元化するクラスを作成します。この静的クラスには、Enterprise Library の構成で定義されている例外ポリシーに直接マップするためのメソッドが存在します。

図 5 ExceptionHandling クラス

public static class ExceptionHandling
{
    public static Exception UiUnknown(Exception exception)
    {
        try
        {
            if (Microsoft.Practices.EnterpriseLibrary.
                ExceptionHandling.ExceptionPolicy
                  .HandleException(exception, "UiUnknown"))
                return exception;
        }
        catch (Exception ex)
        {
            return ex;
        }
        return null;
    }
}

Enterprise Library Configuration ツールでポリシーを構成します (図 6 を参照)。ここで、2 つの型ハンドラを指定します。ちょうど try/catch ステートメントに似ています。つまり、例外発生時には、2 つのハンドラのうち、より具体的な方のハンドラが選択されます。どちらのハンドラも、スローされた例外を最初にログに記録しておくようにします。これには、組み込みの XML 例外フォーマッタと XML ログ トレース リスナを使用できます。一般的な例外の場合は、発生元の例外を新しい例外でラップし、よりユーザーの立場に立ったメッセージを表示することができます。完全に置き換えることもできますが、実際に発生した例外の詳細を UI に表示する場合は、ラップした方が簡単です。

図 6 Enterprise Library Configuration ツール

ここで 1 つ忘れてはならない重要な設定があります。例外をラップしたり置き換えたりする場合には、必ず、例外型の PostHandlingAction を ThrowNewException に設定する必要があります。こうすることで、ラップされた新しい例外がスローされます。

呼び出し元のコードで、他に例外処理を行う必要がある場合は、NotifyRethrow を選択するようにします。このオプションを選択した場合、EntLib の ExceptionPolicy.HandleException からは true が返されます。ご覧のように、DatabaseConnectivityException では、カスタム例外型によって、ユーザーの立場に立ったメッセージ処理が実現されています。あらかじめ設定しておく必要のあるポリシーは、例外をログに記録し、例外の再スローが必要である旨を伝えることだけです。

ExceptionHandling.UiUnknown を呼び出した結果は、ラップされた新しい例外が返されるか、元の例外が返されるか、(ポリシーの設定で、新しい例外をスローすることも、再スローすることも選択しなかった場合) 何も返されないかのいずれかです。アプリケーション コードの外側でポリシーを構成できること。これは、Exception Handling Block を利用する最大のメリットです。実行環境全体の横断的な問題をアプリケーション コードから切り離して考えることができるからです。後は、それを ErrorMessage フォームの ErrorMessage.Show メソッド (図 7 ) に渡します。

図 7 ErrorMessage フォーム

public static void Show(Exception relatedException)
{
    ErrorMessage em = new ErrorMessage();
    if (relatedException == null)
    {
        em.problemDetailsContainer.Visible = false;
    }
    else
    {
        em.problemDescription.Text = relatedException.Message;
        IUIExceptionDetail detail = 
          relatedException as IUIExceptionDetail;
        if (detail == null)
        {
            em.errorCode.Text = "500";
            em.problemDetails.Visible = false;
        }
        else
        {
            em.errorCode.Text = detail.ErrorCode.ToString();
            em.problemDetails.Text = detail.DetailMessage;
        }
        em.problemType.Text = 
          em.GetMeaningfulExceptionType(relatedException).Name;
        em._SearchText = em.errorCode.Text + " " + em.problemType.Text;
    }
    em.ShowDialog();
}

ErrorMessage フォームは、非常に親切なつくりとなっています。会社のロゴや連絡先の情報が表示されているほか、問題を会社に報告したり、解決方法をオンラインで検索したりすることもできます。

例外が指定されなかった場合、詳細情報の領域は非表示になります。ユーザーに伝える情報が何もないのであれば、むやみに情報を表示して、ユーザーを困惑させる必要はありません (伝える情報がまったくないのであれば、メッセージそのものを表示しないようにすることも 1 つの選択肢です)。例外が指定された場合は、その問題の説明を例外メッセージに設定しています。続けて、例外型にカスタムの IUIExceptionDetail インターフェイスが実装されているかどうかを確認する処理に進みます。

このインターフェイスを使用すると、より実用的な例外情報を臨機応変に提供することが可能です。実際の例を次に示します。

public interface IUIExceptionDetail
{
    int ErrorCode { get; }
    string DetailMessage { get; }
}

このインターフェイスを使用して、実用的でユーザーの立場に立ったカスタム例外を作成することにより、ユーザーに独力での問題解決を促すことができるほか、単にエラー コードを提供するだけでも、検索時やサポートを依頼する際の手掛かりになります。図 8 の DataConnectivityException 型にも、このインターフェイスが実装されています。

図 8 DataConnectivityException

public class DatabaseConnectivityException 
  : Exception, IUIExceptionDetail
{
    public DatabaseConnectivityException(Exception innerException)
     : base(Resources.Exceptions.DatabaseConnectivityException_Message, 
                innerException)
    {
        int.TryParse(
          Resources.Exceptions.DatabaseConnectivityException_Code,
          out _ErrorCode);
        _DetailMessage = 
           Resources.Exceptions
             .DatabaseConnectivityException_DetailMessage;
    }

    #region IUIExceptionDetail Members
    int _ErrorCode;
    public int ErrorCode
    {
        get { return _ErrorCode; }
    }

    string _DetailMessage;
    public string DetailMessage
    {
        get { return _DetailMessage; }
    }
    #endregion
}

ここで最も興味深いのは、メッセージ、エラー コード、および詳細情報の保存に RESX ファイルを使用している点です。RESX ファイルには、ローカライズが可能になるだけでなく、エラー メッセージ ドキュメント用の XML ソースとして利用できるというメリットがあります。たとえば、RESX 形式に XSLT を適用することによって、HTML や各種のリッチ テキスト マークアップを生成することができます。

このアプローチは、EntLib が提供する基本的なラップ/置き換え機能に適しています。ユーザーの立場に立ったメッセージを表示するために必ずしも EntLib を使用する必要はありません。しかし、例外処理をポリシーとしてアプリケーションから切り離し、外部化することは、ログ機能を実現したり、例外処理をカスタマイズしたりするうえで、きわめて有効な手段であることに変わりはありません。

もう一度 ErrorMessage.Show メソッドに戻って、IUIExceptionDetail interface を見てみましょう。詳細な情報が指定されていた場合は、その情報をユーザーに表示します。詳細な情報が指定されていない場合は、詳細情報の領域を非表示にして、(HTTP 500 に似た) 汎用的なエラー コード 500 を表示しています。

汎用的な未知のエラーが発生した場合は、図 9 のメッセージが表示されます。DataConnectivityException のように、より具体的なエラーが発生した場合は、図 10 のようなメッセージが表示されます。

図 9 汎用的なエラー メッセージ

図 10 より具体的なエラー メッセージ

ここではいくつか注目すべき点があります。まず、このエラー メッセージは Windows Vista ガイドラインに忠実に従っていることがわかります。ウィンドウはモーダル ダイアログで表示されています。ユーザーは、ダイアログ タイトルを見て、どのプログラムからエラーが生成されたのかをすぐに判断することができます。そのため、システム エラーと取り間違えるようなことはありません。また、アプリケーションの特定の機能でエラーが発生したことも一目瞭然です。エラーであることがひとめでわかるように、アプリケーションのロゴに重ねるかたちで、大きなアイコンが表示されています。これには、エラーの発生をはっきりと知らせると共に、問題の発生源を明示する意図が込められています。また、メッセージの見出しを読んだだけでも、それがアプリケーションに関連した問題であると、すぐに察することができます。

タイトルのすぐ下には、例外メッセージが表示されています。このメッセージには、ユーザーが理解できるように、簡潔かつていねいな言葉づかいが用いられていることが大切です。可能ならば、問題の解決方法を記述してもかまいません。一般的なエラーの場合、ここで解決方法を提供することは困難です。そのような場合、最善の方法は、ユーザーにエラーを報告してもらうか、オンラインで検索してもらうことです。接続性の問題であれば、ある程度、考えられる推奨事項を記載することは可能かと思います。ユーザーがこのメッセージを見て独力で問題を解決できるのならば、それに越したことはありません。具体的なメッセージの方が、一般的なメッセージよりも好ましいとされるのには、そのような背景もあります。

図 11 [Tell Us about the Problem] ボタンに注目

"Search for Solutions Online" (解決策をオンラインで検索) というリンク ボタンをクリックすると、エラー コード、例外の種類、および、"MSDN Magazine" を条件とする検索が開始されます。検索ボックスに何を入力すればよいか迷うユーザーもいるかもしれないので、これはよい機能だと思います。自社サイトにユーザー サポート セクションがある場合は、検索をそのサイト内に限定してもかまいません。もちろん、特定の (エラー コードに基づく) 検索サービスがある場合は、一般的なキーワード検索よりも、そちらを利用した方が効果的です。

"Tell Us About the Problem" (問題についてお聞かせください) ボタンをクリックすると、XML ログが Web サービスに送信されます。ユーザーがコンテキスト情報や連絡先情報を入力できるようにしてもかまいません。そうすれば、サービスから追跡情報を送り返すことも可能です。ユーザーは、電話で問い合わせをする際、その追跡情報を使用することができます。

図 11 は、先ほどのダイアログに若干手を加えたものです。変わった点は、"Tell Us About the Problem" が最も目立つコマンドとして画面に配置されていることです。UI デザインで大切なことの 1 つは、視覚的な序列によってユーザーを導くことです。つまり、ユーザーに使わせたい重要な要素がある場合 (ここではコマンド ボタン)、最も目立つように、はっきりと、使いやすいように配置することが大切です。状況に応じてユーザーに行わせたい操作を決め、それぞれの操作に序列があるようであれば、それが視覚的にわかるように配慮する必要があります。

それが済んだら、Program.cs の Main メソッドで、次のように、アプリケーション レベルのハンドラを追加します。

Application.ThreadException += Application_ThreadException;

実際のメソッドは、次のようになります。

static void Application_ThreadException(object sender, 
  System.Threading.ThreadExceptionEventArgs e)
{
    ErrorMessage.Show(ExceptionHandling.UiUnknown(e.Exception));
}

これで、予期しない UI 例外は、一元化された例外ハンドラ クラスですべて捕捉され、"UiUnknown" ポリシーを通じて伝播されます。このサンプルでは、処理を Enterprise Library に委譲していますが、特に Enterprise Library に限定されるわけではなく、他に例外処理フレームワークがあるのであれば、それを利用することもできます。メソッドから返された例外は、よりユーザー フレンドリな ErrorMessage フォームで表示されるようになります。もちろん、これは特定の例外に対するポリシーに対しても同様です。アプリケーション全体を通じて同様のアプローチを使用できます。

これまで見てきたように、適切なエラー メッセージを作成するのは決して簡単ではありません。しかし、きちんと時間をかけ、注意深く設計することによって、ユーザーの負担を軽くし、フラストレーションを大幅に軽減することができます。

Dr. Charles Kreitzberg はユーザビリティのコンサルティングとユーザー エクスペリエンスのデザイン サービスを提供する Cognetics Corporation の CEO です。彼は、製品のビジネス目標をサポートしつつも、ユーザーを魅了し、楽しませる直感的なインターフェイスを作成することに情熱を燃やしています。セントラル ニュージャージー在住で、パフォーミング ミュージシャンとして夜間のアルバイトをしています。

Ambrose Little は、夫人と 4 人の子供とセントラル ニュージャージーで暮らしています。ソフトウェアのデザインおよび開発に 10 年以上携わっており、INETA 講演者であり、Microsoft MVP でもあります。最近は、テクニカル デザインから人々のためのデザインにシフトし、現在は Infragistics 社のユーザー エクスペリエンス デザイナです。