انواع پیام‌هایی که طراحان تجربه کاربری باید برای طراحی به خاطر بسپارند

این سناریو را در نظر بگیرید که یک کارشناس UX طراحی خود را تمام کرده و با توسعه‌دهندگان شروع به‌کار کرده است. ظاهراً همه‌چیز خوب است و کار را شروع می‌کنند. در حین کار سؤالاتی مطرح می‌شود. اگر کاربر حس خوب خود را از دست بدهد، چه اتفاقی می‌افتد؟ چه پیامی باید به کاربر نشان داده شود تا او مجاب شود که پیشرفت کار موفقیت آمیز بوده است. اگر مشکلی پیش‌آمده باشد چگونه می‌توانیم شرایط کنونی را به کاربران توضیح دهیم؟ چگونه به آنها در ریکاوری یک ارور کمک کنیم؟ خوشبختانه توسعه‌دهنده‌ها برای ایجاد این پیام‌ها با طراح (یا نویسنده UX) همکاری می‌کنند. در بدترین حالت، خودش توسعه‌دهنده‌ها یک متن می‌نویسند و پیام‌های متعدد ممکن است آن را طبیعی نشان دهد.

هنگام کار با سیستم، کاربران شما با انواع مختلفی از پیام‌ها مواجه می‌شوند. شما باید این پیام‌ها را با دقت آماده کنید تا به تجربه کاربران بی افزایید و آنها بتوانند با سیستم ارتباط برقرار کنند نه آنکه صرفاً از آن استفاده کنند. قبلاً در مورد ارورها نوشتم، اما انواع دیگری از پیام‌ها نیز وجود دارد که باید به آنها توجه کنید. این پست پنج نوع پیام را که باید برای طراحی، آنها را به خاطر بسپارید، بیان می‌کند.

پنج نوع پیامی که برای طراحی باید آنها را به خاطر داشته باشید.

1. پیام‌های تایید
2. پیام‌های موفقیت‌آمیز
3. پیام‌های هشداردهنده
4. ارورها
5. پیام‌های سیستمی

پیام‌های تایید

این‌ها پیام‌هایی هستند که نیازمند تأیید کردن کاربر می‌باشد. هنگامی‌ که کاربر یک به‌روزرسانی انجام می‌دهد، عموماً نیازی به نمایش پیام تأیید نیست (مگر اینکه تغییر فاحشی باشد)، اما ممکن است بخواهید آنها را وقتی که یکی از دو مورد زیر صدق می‌کند، نمایش دهید:

• وقتی یک آیتم را حذف می‌کنید (برای مثال : از حذف مطمئن هستید؟)
• سعی می‌کنید از یک صفحه خارج شوید بدون اینکه تغییرات را ذخیره کرده باشید. (برای مثال تغییرات ذخیره شود؟)

از این نوع پیام فقط برای انتقال اطلاعاتی که  باید قبل از اتمام کار تأیید شوند، استفاده کنید. با تأییدهای غیرضروری سرعت عمل را کاهش ندهید.

 

پیام‌های موفقیت‌آمیز

وقتی‌که کاربر تسکی را انجام می‌دهد، گاهی اوقات یک پیام موفقیت‌آمیز نمایش داده می‌شود که تایید می‌کند عملیات/کار با موفقیت انجام‌شده است. مثلاً:

• با موفقیت حذف شد
• به‌روزرسانی شد
• تغییرات ذخیره شد

این‌ها ممکن است به‌عنوان یک بنر در بالای صفحه یا یک دیالوگ توستر نمایش داده شود که بدون دخالت کاربر به‌طور خودکار از بین می‌رود. وقتی وضعیتی تغییر می‌کند این پیام‌ها نمایان می‌شوند تا یک فیدبک از عمل انجام‌شده ارائه دهند. این قابلیت باعث می‌شود از وضعیت سیستم مطلع باشید.

پیام‌های هشداردهنده

