کاربر پیامی می‌نویسد و دکمه ارسال را می‌زند. متن داخل حباب ظاهر می‌شود، اما معلوم نیست پیام به سرور رسیده، مخاطب آن را دریافت کرده یا ارسال هنوز در جریان است. رابط گفت‌وگو با چند حباب و یک کادر متن کامل نمی‌شود. بخش مهم طراحی، توضیح وضعیت‌ها و حفظ پیوستگی مکالمه است؛ فرد باید بداند چه چیزی رخ داده و در صورت مشکل چگونه ادامه دهد.
گفت‌وگوی پشتیبانی، پیام‌رسان گروهی و چت‌بات آموزشی نیازهای متفاوتی دارند. در پشتیبانی، سابقه مسئله و انتقال به کارشناس مهم است. در گروه، هویت فرستنده و پاسخ به پیام مشخص اهمیت دارد. در چت‌بات، دامنه توانایی و محدودیت پاسخ باید روشن باشد. پیش از طراحی ظاهر، نوع مکالمه و کاری را که قرار است در آن انجام شود مشخص کنید.
هویت طرف گفت‌وگو را روشن نگه دارید
در ابتدای مکالمه معلوم باشد مخاطب انسان است، سامانه خودکار است یا ترکیبی از هر دو. تصویر چهره و نام انسانی برای پاسخ خودکار، اگر ماهیت آن توضیح داده نشود، می‌تواند انتظار نادرستی ایجاد کند. لحن دوستانه با شفافیت سازگار است. سامانه می‌تواند نام و شخصیت داشته باشد، ولی نباید پاسخ خودکار را به حضور واقعی کارشناس نسبت دهد.
در مکالمه گروهی، رنگ حباب به‌تنهایی برای تشخیص فرستنده کافی نیست. نام، ترتیب و در صورت نیاز تصویر یا علامت نقش کمک می‌کنند. پیام‌های پشت سر هم از یک فرد می‌توانند گروه‌بندی شوند، اما مرز تغییر فرستنده باید دیده شود. اگر کارشناس عوض می‌شود، این تغییر را در سابقه نشان دهید تا کاربر تصور نکند همان فرد تمام پاسخ‌ها را نوشته است.
مراحل ارسال را از هم جدا کنید
نمایش محلی متن به معنی دریافت آن توسط طرف مقابل نیست. وضعیت «در حال ارسال» باید از «ارسال شد» و «خوانده شد» جدا باشد. هرکدام به رویدادی واقعی در زیرساخت نیاز دارند. اگر محصول رسید خواندن ندارد، آن را از روی آنلاین بودن یا باز بودن صفحه حدس نزنید. نام وضعیت باید به چیزی اشاره کند که سامانه واقعاً تأیید کرده است.
در شکست ارسال، متن را حفظ کنید و راه تلاش دوباره بدهید. تکرار درخواست نباید بی‌خبر دو نسخه از یک پیام بسازد؛ این مسئله به شناسه پیام و قرارداد سرور هم مربوط است. رابط بهتر است وضعیت همان پیام را تغییر دهد، نه اینکه حباب شکست‌خورده را حذف و متن را گم کند. اگر فرد امکان ویرایش پیش از ارسال دوباره دارد، حدود این رفتار باید معلوم باشد.
نشانگر تایپ را با واقعیت هماهنگ کنید
نشانگر «در حال نوشتن» وقتی مفید است که به وضعیت شناخته‌شده طرف مقابل مربوط باشد و پس از مدت منطقی متوقف شود. باقی ماندن آن بعد از قطع اتصال انتظار بی‌پایان ایجاد می‌کند. برای پاسخ خودکار، بهتر است «در حال آماده‌سازی پاسخ» بنویسید، اگر همین مرحله واقعاً در جریان است. وانمود کردن به تایپ انسانی برای طولانی کردن مصنوعی زمان انتظار، اطلاعات مفیدی اضافه نمی‌کند.
اگر پاسخ زمان بیشتری می‌خواهد، خبر کوتاه درباره مرحله کار و امکان لغو می‌تواند مناسب باشد. زمان پایان را بدون داده معتبر وعده ندهید. در پاسخ جریانی، مخاطب باید بداند متن هنوز کامل نشده است. اگر تولید قطع می‌شود، همان نسخه ناقص با وضعیت روشن باقی بماند و راه ادامه یا درخواست دوباره مشخص باشد. سکوت رابط پس از توقف ناگهانی، کاربر را به حدس زدن وادار می‌کند.
کادر نوشتن قرارداد قابل پیش‌بینی می‌خواهد
رفتار Enter و ترکیب کلیدها را تعیین کنید. در بعضی محصولات Enter پیام را می‌فرستد و Shift همراه Enter خط تازه می‌سازد؛ در برخی دیگر، Enter فقط خط تازه است. این قرارداد را با نوع مکالمه و نیاز متن بلند انتخاب کنید و نزدیک کادر توضیح دهید. هنگام ترکیب حروف با روش‌های ورودی، ارسال نباید پیش از پایان نوشتن رخ دهد. دکمه ارسال هم باید نام روشن داشته باشد.
برای متن چندخطی، رشد کادر را محدود اما قابل استفاده نگه دارید. اگر ارتفاع زیاد شد، اسکرول داخلی و محل دکمه باید منطقی بمانند. طول مجاز پیام را پیش از رسیدن به خطا اعلام کنید. پس از ارسال موفق، پاک شدن کادر قابل انتظار است؛ پس از شکست، حفظ متن اهمیت دارد. پیش‌نویس محلی نیز سیاست نگهداری می‌خواهد، به‌ویژه اگر دستگاه مشترک باشد یا پیام اطلاعات خصوصی داشته باشد.
اسکرول تازه نباید مطالعه سابقه را قطع کند
وقتی فرد انتهای مکالمه است، دنبال کردن پیام جدید می‌تواند طبیعی باشد. وقتی در حال خواندن پیام‌های قدیمی است، پریدن خودکار به پایین مسیر مطالعه را از بین می‌برد. در این موقعیت، نشان دادن خبر «پیام تازه» و کنترل رفتن به انتها مناسب‌تر است. موقعیت اسکرول را بر اساس رفتار واقعی فرد حفظ کنید؛ صرف ورود یک پیام جدید دلیل کافی برای تغییر محل مشاهده نیست.
دریافت پیام‌های قدیمی در بالای فهرست هم باید با حفظ موقعیت همراه باشد. اضافه شدن چندین ردیف نباید متن زیر نگاه کاربر را جابه‌جا کند. زمان و مرز روزها کمک می‌کند سابقه قابل مرور بماند، ولی تکرار زمان کنار هر جمله همیشه لازم نیست. برای مکالمه طولانی، جستجو و رفتن به پیام مرتبط می‌تواند از اسکرول دستی مفیدتر باشد؛ راهنمای طراحی جستجو درباره حفظ ورودی و نتیجه توضیح دارد.
دریافت پیام باید قابل دسترس باشد
تکنیک role=log در W3C برای اطلاعاتی که به ترتیب افزوده می‌شوند، از جمله سابقه گفت‌وگو، توضیح ارائه می‌کند. اعلام پیام تازه باید با شدت مناسب انجام شود و کل سابقه هر بار دوباره خوانده نشود. محتوای پیام، نام فرستنده و جایگاه آن باید ساختار قابل فهم داشته باشند. صرف گذاشتن متن در یک div رنگی این رابطه‌ها را مشخص نمی‌کند.
focus را بعد از هر پیام دریافتی جابه‌جا نکنید؛ کاربر ممکن است در حال نوشتن باشد. وضعیت ارسال و انتظار نیز می‌تواند بدون گرفتن focus اعلام شود. راهنمای Status Messages درباره این خبرها توضیح دارد. اعلان‌های فراوان می‌توانند محیط را شلوغ کنند، پس نوع تغییر و نیاز واقعی را تعیین کنید. دسترس‌پذیری هم به نام کنترل‌ها وابسته است و هم به رفتار جریان مکالمه.
چت‌بات باید مرز توانایی خود را بیان کند
در شروع، چند نمونه از کارهایی که سامانه انجام می‌دهد نشان دهید. پیشنهاد سؤال باید به قابلیت واقعی وصل باشد؛ دکمه‌ای که بعداً جواب نامرتبط می‌گیرد اعتماد را کم می‌کند. پاسخ «نمی‌دانم» یا «این اطلاعات را ندارم» در موقعیت مناسب از پاسخ قطعی بدون پشتوانه بهتر است. برای اطلاعات وابسته به زمان یا حساب، سامانه باید منبع و حدود دسترسی را در نظر بگیرد.
Quick Reply می‌تواند نوشتن را کم کند، اما مسیر بیان مسئله خارج از گزینه‌ها را مسدود نکند. اگر کاربر گزینه نامناسبی انتخاب کرده، راه اصلاح یا بازگشت لازم است. فرم و گفت‌وگو را نیز می‌توان ترکیب کرد: انتخاب زمان یا وارد کردن چند داده ساختاریافته ممکن است با کنترل‌های مشخص آسان‌تر باشد. تبدیل هر ورودی به یک سؤال جدا می‌تواند مکالمه را طولانی و مرور پاسخ‌ها را دشوار کند.
انتقال به انسان باید عملی باشد
اگر مسیر پشتیبانی انسانی وجود دارد، زمان دسترسی و وضعیت صف را روشن کنید. دکمه «ارتباط با کارشناس» نباید فقط مکالمه خودکار دیگری باز کند. فرد بهتر است بداند چه بخش‌هایی از سابقه برای کارشناس فرستاده می‌شود. انتقال مناسب جلوی تکرار بی‌دلیل توضیح مسئله را می‌گیرد، ولی اشتراک‌گذاری داده باید محدود به نیاز همان پشتیبانی باشد.
وقتی کارشناس حاضر نیست، مسیر جایگزین مانند ثبت درخواست با توضیح زمان پیگیری ارائه کنید؛ زمان پاسخ را بدون تعهد واقعی وعده ندهید. پس از انتقال، نام یا نقش پاسخ‌دهنده و پایان مکالمه باید معلوم باشد. بستن پنجره گفت‌وگو با پایان درخواست یکی نیست. کاربر باید بتواند بداند مسئله هنوز باز است یا رسیدگی تمام شده و سابقه را از کجا دنبال کند.
محتوای خصوصی و فایل‌های پیوست
پیش از بارگذاری فایل، نوع و اندازه مجاز را بیان کنید و وضعیت پیشرفت را جدا از ارسال پیام نشان دهید. نام فایل برای شناسایی مفید است، اما محتوا نباید پیش از موفقیت بارگذاری به عنوان پیوست ارسال‌شده معرفی شود. در خطا، امکان حذف یا تلاش دوباره فراهم باشد. پیام‌ها و فایل‌ها نیز نیاز به سیاست دسترسی، نگهداری و حذف دارند که باید با قرارداد محصول هماهنگ باشد.
در پایان طراحی، مسیر یک پیام را از نوشتن تا ارسال، شکست، دریافت و ادامه مکالمه مرور کنید. روی صفحه کوچک، کادر و دکمه‌ها باید با صفحه‌کلید نرم‌افزاری قابل استفاده بمانند. برای خبرهای بیرون از جریان گفت‌وگو، راهنمای اعلان‌ها مکمل این تصمیم‌هاست. رابط مکالمه زمانی قابل اعتماد است که وضعیت واقعی را روشن نگه دارد و اطلاعات فرد را در جریان ادامه کار حفظ کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!