ریزنوشته: متنهای کوچکی که تجربه را میسازند
در هر محصولی دهها متن کوچک هست که هیچکس مالکشان نیست: متن دکمه، پیام خطا، راهنمای فیلد، حالت خالی، پیام تأیید.
طراح آنها را در فایل «متن نمونه» میگذارد. توسعهدهنده چیزی مینویسد که به ذهنش میرسد. و در نهایت محصولی دارید که در هر صفحه با لحن متفاوتی حرف میزند.
این متنها روی هم، بیشتر از هر عنصر دیگری تعیین میکنند که کاربر کارش را انجام میدهد یا رها میکند.
چرا اهمیتش بیشتر از چیزی است که به نظر میرسد
سه دلیل عملی:
در لحظهٔ تصمیم خوانده میشوند. کاربر متن صفحهٔ «دربارهٔ ما» را نمیخواند؛ متن روی دکمهای که قرار است بزند را میخواند.
در لحظهٔ اضطراب خوانده میشوند. پیام خطا وقتی خوانده میشود که کاربر گیر کرده. آن لحظه، هر ابهامی به رهاکردن ختم میشود.
تغییرشان ارزان است. برخلاف بازطراحی، تغییر متن یک دکمه چند دقیقه است و گاهی نرخ تبدیل را چند درصد جابهجا میکند.
قواعد
دکمه: فعل، نه اسم
دکمه باید بگوید چه اتفاقی میافتد، نه اینکه فرم چیست.
- «ثبت سفارش» بهتر از «تأیید»
- «ارسال درخواست مشاوره» بهتر از «ارسال»
- «ذخیره تغییرات» بهتر از «تأیید»
در پنجرهٔ تأیید، هرگز «بله» و «خیر» نگذارید. کاربری که عجله دارد سؤال را نمیخواند و فقط دکمهها را میبیند. اگر دکمهها «حذف فاکتور» و «انصراف» باشند، بدون خواندن سؤال هم میفهمد.
پیام خطا: سه بخش
چه شد، چرا، چه کار کنم.
بد: «خطا در ثبت سفارش»
بهتر: «سفارش ثبت نشد چون موجودی این کالا به ۲ عدد کاهش یافته. تعداد را اصلاح کنید یا کالای دیگری انتخاب کنید.»
و هرگز کد فنی را به کاربر نشان ندهید — مگر شناسهای برای پیگیری، که آن هم باید با توضیح باشد: «کد پیگیری خطا: ۴۸۲۱ — این کد را به پشتیبانی بگویید.»
حالت خالی: راهنما، نه اطلاعیه
«موردی یافت نشد» بدترین استفادهٔ ممکن از یک صفحهٔ کامل است.
سه چیزی که باید داشته باشد: چرا خالی است، قدم بعدی چیست (با دکمه)، و اگر ممکن است، پر شدنش چه شکلی است.
جزئیاتش در تجربهٔ اولین اجرا.
تأیید عملیات خطرناک
سؤال باید اثر را بگوید، نه عمل را:
بد: «آیا مطمئن هستید؟»
بهتر: «این فاکتور و ۱۲ ردیف آن حذف میشوند. این کار برگشتپذیر نیست.»
و اگر میتوانید، بهجای تأیید، امکان بازگشت بدهید. پیام «حذف شد — بازگرداندن» بهمراتب بهتر از پنجرهای است که کاربر بعد از سومین بار بیفکر تأیید میکند.
راهنمای فیلد: نمونه، نه توضیح
«مثال: ۰۹۱۲۱۲۳۴۵۶۷» بهتر از «شمارهٔ موبایل خود را وارد کنید» است — که همان چیزی است که برچسب فیلد گفته.
و قواعد را از قبل بگویید، نه بعد از خطا. «حداقل ۸ کاراکتر» باید زیر فیلد رمز باشد، نه اینکه بعد از تلاش ناموفق ظاهر شود. بقیهٔ قواعد فرم در طراحی فرم.
حالت بارگذاری و موفقیت
بارگذاری: اگر بیش از چند ثانیه است، بگویید چه اتفاقی میافتد — «در حال بررسی موجودی…». چرخندهٔ بیمتن، اضطراب میسازد.
موفقیت: بگویید بعدش چه میشود. «سفارش ثبت شد. پیامک تأیید تا چند دقیقه دیگر میرسد.» — این یک جمله، حجم زیادی از تماسهای پشتیبانی را حذف میکند.
مسئلهٔ لحن در فارسی
تصمیمی که باید یک بار گرفته و در همهجا رعایت شود:
رسمی یا صمیمی؟ «وارد شوید» یا «وارد شو»؟ هر دو قابل دفاعاند؛ مخلوط کردنشان نه. محصولی که در یک صفحه «شما» و در صفحهٔ بعد «تو» میگوید، ناهماهنگ حس میشود.
برای محصولات سازمانی و مالی، رسمی. برای محصولات مصرفی و جوانپسند، صمیمی قابل دفاع است. تصمیم را بنویسید و در دیزاین سیستم ثبتش کنید — همان لایهٔ «قواعد» که در دیزاین سیستم گفتیم.
سه دام رایج در فارسی:
ترجمهٔ تحتاللفظی. «عملیات با موفقیت انجام شد» ترجمهٔ مستقیم است و فارسی طبیعی نیست. «ذخیره شد» کافی است.
رسمیت اداری بیش از حد. «مقتضی است نسبت به تکمیل فرم اقدام فرمایید» هیچکس اینطور حرف نمیزند.
اصطلاح فنی ترجمهنشده یا بدترجمه. بعضی واژهها را نباید ترجمه کرد و بعضی را حتماً باید. معیار: کاربر شما کدام را میفهمد؟ برای کاربر عمومی «رمز عبور»؛ برای توسعهدهنده شاید همان واژهٔ انگلیسی روشنتر باشد.
و اعداد: فارسی یا لاتین؟ این هم یک بار تصمیم گرفته شود. توصیهٔ ما: در نمایش فارسی، در فیلدهای فنی مثل کد پیگیری و شمارهٔ کارت لاتین.
اشتباهاتی که مکرر دیدهایم
متن نمونه که به تولید رفته. «لورم ایپسوم» یا «متن تست» در محصول زنده. یک جستوجوی ساده پیش از هر انتشار، جلویش را میگیرد.
پیامهای متناقض برای یک چیز. «سبد خرید»، «سبد»، «کارت خرید» در سه صفحه.
متنهای هاردکد شده در کد. افزودن زبان دوم بعداً یعنی گشتن در کل کد. حتی اگر فعلاً تکزبانهاید، متنها را در یک جا جمع کنید — هزینهاش امروز تقریباً صفر است.
شوخی در جای اشتباه. پیام بامزه هنگام خطای پرداخت، عصبانیکننده است. لحن بازیگوش برای حالتهای موفق، نه برای لحظهای که کاربر گیر کرده.
چه کسی مسئول است
پیشنهاد عملی ما: یک نفر مالک همهٔ متنها باشد — طراح، مدیر محصول، یا کسی که خوب مینویسد. نه اینکه هر توسعهدهنده متن خودش را بنویسد.
و متنها را جایی جمع کنید که قابل مرور باشند، نه پراکنده در کد. وقتی کنار هم دیده شوند، ناهماهنگیها فوراً پیدا میشوند.
آزمون
متنهای محصولتان را در یک فایل کنار هم بگذارید و بخوانید.
اگر مثل حرف زدن یک نفر به نظر میرسد، خوب است. اگر مثل حرف زدن پنج نفر متفاوت است — که تقریباً همیشه در بار اول همینطور است — کار دارید.
این تمرین چند ساعت است و معمولاً بیشترین بهبود قابل مشاهده را به ازای وقت صرفشده میدهد.