هنگامی‌که کاربر سعی می‌کند عملی را انجام دهد که باعث به‌روزرسانی در سایر قسمت‌های سیستم یا تغییرات چشم‌گیر دیگری می‌شود، ممکن است بخواهید از یک مسیج هشدار استفاده کنید. این موارد کاربر را از عواقب عمل خود آگاه می‌کند، که در غیر این صورت ممکن است بلافاصله مشخص نشود. این اعلان‌ها به کاربر اجازه می‌دهد اگر قصد ایجاد چنین تغییری را نداشته باشد، از آن خارج شود. این پیشگیری باعث می‌شود اشتباه نکنید. بااین‌حال، شما نمی‌خواهید این نوع پیام‌ها را بیش‌ازحد ببینید. هشدارهای مداوم می‌تواند تاثیر معکوس داشته باشد، یعنی کاربران آنها را نخوانند و فقط  آنها را تایید کنند. درصورتیکه کمتر از این پیام‌ها استفاده شود کاربر آن را می‌خواند و به آن توجه می‌کند.

پیام‌های ارور

هنگامی‌که یک کاربر به‌روزرسانی را انجام می‌دهد که در سطح فیلد، اسکرین یا بیزینس رول معتبر نیست، سیستم ارور می‌دهد که علت دقیق خطا و اقدامات اصلاحی موردنیاز را مشخص می‌کند. این پیام‌ها به کاربران کمک می‌کند تا خطاها را تشخیص داده و آنها را بازیابی کنند.

درک پیام‌های ارور و اصلاح آنها باید ساده باشد.

پیام‌های سیستمی

در حالت ایده‌آل، یک کاربر به ندرت پیام سیستمی مانند پاسخ HTTP، ارور دیتابیس یا خرابی سیستم را مشاهده می‌کند. این پیام‌ها را به‌ عنوان باگ در نظر بگیرید که برای کدگذاری به‌عنوان یکی از پیام‌های ارور باید هندل شود. مطمئن شوید که ارورهای http رهگیری می‌شوند و به  کاربر توضیح می‌دهند که ارورهای ۴۰۳ (ممنوعیت و عدم دسترسی)، ۴۰۴ (ریسورس وجود ندارد)، ۵۰۳ (سرویس در دسترس نیست) و غیره به چه معناست. این پیام‌ها باید نحوه بازیابی را برای کاربر توضیح دهد (به‌عنوان مثال بعداً دوباره امتحان کنید، املای آنها را بررسی کنید یا در صورت ارور ۴۰۴، سرچ کنید و پیج موردنظر را پیدا کنید.)

دانستن این ۵ پیام، تنها یک مرحله از این فرآیند است. اگر فقط به دنبال انتقال یک حس خوب به کاربر هستید، طراحی شما کامل و آماده تحویل نیست. شما باید در مورد همه سناریوهای احتمالی و اطلاعاتی که سیستم باید ارائه دهد، فکر کنید تا کمکی به کاربران کرده باشید.

به سناریوی مقدماتی برگردیم. یک راه بهتر این است که طراح و تیم در مورد همه پیام‌ها از قبل فکر کرده و با هم همکاری کرده باشند تا به آنها رسیدگی کنند. روشی که تیم ما در حال حاضر کار می‌کند این اطمینان را می‌دهد که سناریوهای کمتری بدون طراحی باقی می‌مانند که در حین کار کشف شوند. آنچه ما انجام می‌دهیم به این صورت است که توسعه‌دهندگان ارورهای فنی را که ممکن است رخ دهد لیست می‌کنند، درحالی‌که QA کمک می‌کند برای تمام حس‌های ناخوشایندی که ممکن است در آن طرح در نظر نگرفته باشد، ایده‌ای داشته باشید. با دانستن این اطلاعات، طراحان می‌توانند پیام‌های موردنیاز خود را به‌راحتی بسازند.

مطمئن باشید که همه پیام‌ها، نه فقط ارورها، بهترین تجربه را در بردارند.