نوشتن متن رابط کاربری فارسی با کمک هوش مصنوعی
متن دکمه، پیام خطا و حالت خالی همان چیزی است که کاربر واقعاً میخواند. قاعدهی سهتکهی پیام خطا، تلهی طول در فارسی، و اینکه مدل کجا کمک میکند و کجا فقط خرابتر میکند.
کاربر روی دکمهی پرداخت میزند، صفحه چند ثانیه میچرخد و یک کادر قرمز بالا میآید: «خطایی رخ داد.» همین. نه معلوم است کدام مرحله شکسته، نه اینکه پول از حساب کم شده یا نه. فردا پشتیبانی سه تماس میگیرد که هر سه یک سؤال دارند: بالاخره سفارشم ثبت شد؟
متن رابط کاربری آخرین چیزی است که نوشته میشود و اولین چیزی که کاربر میخواند. این دقیقاً همان جنس کاری است که مدل زبانی در آن خوب است — بازنویسی جملههای کوتاه با محدودیت مشخص — ولی اگر بدون قاعده سراغش بروید، بهجای «خطایی رخ داد» یک جملهی بلندِ مؤدبِ همانقدر بیفایده تحویل میگیرید.
«خطایی رخ داد» یعنی «نمیخواهم توضیح بدهم»
این جمله از بلوک catch میآید: قطع شدن اینترنت، رد شدن کارت، خالی بودن یک فیلد و تایماوت درگاه، همه به یک رشتهی واحد ختم شدهاند. برای برنامهنویس صرفهجویی است، برای کاربر یک در بسته. ضررش هم دیده نمیشود چون کاربر شکایت نمیکند، میرود؛ شما در گزارش فقط نرخ ترک بالا را میبینید بیآنکه بدانید علتش یک جملهی چهارکلمهای بوده. گونههای اینجور پیامها را مدخل Error message جمع کرده است.
پیام خطای خوب سه چیز میگوید
چه شد، چرا شد، حالا چه کار کنم. پیامی که یکی از این سه را نداشته باشد ناقص است و پیامی که بیشتر بگوید، پرحرف. «چه شد» با زبان کاربر: «پرداخت انجام نشد»، نه «تراکنش با کد ۴۱ برگشت خورد». «چرا» یک جمله است: «موجودی کارت کافی نبود». و «حالا چه کنم» باید انجامشدنی باشد: «با کارت دیگری امتحان کنید»، نه «بعداً تلاش کنید» که در عمل یعنی هیچ.
قاعدهی چهارمی هم هست که کمتر گفته میشود: کاربر را مقصر نکنید. «شما شماره را اشتباه وارد کردید» و «شمارهی کارت باید ۱۶ رقم باشد» یک اطلاعات را میرسانند؛ اولی سرزنش است و دومی راهنمایی.
پیام ضعیف، پیام بهتر، و اینکه چرا
تفاوت دو ستون زیر نه در ادبیات است و نه در طول؛ در مقدار اطلاعاتی است که به کاربر میرسد.
| پیام ضعیف | پیام بهتر | چرا |
|---|---|---|
| خطایی رخ داد | پرداخت انجام نشد؛ مبلغ از حسابتان کم نشده است | نگرانی اول کاربر پول است، نه خطا |
| اطلاعات نامعتبر است | شمارهی کارت باید ۱۶ رقم باشد | میگوید دقیقاً چه چیزی را درست کند |
| تأیید | ثبت سفارش | نتیجه روی خود دکمه نوشته شده |
| موردی یافت نشد | هنوز فاکتوری نساختهاید؛ اولین فاکتور را بسازید | حالت خالی به قدم بعدی وصل میشود |
| شما رمز را اشتباه زدید | رمز درست نبود؛ دوباره وارد کنید | راهنمایی نشسته جای سرزنش |
متن دکمه: فعل مشخص، نه «تأیید»
«تأیید» تنبلترین متن دکمهی ممکن است، چون چیزی دربارهی نتیجه نمیگوید. کاربر جلوی کادری که پرسیده «آیا مطمئن هستید؟» فقط دو کلمه دارد و اگر همان لحظه حواسش پرت شده باشد، نمیداند تأیید یعنی حذف میشود یا نمیشود.
قاعده ساده است: متن دکمه باید جملهی ذهنی کاربر را کامل کند. «میخواهم… سفارش را ثبت کنم» روی دکمه میشود «ثبت سفارش». حالا کاربری که متن بالای کادر را نمیخواند هم میداند چه اتفاقی میافتد. نمونههای بیشتر این همکاری با طراح در هوش مصنوعی برای طراحان رابط کاربری آمده است.
حالت خالی: بهترین جای آموزش دادن
«موردی یافت نشد» فقط یک چیز میگوید: صفحه خراب نیست. اما حالت خالی تنها جایی است که کاربر بدون حواسپرتی به یک صفحهی تقریباً سفید نگاه میکند؛ گرانترین فضای محصول شماست و در آن نوشتهاید «موردی یافت نشد».
سه نوع حالت خالی داریم و هر سه متن متفاوتی میخواهند. کاربر تازهواردی که هنوز چیزی نساخته: بگویید این صفحه به چه درد میخورد و دکمهای بگذارید که اولین مورد را بسازد. جستوجویی که نتیجه نداشته: بگویید چه چیزی جستوجو شد و پیشنهاد بدهید فیلتر برداشته شود. و حالت «همهچیز تمام شد»: تبریک بگویید و بروید کنار.
لحن یکدست، وگرنه محصول شبیه چهار نفر حرف میزند
در یک اپ فروشگاهی معمولی، صفحهی پرداخت را یک نفر نوشته، پیامهای اعتبارسنجی فرم را یکی دیگر، و متن اعلانها را ماهها بعد کسی که در تیم اول نبوده. نتیجه: یکجا «شما»، یکجا «کاربر گرامی»، یکجا «باشه» و یکجا «تأیید میکنم».
راهحل یک سند یکصفحهای است: خطاب چیست، فعل مجهول مجاز است یا نه، ایموجی میگذاریم یا نه، «لطفاً» کجا میآید. همان کاری که در ساخت لحن برند برای محتوای بازاریابی گفته شده، اینجا سختگیرانهتر لازم است چون متنها کوتاهترند و ناهماهنگی زودتر توی چشم میزند. مدل هم دقیقاً همینجا بیشترین سود را میرساند: سند لحن را بالای پرامپت بگذارید و رشتههای موجود را دستهدسته بدهید تا یکدست بازنویسی کند.
تلهی طول: ترجمه، دکمهی فارسی را میشکند
«Save» چهار نویسه است و «ذخیرهی تغییرات» چند برابرش؛ «Sign in» میشود «ورود به حساب کاربری». اگر رابط را با متن انگلیسی طراحی کنید و بعد ترجمه، متن فارسی معمولاً بلندتر درمیآید و دکمه یا دو خطی میشود یا با سهنقطه بریده — و «ذخیرهی تغی…» از هیچ هم بدتر است. پس سقف طول را داخل خود پرامپت بنویسید، نه اینکه بعداً کوتاهش کنید. تلههای مشابه را ترجمه و بومیسازی اپلیکیشن باز کرده است.
یک نکتهی فنی هم هست: نیمفاصله. «میشود» یک کلمه است و «می شود» دو تکهی شکسته. مدلها در تولید نیمفاصله بیثباتند و گاهی وسط یک فهرست نصف موارد را درست و نصف را غلط میدهند؛ خروجی را از یک یکسانساز رد کنید. ریشهاش در محدودیتهای فارسی در هوش مصنوعی توضیح داده شده است.
عدد، تاریخ، و جایی که مدل واقعاً اشتباه میکند
تاریخ را شمسی نشان بدهید مگر اینکه محصولتان بینالمللی باشد؛ «۱۴۰۵/۰۵/۱۴» برای کاربر ایرانی خواناتر است و برای فاصلههای کوتاه «۲ روز پیش» از هر دو بهتر. مبنای این تقویم در مدخل Solar Hijri calendar آمده. ارقام فارسی یا لاتین هم فرقی نمیکند، به شرطی که همهجا یکی باشد؛ بدترین حالت این است که مبلغ فاکتور فارسی نوشته شود و شمارهی پیگیری لاتین.
و اینجا باید صریح باشم: مدل در همین قسمت بیشترین اشتباه را میکند. تبدیل تاریخ میلادی به شمسی را غلط انجام میدهد، جداکنندهی هزارگان را جابهجا میگذارد و گاهی ارقام را وسط جمله عوض میکند. برای نوشتن متن بله، برای محاسبهی تاریخ نه — آن کار کتابخانهی تقویم است.
پیامهای حساس: حذف و پرداخت
در کادر حذف سه چیز باید روشن باشد: چه چیزی حذف میشود، برگشتپذیر هست یا نه، و چه چیز دیگری با آن میرود. «آیا مطمئن هستید؟» هیچکدام را نمیگوید؛ «حذف پروژهی فروشگاه زعفران و همهی فایلهای داخلش. این کار برگشتپذیر نیست.» هر سه را میگوید. در پرداخت هم مهمترین متن همانی است که کاربر بعد از فشردن دکمه میبیند: اگر تراکنش ناموفق بود بگویید پول کم شده یا نه و کِی برمیگردد. و روی دکمهی پرداخت ننویسید «تأیید»؛ بنویسید «پرداخت ۲۵۰٬۰۰۰ تومان».
جملههایی که تعهد میسازند — شرایط بازگشت وجه، مهلت لغو سفارش، متن قرارداد کاربری — پیشنویسشان را از مدل بگیرید، ولی نسخهی نهایی باید از نظر مسئول مالی یا حقوقی رد شود. مدل جملهی روان میسازد، نه تعهد قابل دفاع. متنهای مربوط به خوانندهی صفحه هم که در هوش مصنوعی و دسترسپذیری آمده، آزمون واقعی میخواهند نه حدس.
پرامپتی که خروجی قابل استفاده میدهد
«یک پیام خطای بهتر بنویس» نتیجهی بیفایده میدهد، چون مدل نه میداند چه شده و نه میداند کاربر چه کاری از دستش برمیآید. الگوی زیر همان اطلاعات را میدهد:
نقش: نویسندهی متن رابط کاربری فارسی
محصول: [اپ فروشگاه اینترنتی، لحن ساده، خطاب «شما»]
موقعیت: [کاربر روی پرداخت زد و درگاه بانک جواب نداد]
کاری که کاربر میتواند بکند: [چند دقیقه بعد دوباره، یا کارت دیگر]
وضعیت پول: [مبلغ کم نشده است]
قواعد ثابت:
- سه چیز بگو: چه شد، چرا، حالا چه کنم
- کاربر را مقصر نکن و فعل مجهول به کار نبر
- بدون «لطفاً» و بدون علامت تعجب
- متن پیام حداکثر دو جمله
- متن دکمه فعل مشخص، حداکثر هجده نویسه
خروجی: جدول — متن پیام، دکمهی اصلی، دکمهی فرعی
سه نسخه بده با درجهی رسمیبودن متفاوتسه نسخه خواستن عمدی است: کنار هم که ببینیدشان زودتر میفهمید کدام لحن به محصولتان میخورد. اصولش در پرامپتنویسی فارسی آمده و در نارنگی میشود همانجا امتحانش کرد.
جایی که مدل جواب نمیدهد
مدل نمیداند دکمهی شما در موبایل چقدر جا دارد، نمیداند کاربرانتان چه سنیاند، و از همه مهمتر نمیداند در کد شما دقیقاً چه خطایی افتاده. اگر خودتان ندانید کد بازگشتی درگاه یعنی چه، مدل حدس میزند و حدسش را با لحنی مطمئن مینویسد؛ آن جمله بعد سر راه هزار کاربر میرود. دو تصمیم هم مال شماست: اینکه اصلاً این پیام لازم است یا باید حذف شود، و آزمون روی کاربر واقعی. برای بازنویسی انبوه، ویرایش و بازنویسی متن فارسی ابزار خوبی است.
جمعبندی
متن رابط کاربری کار محتوایی نیست، بخشی از طراحی است. «خطایی رخ داد» یک باگ است که کامپایلر آن را نمیگیرد.
سه قاعده را نگه دارید: هر پیام خطا سه چیز بگوید، هر دکمه فعل داشته باشد، هر حالت خالی یک قدم بعدی پیشنهاد بدهد. یک سند یکصفحهای لحن بنویسید و بالای هر پرامپتی بگذاریدش، بعد از پرترافیکترین صفحهها شروع کنید. و متن نهایی را روی گوشی بخوانید، نه روی مانیتور.
برای ادامه:
