تجربه کاربری هوش مصنوعی از جایی اهمیت پیدا میکند که دستیار نمی‌تواند پاسخ دهد. در این لحظه، رابط کاربری تعیین میکند کاربر سردرگم شود یا راه بعدی را پیدا کند. یک کادر متن و یک دکمه‌ی ارسال برای تجربه‌ی خوب کافی نیست.
کاربر باید بداند سیستم چه اطلاعاتی دارد، چه کاری انجام می‌دهد و چطور می‌توان پاسخ اشتباه را اصلاح کرد. در این قسمت از مجموعه‌ی آموزش هوش مصنوعی تخته سبز، اصول طراحی تجربه‌ی کاربری را برای یک دستیار آموزشی مرور می‌کنیم و آن‌ها را به حالت‌های مشخص رابط کاربری تبدیل می‌کنیم.
تجربه کاربری در برنامه‌های هوش مصنوعی چیست؟
تجربه کاربری یعنی نحوه‌ی تعامل و استفاده‌ی کاربر از یک محصول. در برنامه‌های هوش مصنوعی، سازندگان فقط به کارآمد بودن فکر نمی‌کنند؛ اخلاقی بودن تجربه هم اهمیت دارد. برنامه باید برای همه قابل استفاده باشد و کاربر را به تصمیمهای اشتباه سوق ندهد.
کاربران را بشناسید
یک مجموعه‌ی آموزشی دو گروه کاربر اصلی دارد: مدرسان و دانشجویان. هر گروه نیازهای خاص خودش را دارد. مدرس می‌خواهد کارهای تکراری مثل ارزیابی سریع‌تر شود. دانشجو می‌خواهد راهنمایی متناسب با سطح و زمانش بگیرد.
طراحی کاربرمحور یعنی کاربر را در مرکز تصمیم‌ها قرار دهید. محصولی که برای «همه» طراحی شود، معمولاً برای هیچ‌کس خوب کار نمی‌کند. پیش از طراحی هر صفحه، بپرسید این صفحه برای کدام کاربر و کدام کار است.
چهار ویژگی تجربه‌ی خوب
برنامه برای تجربه‌ی خوب باید چهار ویژگی داشته باشد. مفید بودن یعنی قابلیت‌هایش با هدفش جور باشد. برنامه‌ای که ارزیابی را خودکار میکند، باید نمره‌ها را دقیق و سریع ثبت کند.
قابلیت اطمینان یعنی برنامه کارش را مداوم و بی‌خطا انجام دهد. هوش مصنوعی مثل انسان کامل نیست؛ پس برنامه باید برای خطا و موقعیت غیرمنتظره آماده باشد و در صورت لزوم انسان را وارد کار کند.
دسترس‌پذیری یعنی تجربه برای کاربران با توانایی‌های مختلف، از جمله افراد دارای معلولیت، قابل استفاده باشد. خوشایند بودن هم یعنی استفاده از برنامه لذت‌بخش باشد تا کاربر دوباره برگردد.
یک نکته را هم فراموش نکنید: هر مشکلی را نمی‌شود با هوش مصنوعی حل کرد. هوش مصنوعی برای تقویت تجربه می‌آید، مثل خودکارسازی کارهای دستی یا شخصی‌سازی؛ نه برای جایگزینی فکر درباره‌ی نیاز کاربر.
طراحی برای اعتماد و شفافیت
اعتماد در برنامه‌های هوش مصنوعی حیاتی است. کاربر باید مطمئن باشد برنامه کارش را انجام می‌دهد و نتیجه همان چیزی است که لازم دارد. اما دو خطر در این حوزه وجود دارد: بی‌اعتمادی و اعتماد بیش از حد.
بی‌اعتمادی یعنی کاربر به سیستم اعتماد نمی‌کند و آن را کنار می‌گذارد. اعتماد بیش از حد یعنی کاربر توانایی سیستم را بیش از واقعیت می‌داند. مثلاً مدرسی که بدون بررسی به نمره‌دهی خودکار اعتماد کند، ممکن است دانشجویی را ناعادلانه مردود کند. دو ابزار اصلی برای تنظیم درست اعتماد وجود دارد: وضوح و کنترل.
وضوح؛ کاربر بداند چه اتفاقی می‌افتد
وقتی هوش مصنوعی در تصمیمی مثل آموزش نقش دارد، مدرسان و والدین باید بفهمند سیستم چطور تصمیم می‌گیرد. نشان‌دادن منبع پاسخ یکی از ساده‌ترین راه‌هاست. اگر دستیار دوره‌ای پیشنهاد می‌دهد، بگوید بر اساس کدام اطلاعات این کار را کرده است.
بخش دیگر وضوح، توضیح ساده‌ی محدودیت‌هاست. مثلاً دستیار آموزشی ممکن است جواب تمرین را مستقیم نگوید، اما به دانشجو کمک کند خودش به جواب برسد. کاربران متخصص هوش مصنوعی نیستند. پس توضیح اینکه برنامه چه میکند و چه نمی‌کند، باید ساده و قابل‌فهم باشد.
کنترل؛ کاربر بتواند تغییر دهد
هوش مصنوعی مولد یک همکاری میان سیستم و کاربر است. کاربر باید بتواند درخواستش را تغییر دهد و خروجی را ویرایش کند تا حس کنترل داشته باشد. دستیاری که پاسخش قابل ویرایش یا بازتولید نیست، کاربر را منفعل میکند.
کنترل بر داده هم بخشی از همین اصل است. کاربر باید بتواند تصمیم بگیرد آیا یادداشت‌ها و اطلاعاتش برای شخصی‌سازی استفاده شوند یا نه. گزینه‌ی روشن برای موافقت یا مخالفت با استفاده از داده، اعتماد را بالا می‌برد.
اصطکاک عمدی
گاهی کمی اصطکاک در طراحی مفید است. یادآوری کوتاه اینکه «این پاسخ را هوش مصنوعی تولید کرده و ممکن است خطا داشته باشد» کاربر را به بررسی دوباره تشویق میکند. هدف این نیست که کاربر را بترسانید؛ هدف این است که انتظارش واقع‌بینانه بماند.
این اصطکاک باید متناسب با ریسک باشد. برای پیشنهاد یک مقاله، یک برچسب کوچک کافی است. برای تصمیمی مثل ثبت‌نام یا پرداخت، مرحله‌ی تأیید صریح لازم است.
طراحی برای همکاری و بازخورد
بیشتر تعامل‌ها با هوش مصنوعی ساده است: کاربر درخواست می‌دهد و سیستم پاسخ تولید میکند. اما اگر پاسخ نادرست باشد چه؟ برنامه با خطا چطور برخورد میکند؟ آیا کاربر را مقصر می‌داند یا راه ساده‌ای برای اصلاح می‌گذارد؟
حلقه‌ی بازخورد
برنامه‌ی هوش مصنوعی باید برای دریافت بازخورد ساخته شود. ساده‌ترین شکل، دکمه‌ی موافق و مخالف کنار هر پاسخ است. این بازخورد هم به بهبود سیستم کمک میکند و هم به کاربر نشان می‌دهد نظرش مهم است.
بازخورد را فقط جمع نکنید؛ از آن استفاده کنید. پاسخ‌هایی که بازخورد منفی گرفته‌اند، بهترین منبع برای مجموعه‌ی آزمون بعدی شما هستند؛ همان چرخه‌ای که در قسمت ارزیابی ایجنت دیدیم.
مدیریت خطا و محدودیت
راه دیگر، بیان روشن توانایی‌ها و محدودیت‌هاست. فرض کنید دستیار فقط با داده‌ی درس‌های تاریخ و ریاضی آموزش دیده و کاربر درباره‌ی جغرافیا می‌پرسد. پاسخ خوب این نیست که دستیار چیزی سرهم کند. پاسخ خوب این است که صادقانه بگوید این موضوع خارج از دامنه‌اش است و قدم بعدی را پیشنهاد دهد.
محدودیت‌های فنی هم وجود دارد؛ مثلاً سقف تعداد پرسش یا طول متن قابل خلاصه‌سازی. پیام خطا باید ساده بگوید چه شده، چرا شده و کاربر حالا چه کاری می‌تواند بکند. جدول زیر تفاوت پیام خوب و بد را نشان می‌دهد.
| موقعیت | پیام ضعیف | پیام خوب |
|---|---|---|
| پرسش خارج از دامنه | «خطا رخ داد» | «من فقط درباره‌ی دوره‌های همین مرکز اطلاعات دارم؛ می‌خواهید فهرست دوره‌ها را ببینید؟» |
| متن بیش از حد طولانی | «درخواست نامعتبر است» | «این متن برای خلاصه‌سازی طولانی است؛ لطفاً آن را در دو بخش بفرستید.» |
| نبود اطلاعات کافی | پاسخ حدسی بدون اعلام | «زمان آزادتان را نگفتید؛ با فرض دو ساعت در روز برنامه چیدم. تغییرش می‌دهید؟» |
| قطعی سرویس | صفحه‌ی خالی | «پاسخ‌گویی فعلاً ممکن نیست؛ چند دقیقه‌ی دیگر دوباره امتحان کنید.» |
چهار حالت رابط دستیار
از همه‌ی این اصول می‌توان به یک نتیجه‌ی عملی رسید. رابط هر دستیار دست‌کم چهار حالت دارد که باید جداگانه طراحی شوند. بیشتر محصولات فقط حالت دوم را طراحی می‌کنند و بقیه را به شانس می‌سپارند.
انتظار و پاسخ با منبع
در حالت انتظار، کاربر باید بداند سیستم در حال کار است. پیام‌هایی مثل «در حال جستجو در فهرست دوره‌ها» بهتر از یک چرخ‌دنده‌ی بی‌معناست. برای پاسخ‌های طولانی، نمایش تدریجی متن هم حس انتظار را کم میکند.
در حالت پاسخ، پیشنهاد همراه منبع و فرض‌ها نمایش داده شود. اگر دستیار فرضی کرده، آن فرض قابل دیدن و قابل تغییر باشد. دکمه‌های کوچکی مثل «ساده‌تر بگو» یا «منبع را نشان بده» کنترل را به کاربر می‌دهند.
خطا، اصلاح و دسترس‌پذیری
حالت خطا باید صادقانه و کمک‌کننده باشد، همان‌طور که در جدول دیدیم. حالت اصلاح هم به کاربر اجازه می‌دهد ورودی را تغییر دهد، بی‌آنکه گفت‌وگو را از اول شروع کند.
همه‌ی این حالت‌ها باید دسترس‌پذیر باشند. برنامه با صفحه‌کلید قابل استفاده باشد، با صفحه‌خوان کار کند و پیام‌های وضعیت برای فناوری‌های کمکی اعلام شوند. روی تلفن همراه هم متن خوانا بماند و دکمه‌ها به‌اندازه‌ی کافی بزرگ باشند.
سناریوی عملی؛ دانشجویی که نظرش را عوض میکند
دانشجویی با تلفن همراه درباره‌ی دوره‌ی مناسب سؤال میکند. دستیار پیشنهادی می‌دهد. بعد دانشجو می‌گوید «فقط آخر هفته‌ها وقت دارم». حالا دستیار باید چه کند؟
ورودی و اقدام مورد بررسی
ورودی آزمون سه بخش دارد: درخواست اولیه، تغییر ترجیح کاربر و یک سند مرجع کوتاه از برنامه‌ی دوره‌ها. یک نمونه‌ی عادی و یک نمونه‌ی ناقص آماده کنید؛ مثلاً حالتی که هیچ دوره‌ای آخر هفته برگزار نمی‌شود.
اقدام مورد بررسی سه بخش دارد: نمایش پیشنهاد، نمایش منبع پاسخ و راه اصلاح اطلاعات ورودی. معیار پذیرش هم خوانایی روی تلفن همراه، دسترسی کامل با صفحه‌کلید و روشن بودن حالت انتظار است.
نمونه‌ی شکست؛ پاسخ کهنه
شکستی که باید عمداً دنبالش بگردید این است: دستیار بعد از تغییر ترجیح، همان پیشنهاد قبلی را نشان دهد و نگوید با شرط جدید سازگار نیست. کاربر فکر میکند دوره‌ی پیشنهادی آخر هفته است و ثبت‌نام میکند.
این خطا بیشتر به طراحی رابط مربوط است تا مدل. رابط باید وقتی شرط تغییر کرد، پیشنهادهای قبلی را منقضی نشان دهد یا دوباره بسنجد. این نمونه را در آزمون بگذارید و بعد از هر تغییر، دوباره بررسی کنید.
تمرین عملی؛ طرح مکالمه‌ی کامل
یکی از دستیارهایی که در این مجموعه ساخته‌اید را انتخاب کنید و این چهار کار را انجام دهید:
- خوشایندی: پیام‌های خطا را بازنویسی کنید تا کمک‌کننده باشند، نه سرزنش‌کننده.
- دسترس‌پذیری: بررسی کنید برنامه با صفحه‌کلید به‌طور کامل قابل استفاده است.
- اعتماد: منبع پاسخ و یک یادآوری کوتاه درباره‌ی احتمال خطا اضافه کنید.
- کنترل: گزینه‌ای برای موافقت یا مخالفت با استفاده از داده‌ی کاربر بگذارید.
خروجی نهایی یک طرح مکالمه است که هر چهار حالت انتظار، پاسخ، خطا و اصلاح را نشان می‌دهد. مشخص کنید کدام بخش را پیاده کرده‌اید و کدام هنوز طرح است.
سخن پایانی
تجربه کاربری هوش مصنوعی در لحظه‌های سخت آزموده می‌شود؛ وقتی پاسخی نیست، وقتی خطایی رخ داده یا وقتی کاربر نظرش را عوض کرده است. دستیار خوب مفید، قابل‌اعتماد، دسترس‌پذیر و خوشایند است. با وضوح و کنترل اعتماد را درست تنظیم میکند و با حلقه‌ی بازخورد از خطاهایش یاد می‌گیرد. هر چهار حالت رابط را طراحی کنید، نه فقط حالت پاسخ موفق را.
در قسمت بعد چرخه‌ی عمر برنامه‌ی هوش مصنوعی را می‌بینیم؛ از نمونه‌ی اولیه تا نسخه‌ای که در صورت خطا قابل بازگشت است.
این آموزش بر پایه‌ی درس Designing UX for AI Applications از مجموعه‌ی آزاد Generative AI for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.
پرسش‌های پرتکرار
تجربه کاربری خوب در برنامه‌ی هوش مصنوعی چه ویژگی‌هایی دارد؟
چهار ویژگی اصلی؛ مفید باشد و کار واقعی کاربر را انجام دهد، قابل‌اعتماد باشد و خطاهایش را مدیریت کند، برای همه‌ی کاربران از جمله افراد دارای معلولیت دسترس‌پذیر باشد و استفاده از آن خوشایند باشد.
چطور اعتماد کاربر به دستیار هوش مصنوعی را درست تنظیم کنیم؟
با وضوح و کنترل. توضیح دهید دستیار چطور به پاسخ رسیده و از چه منبعی استفاده کرده، محدودیت‌هایش را ساده بگویید و به کاربر اجازه دهید خروجی را ویرایش کند و درباره‌ی استفاده از داده‌اش تصمیم بگیرد.
اعتماد بیش از حد به هوش مصنوعی چه خطری دارد؟
کاربری که بیش از حد اعتماد کند، خروجی را بدون بررسی میپذیرد و خطاهای مدل به تصمیمهای واقعی او راه پیدا میکند. یادآوری اینکه پاسخ را هوش مصنوعی تولید کرده و نمایش منبع، این خطر را کم میکند.
پیام خطای دستیار هوش مصنوعی چطور باید باشد؟
ساده و صادقانه بگوید چه چیزی ممکن نیست، دلیلش را کوتاه توضیح دهد و قدم بعدی را پیشنهاد کند؛ مثلاً پرسیدن سؤال دیگر یا تماس با پشتیبان انسانی.
دیدگاه‌ها
هنوز دیدگاهی ثبت نشده است. شروع‌کننده باشید — پرسش و اصلاح را با آغوش باز می‌پذیریم.