متن دکمه «ثبت» به تنهایی معلوم نمی‌کند داده ذخیره می‌شود، درخواست ارسال می‌شود یا پرداخت نهایی انجام می‌گیرد. UX Writing از همین فاصله میان کلمه و نتیجه عمل شروع می‌شود. متن رابط باید کاربر را برای تصمیمی که اکنون می‌گیرد آماده کند و پس از عمل، نتیجه واقعی را توضیح دهد. انتخاب واژه خوش‌صدا بدون شناخت رفتار محصول، این نیاز را پاسخ نمی‌دهد.
نویسنده رابط باید بداند کاربر در کدام مرحله است، چه اطلاعاتی دارد و سیستم چه محدودیتی دارد. یک پیام خطای شبکه با خطای قالب شماره تماس فرق دارد. پیشنهاد اصلاح برای اولی ممکن است تلاش دوباره باشد و برای دومی توضیح ورودی مورد قبول. استفاده از یک پیام عمومی برای هر دو، مسئولیت فهم مسئله را به کاربر می‌سپارد.
متن را همراه جریان کار بنویسید
برای نمونه فرضی ثبت سفارش، مرحله انتخاب کالا، مرور نشانی و پرداخت را جدا در نظر بگیرید. این مثال به داده مشتری واقعی تکیه ندارد. در هر مرحله، سؤال کاربر فرق می‌کند: آیا کالا درست است، ارسال به کجا انجام می‌شود و چه مبلغی پرداخت خواهد شد؟ متن عنوان و دکمه باید همین مرحله را معرفی کند، نه اینکه در تمام مسیر «ادامه» تکرار شود.
پیش از نوشتن، نتیجه عمل را از تیم فنی بپرسید. آیا کلیک واقعاً سفارش می‌سازد یا کاربر را به سرویس پرداخت می‌برد؟ آیا ذخیره خودکار فعال است یا باید دکمه را بزند؟ متنی که از رفتار جلوتر وعده می‌دهد، اعتماد را کم می‌کند. اگر نتیجه هنوز تعریف نشده، مسئله محصول را با جمله خوش‌خوان پنهان نکنید؛ قرارداد عمل باید روشن شود.
برای هر مرحله، ورود و خروج آن را ثبت کنید. کاربر ممکن است از لینک مستقیم وارد صفحه شود و توضیح مرحله قبلی را ندیده باشد. عنوان و متن کوتاه باید زمینه لازم را داشته باشند. در بازگشت به صفحه نیز داده و وضعیت باید با پیام هماهنگ باشند؛ نمایش «از ابتدا شروع کنید» وقتی اطلاعات حفظ شده، مسیر واقعی را توضیح نمی‌دهد.
نام دکمه باید عمل را معرفی کند
فعل مشخص معمولاً از کلمه عمومی قابل فهم‌تر است. «ذخیره پیش‌نویس» با «ارسال درخواست» تفاوت دارد و این تفاوت باید روی کنترل دیده شود. راهنمای Button در GOV.UK Design System هم بر متن توصیف‌کننده عمل تأکید می‌کند. این راهنما یک مرجع طراحی است؛ لحن و زبان آن را بی‌فکر به رابط فارسی منتقل نکنید.
دکمه «بازگشت» باید مقصد یا اثر قابل پیش‌بینی داشته باشد. اگر داده پاک می‌شود، کاربر باید پیش از عمل از آن باخبر شود. برای پرداخت نهایی، نام عمل و اطلاعات مبلغ در زمینه نزدیک لازم‌اند. کوتاه بودن دکمه مزیت است، اما اگر نتیجه را مبهم کند، طول کم‌تر به قیمت تصمیم ناقص تمام می‌شود. متن کمکی می‌تواند جزئیات مربوط را بدون شلوغ کردن نام دکمه بیان کند.
برای چند عمل کنار هم، نام‌ها را با هم بخوانید. «لغو» در Dialog ممکن است به بستن پنجره یا لغو سفارش تعبیر شود. «بازگشت به سفارش» و «لغو سفارش» در آن زمینه تفاوت روشن‌تری دارند. یک واژه را فقط به دلیل استفاده در componentهای دیگر تکرار نکنید؛ معنی آن باید در مرحله فعلی قابل تشخیص بماند.
نام و توضیح فیلد را از هم جدا کنید
Label نام داده مورد نیاز را مشخص می‌کند و hint قالب یا دلیل را توضیح می‌دهد. اگر قالب مهم است، آن را پیش از خطا در دسترس قرار دهید. برای «شماره تماس» می‌توانید قالب مورد قبول واقعی محصول را توضیح دهید؛ نمونه فرضی نباید با قانون backend تفاوت داشته باشد. اگر ورودی فارسی و لاتین پذیرفته می‌شود، متن نباید محدودیت غیرواقعی اعلام کند.
Placeholder برای مثال کوتاه مفید است، ولی جای label پایدار را نمی‌گیرد. پس از ورود داده، کاربر باید همچنان بداند فیلد چیست. متن توضیحی را با ارتباط برنامه‌ای مناسب به input وصل کنید تا صرفاً یک جمله دیداری کنار آن نباشد. مقاله طراحی فرم وب ادامه‌ای برای رابطه چیدمان، ورودی و پیام است.
دلیل درخواست اطلاعات حساس را صریح بنویسید. «برای تجربه بهتر» معمولاً توضیح کافی برای شماره ملی یا تاریخ تولد نیست. اگر داده برای یک کار مشخص لازم است، همان کار را نام ببرید. اگر اختیاری است، این وضعیت را واضح کنید. متن نمی‌تواند ضرورت جمع‌آوری داده را ایجاد کند؛ ابتدا نیاز محصول باید قابل دفاع و مشخص باشد.
خطا باید مشکل و قدم بعدی را روشن کند
«اشتباه وارد کردید» هم مبهم است و هم کاربر را مقصر معرفی می‌کند. خطا را به داده یا وضعیت مشخص نسبت دهید. برای یک تاریخ خارج از بازه، بازه مجاز را بیان کنید؛ برای ارتباط ناموفق، وضعیت دریافت را توضیح دهید. حدس درباره علت نسازید. اگر معلوم نیست پرداخت انجام شده، پیام قطعی «ناموفق بود» می‌تواند کاربر را به تکرار پرداخت هدایت کند.
راهنمای Error Message در GOV.UK توصیه می‌کند توضیح دهد چه مشکلی وجود دارد و چگونه برطرف می‌شود، و خطای سرویس را از خطای ورودی تفکیک کند. در فارسی، لحن مستقیم و محترمانه کافی است. لازم نیست پیام خطا را با شوخی یا عبارت احساسی شروع کنید؛ کاربر در آن لحظه به راه ادامه کار نیاز دارد.
پیام باید کنار محل مربوط و در مسیر مرور قابل یافتن باشد. برای چند خطا، خلاصه‌ای با پیوند به فیلدها مفید است. پیام‌های field و خلاصه نباید دو دستور متفاوت بدهند. اگر اطلاعات درست حفظ شده‌اند، آن را در رفتار نشان دهید؛ پاک کردن فرم و درخواست ورود دوباره، هزینه اصلاح را افزایش می‌دهد حتی اگر متن پیام مودبانه باشد.
حالت خالی، loading و شکست را یکسان ننویسید
وقتی فهرست سفارش خالی است، ابتدا معلوم کنید چرا. کاربر تازه هنوز سفارشی ندارد، فیلتر ممکن است همه نتایج را حذف کرده باشد یا دریافت داده شکست خورده باشد. این سه حالت قدم بعدی متفاوتی دارند. «هنوز سفارشی ثبت نشده» فقط وقتی درست است که داده معتبر آن را نشان دهد؛ در شکست دریافت، چنین پیامی خبر نادرست درباره وضعیت سامانه می‌دهد.
در loading، انتظار را توضیح دهید بدون زمان ساختگی. «چند ثانیه دیگر» وقتی مدت معلوم نیست وعده نادرستی است. برای عملیات طولانی، وضعیت قابل اعتماد و راه ادامه کار را مشخص کنید. اگر امکان خروج از صفحه وجود دارد، اثر آن را روشن کنید. پیام باید از state واقعی برنامه بیاید، نه از timer تزئینی که درصد موفقیت فرضی نمایش می‌دهد.
پس از موفقیت، نتیجه و قدم بعدی را نام ببرید. «انجام شد» برای ذخیره فایل، ارسال درخواست و تغییر رمز اطلاعات یکسان و ناکافی می‌دهد. پیام «درخواست ارسال شد؛ پاسخ در بخش درخواست‌ها نمایش داده می‌شود» مسیر روشن‌تری دارد، به شرط آنکه رفتار واقعی همین باشد. اعلان موفقیت نباید اطلاعات حساس یا تمام داده فرم را بی‌دلیل تکرار کند.
لحن را با موقعیت هماهنگ نگه دارید
لحن برند می‌تواند صمیمی باشد، اما خطای مالی یا بازیابی حساب به وضوح و آرامش نیاز دارد. شوخی در این موقعیت ممکن است بی‌اعتنایی به مسئله تلقی شود. تغییر شدت و طول پیام با موقعیت طبیعی است؛ یکدست بودن به معنی جمله یکسان برای همه شرایط نیست. قواعد لحن را همراه مثال وضعیت عادی، خطا و عمل حساس ثبت کنید.
واژه‌های تخصصی لازم را حفظ کنید و در محل مناسب توضیح دهید. برای پنل توسعه‌دهنده، API Key نام قابل انتظار است و جایگزین ناآشنا ممکن است فهم را سخت‌تر کند. در رابط عمومی، اصطلاح backend بدون توضیح فایده ندارد. انتخاب از آشنایی مخاطب و دقت مفهوم می‌آید؛ حذف اجباری تمام واژه‌های انگلیسی یا استفاده نمایشی از آن‌ها هر دو مسئله می‌سازند.
در فارسی، فعل‌ها و رسم‌الخط را خوانا نگه دارید. «ذخیره می‌گردد» معمولاً از «ذخیره می‌شود» روشن‌تر نیست. جمله بلند اداری را به رابطه مستقیم عمل و نتیجه تبدیل کنید. اگر محدودیت مهمی دارید، آن را پشت چند مقدمه پنهان نکنید. احترام به کاربر با توضیح دقیق و اختیار روشن ساخته می‌شود، نه با تعداد زیاد عبارت‌های تعارفی.
متن باید در دسترسی‌پذیری و ترجمه دوام بیاورد
دستور را فقط به محل یا رنگ وابسته نکنید. Sensory Characteristics در WCAG همین محدودیت را توضیح می‌دهد. «گزینه ذخیره پیش‌نویس را انتخاب کنید» از «دکمه آبی سمت چپ» مستقل‌تر است. رنگ و محل می‌توانند نشانه کمکی باشند، اما نام کنترل باید در زبان و layoutهای مختلف آن را شناسایی کند.
برای لینک، متن مقصد را توصیف کند. چند لینک «بیشتر» در فهرست، خارج از زمینه ممکن است قابل تفکیک نباشند. از نام طولانی و تکراری برای همه لینک‌ها هم دور بمانید؛ اطلاعات مربوط کافی است. عنوان صفحه، نام کنترل و نام قابل دسترس را با هم بررسی کنید تا یک عمل در فناوری کمکی با واژه‌ای کاملاً متفاوت شنیده نشود.
رشته ترجمه را از چند قطعه پراکنده نسازید که ترتیب دستوری را ثابت فرض می‌کنند. مقدار پویا، واحد و جمله باید زمینه مشخص داشته باشند. نام کاربر یا کد سفارش را بدون تغییر محتوایش در جهت مناسب نمایش دهید. برای متن بلندتر فارسی، فضای component را در نظر بگیرید؛ کوتاه کردن واژه تا حد ابهام راه حل محدودیت عرض نیست.
یک فهرست متن قابل نگهداری تحویل دهید
برای هر پیام، محل نمایش، state آغازکننده و عمل ممکن را ثبت کنید. پیام‌های تقریباً یکسان را فقط وقتی یکسان کنید که رفتار یکسان دارند. اگر «ذخیره» در یک بخش محلی و در بخش دیگر سروری است، تفاوت نتیجه باید روشن بماند. این فهرست به تیم کمک می‌کند هنگام تغییر API یا جریان کار، متن مربوط را پیدا کند و وعده قدیمی باقی نماند.
در ارزیابی، از کاربر بخواهید توضیح دهد پس از زدن دکمه چه اتفاقی خواهد افتاد و در خطا چه کاری می‌کند. فهم او را با نتیجه واقعی مقایسه کنید. مقاله Visual Hierarchy برای محل و وزن پیام ادامه مرتبط است. متن درست وقتی کار می‌کند که در نقطه تصمیم دیده شود و با رفتار همان نقطه هماهنگ بماند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!