بعد از فشردن دکمه ثبت، کاربر باید بداند درخواست واقعاً دریافت شده، خطا خورده یا نتیجه هنوز نامعلوم است. پیام تشکر عمومی برای هر سه حالت مناسب نیست. رسید را فقط پس از ثبت معتبر نشان دهید و برای خطا، اقدام بعدی قابل فهم بدهید؛ ظاهر موفق نباید نبود ثبت را پنهان کند.
چهار حالت اصلی را طراحی کنید
آماده ارسال، در حال ارسال، ثبت موفق و نتیجه ناموفق یا نامعلوم را جدا بنویسید. حالت در حال ارسال نباید به کاربر بگوید کار تمام شده است. اگر پاسخ سامانه قطع شد، ممکن است نتیجه نامعلوم باشد و لازم است وضعیت بررسی شود. پیشنهاد تکرار فوری بدون این کنترل می‌تواند درخواست مشابه بسازد. جزئیات فنی تشخیص و جلوگیری از تکرار را تیم مسئول پیاده می‌کند؛ متن رابط باید با رفتار واقعی آن هماهنگ باشد.
رسید موفق باید چیزی برای ادامه بدهد
اگر سامانه شناسه معتبر می‌سازد، آن را همراه روش پیگیری نشان دهید. اگر فقط ایمیل مشتری را باز می‌کند، صریح بگویید «پیش‌نویس آماده شد؛ برای ارسال آن را در برنامه ایمیل بفرستید». این حالت ثبت موفق در سایت نیست. عبارت‌هایی مانند درخواست شما به تیم رسید تنها وقتی مجازند که دریافت واقعی تأیید شده باشد. زمان پاسخ هم باید از سیاست عملیاتی معتبر بیاید؛ یک وعده سریع بی‌پشتوانه، گلوگاه بعدی تجربه مشتری است.
پیام خطا باید راه اصلاح مشخص داشته باشد
برای فیلد ناقص، نام همان فیلد و شکل درست را بگویید. برای اختلال مسیر دریافت، کاربر را با خطای خام یا متن نامفهوم تنها نگذارید. مثال آموزشی: «نتیجه ارسال مشخص نشد؛ لطفاً وضعیت همین درخواست را از روش پیگیری بررسی کنید.» این جمله به وجود آن روش وابسته است. اگر روش خودکار ندارید، کانال انسانی واقعی را توضیح دهید و از وعده شماره پیگیری خیالی پرهیز کنید.
اطلاعات واردشده را بی‌دلیل از دست ندهید
در خطای قابل اصلاح، پاک‌شدن همه فیلدها کاربر را مجبور به شروع دوباره می‌کند. رفتار نگهداری و پاک‌سازی داده باید با سیاست سامانه و نوع اطلاعات هماهنگ باشد؛ همه چیز را خودکار در مرورگر ذخیره نکنید. در آزمون، ببینید پیام خطا دیده و خوانده می‌شود و کاربر می‌تواند به فیلد مربوط برسد. وجود رنگ قرمز به‌تنهایی برای فهم نتیجه یا استفاده با ابزار کمکی کافی نیست.
آزمون را با نتیجه واقعی پشت صحنه تطبیق دهید
در محیط آزمایشی از نمونه ساختگی استفاده کنید و حالت ثبت موفق، خطای اعتبارسنجی، اختلال سرویس و کلیک دوباره را بررسی کنید. برای هر حالت، رکورد ساخته‌شده و پیام رابط باید یک معنا داشته باشند. اگر رابط موفق می‌گوید ولی رکوردی وجود ندارد، مشکل فقط متن نیست. این مقاله درباره طراحی عمومی رسید است و بررسی یا تعمیر فرم واقعی هیچ سایت را گزارش نمی‌کند؛ تغییر عملی هم نیازمند مجوز و آزمون همان سامانه است.
ماتریس حالت ارسال فرم؛ نمونه آموزشی
داده‌های جدول زیر ساختگی‌اند و نتیجه اجرای واقعی هیچ محصولی نیستند. آن‌ها را برای تمرین تیم به کار ببرید و قواعد اجرایی را با مسئول همان فرایند تأیید کنید.
| حالت آموزشی | پیام مناسب مشروط | مدرک لازم | قدم بعد |
|---|---|---|---|
| پیش‌نویس ایمیل | هنوز باید ارسال کنید | فقط متن آماده شده | ارسال توسط کاربر |
| در حال ارسال | لطفاً منتظر نتیجه بمانید | پاسخ نهایی نیامده | جلوگیری از اقدام مبهم |
| ثبت موفق | درخواست با شناسه معتبر دریافت شد | ثبت واقعی | روش پیگیری |
| نتیجه نامعلوم | وضعیت نیاز به بررسی دارد | تأیید قطعی نداریم | کنترل پیش از ارسال مجدد |
دانلود ماتریس حالت ارسال فرم با قالب CSV سازگار با اکسل. فایل از داده آموزشی تشکیل شده و اطلاعات مشتری واقعی ندارد. پیش از استفاده عملی، عنوان ستون‌ها و مقادیر مجاز را با سامانه خودتان تطبیق دهید.
منبع و ادامه مسیر
W3C برای فرم‌ها اعلام روشن موفقیت، خطا و روش اصلاح را توضیح می‌دهد. User Notification. این ارجاع، روش اختصاصی این مقاله یا قابلیت اپرا را گواهی نمی‌کند؛ روش و مثال‌های بالا پیشنهاد تحریریه برای طراحی و آزمون هستند.
برای زمینه مرتبط، پیش از ارجاع به پشتیبان فنی چه اطلاعاتی از مشتری بگیریم؟ و وقتی CRM قطع است، درخواست‌های مشتری را چگونه ثبت کنیم؟ را بخوانید. اگر دنبال راهکار اجرایی هستید، بسته‌ها و مسیر درخواست پیشنهاد اپرا را بررسی کنید؛ امکان اجرای سناریوی خود را با تیم فروش مشخص کنید. انتخاب بسته به معنی ثبت خودکار درخواست، صدور فاکتور یا فعال‌شدن فوری خدمت نیست.
راهنماهای مرتبط با این مسئله
ثبت شد با اطلاع داده شد فرق دارد؛ دو وضعیت جدا در CRM و داده ناموجود را صفر نگذاریم؛ نمایش درست شکاف گزارش تماس می‌توانند گام بعدی بررسی تیم شما باشند.