پیام‌های خطا (Error Messages) یکی از رایج‌ترین راه‌های ارتباطی کاربران با سیستم پیش‌رویشان است و درواقع این پیام‌‌ها خبر از اتفاقی غیرمنتظره می‌دهند.
آنچه در ارتباط با تعامل کاربران با یک سیستم نرم‌افزاری می‌بایست همواره مدنظر قرار داد این است که کاربران معمولاً به شکلی سیستماتیک و قابل‌پیش‌بینی منجر به ایجاد ارورها می‌شوند (به‌طورمثال، وارد کردن یک ورودی غیر عددی در فیلدی که صرفاً عدد می‌گیرد). از همین روی، به دلیل قابل‌پیش‌بینی بودن این نوع تعامل، به‌سادگی قادر خواهیم بود همان‌طور که سایر بخش‌های سیستم را دیباگ می‌کنیم، دست به دیباگ کردن نحوهٔ تعامل کاربران با سیستم نیز بزنیم.
برای روشن‌تر شدن این مسأله، مثالی می‌زنیم؛ فرض کنیم یک فیلد ورودی داریم که صرفاً مخصوص دریافت تاریخ است آن‌هم در یک بازهٔ خاص؛ در چنین شرایطی، به‌جای آن که به کاربر اجازه دهیم تا هر تاریخی را وارد کند، به‌سادگی می‌توانیم طیفی از تاریخ‌هایی که مجاز هستند را درمعرض دیدش قرار داده تا وی یکی از آن‌ها را انتخاب کند. چنین کاری احتمال آن‌که کاربر تاریخی خارج از طیف مدنظر را وارد سازد کاهش داده و همین مسأله منجر به ایجاد تجربهٔ کاربری به‌مراتب بهتری می‌گردد.
علاوه‌بر این، گاهی‌اوقات تنبلی دولوپرها هم منجر به سختی کشیدن بیشتر کاربران درحین استفاده از اپلیکیشن می‌شود. برای روشن‌تر شدن این مسأله، مجدد به مثال فوق بازمی‌گردیم؛ وقتی که کاربران با فیلدی که برای درج تاریخ درمعرض دیدشان قرار می‌گیرند مواجه می‌شوند، ممکن است تاریخ مدنظر خود را به‌صورت مثلاً 14-12-1390 وارد کنند اما این درحالی است که پس از ارسال دیتا برای سرور، صرفاً فرمتی همچون ۱۳۹۰/۱۲/۱۴ قابل‌قبول است و دادهٔ ورودی کاربر غیرقابل‌قبول تلقی می‌گردد.
در چنین شرایطی، دولوپرها ۲ راه‌کار پیش‌رو دارند؛ راه‌کار اول این که انواع فرمت‌هایی که کاربر می‌تواند وارد کند را تفسیر کرده و در دیتابیس ذخیره سازند (مثلاً فرمت‌هایی همچون 14-12-1390 یا ۱۳۹۰/۱۲/۱۴ یا حتی بااستفاده از اسپیس و به‌صورت 14 12 1390) و راه‌کار دوم این که صرفاً یک فرمت را مدنظر قرار داده و اگر کاربری چیزی به غیر از آن‌را وارد ساخت، خیلی ساده یک پیام خطا درمعرض دیدش قرار دهند.
از آنجا که راه‌کار دوم بار کدنویسی کمتری روی دولوپر دارا است، اکثر دولوپرها چنین راه‌کاری را انتخاب می‌کنند غافل از این‌که انتخاب چنین رویکردی باعث سردرگمی بیشتر کاربران می‌شود!
حال اگر هم راه‌کار دوم مدنظر دولوپر باشد، بازهم راه‌کارهایی برای به حداقل رساندن خطاها از طرف کاربران وجود دارد؛ مثلاً به‌سادگی می‌توان لیبل‌هایی حاوی متنی مرتبط با فرمت مدنظر درمعرض دید کاربر قرار داد و یا ۳ فیلد مجزا یکی برای سال، یکی برای ماه و دیگری برای روز با لیبل‌های گویا و مشخص درنظر گرفت تا احتمال خطا را به حداقل رساند.
به‌طورکلی، برخی دولوپرها هستند که دستورالعمل‌هایی برای نحوهٔ تعامل کاربر با اپلیکیشن درنظر می‌گیرند اما این درحالی است که بسیاری از این دستورالعمل‌های توسط کاربران اصلاً خوانده نمی‌شوند چراکه کاربران یا حوصلهٔ مطالعهٔ چنین دستورالعمل‌هایی را ندارند و یا فرض را بر این می‌گذارند که نحوهٔ تعامل با سیستم -باتوجه به تجربیات گذشتهٔ خود در تعامل با سرویس‌هایی مشابه- را بلد هستند.
در همین راستا، توصیه می‌شود که به‌جای استفاده از دستورالعمل‌های نحوهٔ استفاده از یک سرویس، اصطلاحاً Hint در اختیار کاربران قرار گیرد. درواقع، تفاوت Hint (به‌معنی ایما، تذکر و اشاره) با Instruction (دستورالعمل) در این است که دستورالعمل‌ها همواره پیش از تعامل کاربر با سیستم در قالب یک پاپ‌آپ، پیام، باکس و … درمعرض دیدش قرار می‌گیرد اما این درحالی است که هینت‌ها درحین تعامل کاربر با سیستم چیزی را به وی گوشزد می‌کنند و به همین دلیل هم هست که اثربخش‌تر هستند (مثلاً وقتی که در یکی از فیلدهای فرمی کلیک می‌کنیم و پیامی درمعرض دیدمان قرار می‌گیرد، این پیام نوعی Hint است).
راه‌کار دیگری که برای جلوگیری از وقوع ارورها می‌توان اتخاذ کرد این است که مثلاً در فیلدهای یک فرم از مقادیر دیفات (پیش‌فرض) استفاده کرد؛ در همان مثال فیلد مرتبط با تاریخ، می‌توان تاریخ روز را به‌صورت مقدار پیش‌فرض درنظر گرفت و این درحالی است که اگر تاریخ مدنظر کاربر تاریخ همان روز باشد که آن‌را دست‌نخورده باقی می‌گذارد و در غیر این صورت، می‌داند که فرمت مدنظر سیستم چیست و چگونه دیتا را می‌بایست وارد کند.
به‌طورکلی، دولوپرها پیش از هرچیز می‌بایست به این درک برسند که کاربران هدفشان چگونه فکر می‌کنند و بر همین اساس هم سیستم را مطابق به نحوهٔ فکر کردن اکثر کاربران هدف طراحی کنند و همین مسأله منجر به بروز پیام‌های خطای کمتر و درنتیجه تجربهٔ کاربری بهتر از جانب کاربران می‌گردد.