این مقاله با کمک هوش مصنوعی تهیه شده است. نمونه‌های UI اختصاصی و فرضی‌اند؛ نتیجهٔ تست کاربری یا عملکرد مشتری ادعا نمی‌شود.
از کار واقعی شروع کنیم، نه از کادر پیام
محصولی که بر پایهٔ هوش مصنوعی طراحی می‌شود، باید روش انجام یک کار را بهتر کند. صرف اینکه بتوان از آن سؤال پرسید، کافی نیست. یک معیار پیشنهادی ما این است: اگر گفت‌وگو را موقتاً کنار بگذاریم، آیا محصول هنوز برداشت روشنی از خواستهٔ کاربر، وضعیت قابل‌فهمی از پیشرفت و راه مشخصی برای تمام‌کردن کار دارد؟ اگر نه، احتمالاً هوش مصنوعی بیشتر به ظاهر تجربه اضافه شده تا به منطق آن.
یک دستیار فرضی برای پیدا‌کردن خانه را در نظر بگیریم. جملهٔ «یک جای آرام نزدیک محل کار می‌خواهم» هم هدف دارد، هم ترجیح، هم اطلاعات ناقص. یک جواب خوش‌بیان هنوز نتیجهٔ مفیدی نیست. تجربهٔ بهتر، برداشت سیستم را نشان می‌دهد، مهم‌ترین ابهام را می‌پرسد و امکان مقایسهٔ انتخاب‌ها را فراهم می‌کند.
هوش مصنوعی کجا واقعاً ارزش دارد؟
قبل از طراحی صفحه، کار فعلی، اطلاعات موجود و هزینهٔ اشتباه را بنویسید. راهنمای People + AI گوگل پیشنهاد می‌کند بررسی کنیم آیا هوش مصنوعی ارزش منحصربه‌فردی به مسئله اضافه می‌کند یا نه. [1] چارچوبی که در ادامه می‌بینید، پیشنهاد تحریریه برای طراحی است؛ نتیجهٔ اندازه‌گیری یک پروژهٔ مشتری نیست.
در مثال جست‌وجوی خانه، فهمیدن یک ترجیح مبهم می‌تواند کار مناسبی برای مدل باشد. محاسبهٔ کارمزد ثابت معمولاً به قواعد قطعی نیاز دارد. بررسی موجودبودن یک ملک به منبع دادهٔ معتبر وابسته است. ارسال درخواست بازدید هم یک اقدام واقعی است که مخاطب و اجازهٔ روشن می‌خواهد. اگر همهٔ این‌ها را داخل یک پاسخ روان پنهان کنیم، مسئولیت هر بخش نامشخص می‌شود.
برداشت سیستم باید قابل اصلاح باشد
خواسته را به یک خلاصهٔ کوتاه تبدیل کنید: محدوده، بودجه، شرط‌های ضروری، ترجیح‌ها و سؤال‌های باز. چیزی را که کاربر گفته از چیزی که سیستم حدس زده جدا کنید. «محلهٔ آرام» یک ترجیح اعلام‌شده است؛ «دورکاربودن» تا وقتی کاربر نگفته، یک فرض است.
در نمونهٔ تعاملی این مقاله، بودجه قبل از هر تأییدی قابل تغییر است. قرار نیست استدلال درونی مدل را نمایش دهیم؛ باید برداشت عملیاتی محصول را روشن کنیم، یعنی همان اطلاعات و انتخاب‌هایی که قدم بعدی را تعیین می‌کنند. اصلاح یک شرط نباید کاربر را مجبور کند همهٔ درخواست را دوباره بنویسد یا گزینه‌های ذخیره‌شده‌اش را از دست بدهد.
چت به‌جای تمام رابط
خواسته، محدودیت‌ها و مرحلهٔ بعد، میان پیام‌ها پخش شده‌اند.
فضای کاری حول نیاز کاربر
معیارهای قابل ویرایش، فهرست روشن و بازبینی پیش از اقدام.
از خواسته تا تأیید
کنترل‌ها را امتحان کنید. این نمونهٔ تعاملی با دادهٔ فرضی، فقط داخل مرورگر کار می‌کند.
خانه‌ای آرام‌تر، نزدیک‌تر به محل کار
- بودجهٔ سالانه
- ۱۲۰٬۰۰۰ درهم
- محدوده
- نزدیک محل کار؛ مکان هنوز مشخص نیست
- فرض سیستم
- آرام یعنی دور از خیابان اصلی؛ نیازمند تأیید شما.
برای شواهد هم جا طراحی کنیم
پیشنهاد باید معاملهٔ اصلی را با زبان همان کار توضیح دهد. مثلاً یک کارت ملک می‌تواند بگوید با بودجه هماهنگ است، اما زمان رفت‌وآمدش هنوز تأیید نشده. این دو گزاره نباید ظاهر یکسانی داشته باشند. دادهٔ دریافت‌شده، برداشت سیستم و اطلاعات ناموجود، سه وضعیت متفاوت‌اند.
پژوهش تعامل انسان و هوش مصنوعی مایکروسافت، رفتار سیستم را در شروع، حین استفاده، هنگام اشتباه و در طول زمان بررسی می‌کند. [2] برداشت ما این است که سطح اصلاح خطا باید هم‌زمان با پاسخ موفق طراحی شود. جملهٔ «امکان بررسی موجودبودن فراهم نشد» از یک ادعای مطمئن با هشدار مبهم در پایین صفحه مفیدتر است.
پیشنهاد با اقدام یکی نیست
ساختن فهرست پیشنهادی و ارسال پیام به مشاور، دو وضعیت جدا هستند. اولی به تصمیم کمک می‌کند؛ دومی با فرد دیگری تماس می‌گیرد. کارت بازبینی باید مخاطب، متن پیام و عمل نهایی را روشن نشان دهد. پیش‌نویسِ قابل ویرایش، پیام ارسال‌شده نیست؛ پیام تأییدشده هم لزوماً تحویل داده نشده است.
این نمونه فقط با دادهٔ نمایشی داخل مرورگر کار می‌کند. می‌توانید متن را بازبینی، بودجه را اصلاح و اقدام را تأیید یا ریست کنید. هیچ پیامی واقعاً ارسال نمی‌شود. محصول واقعی علاوه بر این، به رسید تحویل، وضعیت شکست و روش تلاش دوباره بدون ارسال تکراری نیاز دارد.
کل مسیر تحویل کار را بسنجیم
پاسخ جذاب ممکن است هنوز قسمت سخت کار را روی دوش کاربر بگذارد. در تست ببینید آیا فرد می‌تواند یک فرض اشتباه را پیدا کند، آن را تغییر دهد، دو گزینه را مقایسه کند و بدون شروع دوباره به مرحلهٔ بعد برسد. قطع‌شدن جلسه و در دسترس نبودن منبع داده را هم وارد سناریو کنید.
اتمام کار، اصلاح موفق، رهاکردن مرحلهٔ بازبینی و اقدام تکراری می‌توانند شاخص‌های مفیدی باشند. تعریف هر رویداد و داده‌ای که جمع می‌شود باید از قبل مشخص باشد. طول گفت‌وگو یا تعداد پاسخ‌های تولیدشده، به‌تنهایی نشانهٔ بهترشدن تجربه نیست. برای این نمونه هیچ بهبود عملکردیِ اندازه‌گیری‌شده‌ای ادعا نمی‌کنیم.
یک بریف کاربردی برای شروع
یک کار مشخص را از ابتدا تا انتها انتخاب کنید. بنویسید سیستم چه چیزهایی را می‌تواند برداشت کند، کدام اطلاعات منبع لازم دارند و چه اقدام‌هایی باید تأیید شوند. قبل از پرداختن به ظاهر چت، برداشت، مقایسه، بازبینی و خطا را طراحی کنید.
این کار به تیم چیزی واقعی برای ساختن و آزمودن می‌دهد. هدف، دستیاری نیست که فقط طبیعی‌تر حرف بزند؛ محصول باید نیت مبهم را به نتیجه‌ای قابل‌فهم و تحت کنترل تبدیل کند. در مقالهٔ بعدی بررسی می‌کنیم وقتی وضعیت مشترک کار گم می‌شود، سفر کاربر چگونه می‌شکند.
منابع و یادداشت‌های تحریریه
منابع در ۲۲ اکتبر ۲۰۲۶ بررسی شدند. پیشنهادهای اجرایی و نمونه‌های این مقاله، تفسیر تحریریه‌اند؛ تأیید یا همکاری صاحبان منابع با ما را القا نمی‌کنند.
برای طراحی یک تجربهٔ روشن‌تر، از مسئلهٔ واقعی شروع کنیم.
دربارهٔ پروژه صحبت کنیم
