UX Writing و میکروکپی؛ طراحی متن برای محصول فارسی

کاربر در صفحه پرداخت یک فروشگاه ایرانی روی «تأیید» می‌زند. آیا سفارش ثبت می‌شود، پول کسر می‌شود یا فقط وارد مرحله بعد خواهد شد؟ همین یک واژه مبهم می‌تواند کاربر را مردد کند، کلیک را به تعویق بیندازد یا تماس پشتیبانی بسازد. UX Writing یعنی طراحی همین تصمیم‌ها با کلمه؛ نه تزئین متن در پایان طراحی.

در این راهنما، نویسندگی تجربه کاربری و میکروکپی را به یک فرایند محصول تبدیل می‌کنیم: از شناخت Task و State تا نوشتن دکمه، فرم، خطا، پیام پرداخت و اعلان؛ سپس واژه‌نامه، دسترس‌پذیری، تحویل به توسعه، سنجش و حاکمیت را پوشش می‌دهیم. مثال‌ها برای زبان فارسی، رابط RTL و موقعیت‌هایی مثل رمز یک‌بارمصرف، کد ملی، شبا، مبلغ تومان/ریال و اختلال شبکه نوشته شده‌اند.

UX Writing چیست؟

UX Writing طراحی کلماتی است که به کاربر کمک می‌کنند وضعیت را بفهمد، تصمیم بگیرد، کاری را انجام دهد و در صورت خطا بازیابی کند. این کلمات در Label، دکمه، Hint، پیام خطا، Empty state، اعلان، راهنمای مرحله‌ای، Permission prompt و تأیید عملیات دیده می‌شوند. برای دیدن جای محتوا در کل سفر، ابتدا راهنمای تجربه کاربری را مرور کنید.

خروجی نویسنده UX صرفاً «جمله خوب» نیست. او منطق محصول را روشن می‌کند: چه اتفاقی افتاده، چه چیزی از کاربر می‌خواهیم، هزینه یا پیامد اقدام چیست، چه حالت‌هایی وجود دارد و راه بازگشت کدام است.

میکروکپی چیست و چه تفاوتی با UX Writing دارد؟

میکروکپی قطعه کوچک متن در یک نقطه تعامل است؛ مثل «ارسال دوباره کد تا ۰۱:۲۹»، «تغییر شماره موبایل» یا «پرداخت انجام نشد؛ مبلغی کسر نشده است». UX Writing حوزه وسیع‌تری است و جریان، معماری پیام، صدا، واژگان، قواعد و سنجش همه این قطعات را دربر می‌گیرد.

مرزها مطلق نیستند، اما تعارض هدف مهم است. متن کمپینیِ هیجان‌انگیز ممکن است برای دکمه حذف حساب نامناسب باشد؛ در عمل حساس، وضوح و کنترل کاربر بر لحن تبلیغاتی مقدم است.

کلمه را یک جزء طراحی بدانید

متن بر اندازه دکمه، ترتیب اطلاعات، تعداد مراحل و حتی مدل داده اثر دارد. اگر نمی‌توانید پیام موفقیت انتقال وجه را دقیق بنویسید، شاید Stateهای Backend—«دریافت شد»، «در حال پردازش»، «موفق» و «برگشت‌خورده»—به‌درستی تعریف نشده‌اند. نویسنده باید پیش از Wireframe نهایی وارد مسئله شود، نه پس از قفل‌شدن UI.

قرارداد محتوا برای هر تعامل

Task: کاربر می‌خواهد چه کاری انجام دهد؟
State: اکنون سیستم در چه وضعیتی است؟
Decision: کاربر چه انتخابی دارد؟
Consequence: پس از اقدام چه می‌شود؟
Recovery: اگر شکست خورد یا منصرف شد چه راهی دارد؟
Evidence: متن بر اساس کدام قانون، داده یا تحقیق است؟

این قرارداد، اختلاف میان Product، Design، Engineering، Legal و Support را پیش از تولید ده‌ها پیام آشکار می‌کند.

از زبان واقعی کاربر شروع کنید

زبان رابط را از جلسه داخلی اختراع نکنید. عبارت‌های جست‌وجوی درون‌محصول، Ticket پشتیبانی، مصاحبه، تست کاربردپذیری، گفت‌وگوی فروش و خطاهای پرتکرار را بررسی کنید. اگر تیم می‌گوید «Beneficiary» ولی کاربر می‌گوید «مقصد انتقال»، انتخاب واژه باید با Task و فهم کاربر آزموده شود.

پژوهش باید Segment و موقعیت را ببیند

کاربر تازه‌وارد، اپراتور حرفه‌ای و مشتری مضطرب در پرداخت ناموفق، نیاز زبانی یکسان ندارند. سطح سواد دیجیتال، سن، ابزار، محدودیت شناختی، سرعت شبکه و محیط استفاده را در نمونه پژوهش بگنجانید. راهنمای W3C درباره استفاده از واژه‌های روشن توصیه می‌کند اصطلاح نامأنوس، مخفف بی‌توضیح و معنای اختراعی را حذف یا توضیح دهید.

مدل State پیش از متن

هر Task حداقل چهار لحظه دارد: پیش از اقدام، هنگام پردازش، نتیجه و بازیابی. اگر فقط حالت موفق طراحی شود، پیام‌های واقعی محصول در لحظه بحران شتاب‌زده و متناقض خواهند بود.

برای هماهنگی متن با Feedback بصری و Motion، راهنمای میکرواینتراکشن و State را ببینید. انیمیشن نباید جای پیام قابل فهم یا وضعیت قابل دسترس را بگیرد.

شش اصل میکروکپی مؤثر

۱. روشن: کاربر مجبور به تفسیر نباشد

به‌جای «درخواست نامعتبر»، بنویسید «تاریخ پایان باید بعد از تاریخ شروع باشد». به‌جای «ادامه»، نتیجه عمل را نام ببرید. وضوح یعنی اطلاعات لازم در همان لحظه، نه طولانی‌نویسی.

۲. موجز: هر کلمه وظیفه داشته باشد

عبارت‌های اداری مثل «لطفاً نسبت به وارد نمودن» را به «وارد کنید» تبدیل کنید. اما جزئیات حیاتی—مبلغ، واحد، مهلت، برگشت‌پذیری یا مقصد—را قربانی کوتاهی نکنید.

۳. مشخص: شیء و نتیجه معلوم باشد

«ذخیره آدرس» از «ذخیره» و «ارسال درخواست بازپرداخت» از «تأیید» دقیق‌تر است. متن باید با نتیجه واقعی سیستم منطبق باشد؛ دکمه‌ای که فقط مرحله بعد را باز می‌کند نباید «خرید» نامیده شود.

۴. به‌موقع: راهنما پیش از خطا بیاید

شرط رمز، حجم فایل یا فرمت شبا را پیش از Submit و نزدیک فیلد نشان دهید. نمایش همه قواعد از ابتدا هم می‌تواند بار شناختی بسازد؛ Progressive disclosure را بر اساس نیاز آزمون کنید.

۵. انسانی: بدون سرزنش و شوخی نامناسب

«شما رمز را اشتباه وارد کردید» را به «رمز واردشده درست نیست» تغییر دهید. هنگام رد پرداخت، از دست‌رفتن داده یا مشکل امنیتی، شوخی و لحن بیش‌ازحد صمیمی می‌تواند اعتماد را کاهش دهد.

۶. سازگار: یک مفهوم، یک نام

اگر Object در محصول «سبد خرید» است، در صفحه دیگر آن را «کیف سفارش» ننامید. سازگاری Label، Icon، URL، Email و متن پشتیبانی، یادگیری را کم‌هزینه می‌کند.

متن دکمه و CTA را چگونه بنویسیم؟

برای اقدام مهم، الگوی «فعل + شیء/نتیجه» نقطه شروع خوبی است: «دانلود فاکتور»، «ارسال کد ورود»، «حذف حساب». برچسب باید در فضای موجود قابل اسکن و بدون وابستگی به پاراگراف دوردست قابل فهم باشد.

اقدام مخرب و برگشت‌ناپذیر

در Dialog حذف، نام Object و پیامد را بنویسید، اقدام خطرناک را مشخص کنید و مسیر امن بدهید: «حساب و ۱۲ پروژه برای همیشه حذف می‌شوند»؛ دکمه‌ها «حذف حساب» و «نگه‌داشتن حساب». اگر Undo ممکن است، حذف نرم و فرصت بازگردانی اغلب بهتر از تأییدهای پیاپی است.

فرم را با Label، Hint و Example طراحی کنید

Placeholder جای Label نیست؛ با تایپ ناپدید می‌شود و ممکن است برای مرور، حافظه و فناوری کمکی کافی نباشد. Label پایدار بماند، Hint فقط قاعده غیرقابل‌حدس را توضیح دهد و Example با داده واقعی اشتباه نشود.

Label: شماره شبا
Hint: با IR شروع می‌شود و در مجموع ۲۶ نویسه دارد.
Example: IR12 3456 7890 1234 5678 9012 34
Error: شماره شبا کامل نیست؛ ۲۶ نویسه را وارد کنید.

در WCAG 2.2، وجود Label یا Instruction برای ورودی لازم است؛ نام‌گذاری دیداری به‌تنهایی نباید رابطه برنامه‌ای میان Label، Hint، Error و Input را فراموش کند.

Required و Optional را یکدست اعلام کنید

یکی از دو سیاست را انتخاب کنید: همه فیلدهای اجباری را علامت بزنید یا در فرم عمدتاً اجباری، اختیاری‌ها را مشخص کنید. ستاره بدون توضیح کافی نیست. اگر داده‌ای واقعاً لازم نیست، پرسیدن آن را حذف کنید.

پیام خطا باید کاربر را به بازیابی برساند

W3C در معیار شناسایی خطا می‌گوید وقتی خطا خودکار تشخیص داده می‌شود، فیلد خطادار باید مشخص و مشکل به‌صورت متن توصیف شود. رنگ قرمز یا آیکون به‌تنهایی کافی نیست.

فرمول چهارقسمتی خطا

1. چه شد: «فایل بارگذاری نشد.»
2. کجا/چرا: «حجم فایل ۱۸ مگابایت است.»
3. حد یا قاعده: «حداکثر حجم ۱۰ مگابایت است.»
4. بازیابی: «فایل کوچک‌تری انتخاب کنید.»

همیشه هر چهار جمله لازم نیست؛ اطلاعات شناخته‌شده را کوتاه و کنار محل خطا قرار دهید. ورودی‌های درست را حفظ کنید، Focus را مدیریت کنید و اگر چند خطا وجود دارد خلاصه‌ای قابل پیمایش بسازید.

خطای امنیتی، دقیق اما کم‌افشا

در ورود، بازیابی حساب یا پرداخت، پیام نباید وجود حساب، قواعد ضدتقلب یا جزئیات داخلی را افشا کند. «اگر حسابی با این شماره وجود داشته باشد، راهنما ارسال می‌شود» گاهی امن‌تر از اعلام مستقیم وجود/عدم وجود حساب است. متن امنیتی را با تیم امنیت و پشتیبانی تست کنید.

نتیجه نامشخص پرداخت را جدی بگیرید

در قطع شبکه پس از بازگشت از درگاه، «ناموفق» را بدون Evidence نشان ندهید. State «در حال بررسی» یا «نتیجه نامشخص» باید شناسه پیگیری، زمان بررسی، منع پرداخت تکراری و مسیر پشتیبانی داشته باشد. واحد تومان/ریال و وضعیت کسر وجه را صریح بنویسید.

پیام موفقیت و وضعیت باید قابل شنیدن باشد

Toast کوتاهی که فقط دو ثانیه دیده می‌شود، برای همه کاربران قابل دریافت نیست. معیار Status Messages در WCAG می‌خواهد تغییرهای مهمی که Focus نمی‌گیرند برای فناوری کمکی قابل تشخیص باشند. متن، نقش مناسب مثل status/alert و مدت نمایش را با شدت پیام هماهنگ کنید.

Empty State و No Result را از هم جدا کنید

«هنوز سفارشی ندارید» با «برای این فیلتر نتیجه‌ای پیدا نشد» یکی نیست. حالت نخست ممکن است Onboarding و CTA ایجاد سفارش بخواهد؛ حالت دوم باید فیلتر فعال، اصلاح جست‌وجو و پاک‌کردن محدودیت را نشان دهد. خطای مجوز، خطای شبکه و داده واقعاً خالی نیز پیام جدا می‌خواهند.

Onboarding و Tooltip را جایگزین طراحی روشن نکنید

Tooltip برای توضیح اصطلاح یا قابلیت کم‌تکرار مفید است، نه برای پنهان‌کردن نام مبهم. Onboarding باید کاربر را به First Value برساند و قابل ردکردن یا بازگشت باشد. برای طراحی Trigger، Recovery و Retention از راهنمای آنبوردینگ کاربر استفاده کنید.

اعلان و Permission Prompt باید ارزش و کنترل بدهد

پیش از درخواست مجوز سیستم‌عامل، توضیح دهید چه قابلیتی به آن نیاز دارد و اگر رد شود چه می‌شود. «برای اطلاع از وضعیت سفارش، اعلان را فعال کنید» از «اجازه اعلان می‌دهید؟» زمینه بیشتری دارد. مجوز را در لحظه نیاز بخواهید؛ Dark pattern، ترس یا گزینه‌های نامتوازن اعتماد را فرسوده می‌کند.

صدا ثابت است؛ لحن با موقعیت تغییر می‌کند

Voice شخصیت پایدار محصول است؛ Tone پاسخ آن شخصیت به Context. یک برند صمیمی نیز در خطای انتقال پول باید دقیق، آرام و مسئول باشد. برای تعریف Brand premise، واژگان و Tone matrix از راهنمای صدای برند استفاده کنید.

راهنمای سبک فارسی و واژه‌نامه بسازید

یک فایل قابل جست‌وجو باید صورت ترجیحی، صورت ممنوع، تعریف، Context، نمونه و مالک هر اصطلاح را ثبت کند. «ورود/لاگین»، «حساب/پروفایل»، «لغو/انصراف» یا «کد تخفیف/کوپن» را بر اساس تحقیق و Consistency انتخاب کنید.

قواعد ضروری برای محصول ایرانی

• ی/ک فارسی، نیم‌فاصله و فاصله‌گذاری را در همه Channelها یکسان کنید.
• عدد فارسی یا لاتین را با توجه به ورودی، خوانایی و سیستم مقصد تعریف کنید.
• واحد «تومان» یا «ریال» را کنار مبلغ بنویسید و تبدیل پنهان نکنید.
• تاریخ شمسی/میلادی، منطقه زمانی و ساعت ۱۲/۲۴ساعته را مشخص کنید.
• شماره کارت، شبا، کد ملی و موبایل را با Grouping خوانا و Copy امن نمایش دهید.
• واژه انگلیسی را فقط جایی نگه دارید که برای مخاطب روشن‌تر یا استاندارد محصول است.

RTL و Localization فقط ترجمه نیست

ترکیب فارسی، عدد و لاتین می‌تواند ترتیب دیداری را به‌هم بزند. دکمه، Breadcrumb، Icon جهت‌دار، شماره، پرانتز و Ellipsis را روی Browser و Device واقعی تست کنید. متن ترجمه‌شده ممکن است طولانی‌تر شود؛ Component نباید به‌خاطر طول رشته بشکند.

Localizer باید Context، Screenshot، محدودیت طول، نوع متغیر و توضیح Placeholder را ببیند. رشته‌هایی مثل {count} مورد را تکه‌تکه نکنید؛ قواعد جمع و ترتیب جمله باید در سطح Locale تعریف شوند.

دسترس‌پذیری بخشی از Content Quality است

زبان ساده فقط «خوش‌خوانی» نیست؛ به کاربران دارای محدودیت شناختی، زبانی یا حافظه نیز کمک می‌کند. Heading و Label باید Purpose را توصیف کنند؛ W3C در معیار Headings and Labels بر توصیفی‌بودن تأکید دارد.

• Error را فقط با رنگ یا Icon منتقل نکنید.
• Linkهای «اینجا» و چند دکمه هم‌نام را با Purpose مستقل جایگزین کنید.
• پیام تغییر State را برای Screen reader قابل تشخیص کنید.
• مخفف، اصطلاح فنی، طنز و استعاره مبهم را توضیح دهید.
• متن را در Zoom، Reflow، Voice control و Screen reader آزمایش کنید.

برای فرایند کامل نمونه‌گیری دستی و تست با فناوری کمکی، به ممیزی دسترس‌پذیری وب مراجعه کنید.

Content System را به Design System وصل کنید

دکمه، Dialog یا Form field فقط رنگ و فاصله ندارد؛ Stateهای متنی هم دارد. برای هر Component قرارداد Content بنویسید: Purpose، طول، Grammar، Variable، خطا، ترجمه، Accessibility و نمونه ممنوع. این قرارداد را کنار Token و API جزء نگه دارید. راهنمای سیستم طراحی لایه Component contract و Governance را شرح می‌دهد.

component: payment-status
states: pending | success | failed | unknown
required variables: amount, currency, reference_id
tone: calm, factual
accessibility: status or alert by severity
fallback: never show raw backend error
owner: Payments + Content Design

Workflow نویسندگی UX از Brief تا Release

1. مسئله: Task، مخاطب، State، ریسک و Outcome را تعریف کنید.
2. Evidence: پژوهش، Ticket، Log و محدودیت حقوقی/فنی را جمع کنید.
3. Content-first flow: مسیر و پیام‌ها را پیش از Polish بصری بنویسید.
4. Critique: نسخه‌ها را با Product، Design، Engineering، Support و متخصص دامنه مرور کنید.
5. Prototype: متن را در UI، طول واقعی و تمام Stateها تست کنید.
6. Research: فهم، پیش‌بینی نتیجه و بازیابی را با کاربر بسنجید.
7. Handoff: String ID، Context، Variable، State و Acceptance criteria تحویل دهید.
8. QA/Release: Build واقعی، RTL، دسترس‌پذیری، Analytics و Rollback را کنترل کنید.

رشته‌ها را در طرح جا نگذارید

متن نهایی باید در منبع نسخه‌پذیر—CMS، Localization platform یا Repository—با ID پایدار باشد. Screenshot تنها مرجع توسعه نیست. تغییر Copy نیز Review، تاریخ و مالک می‌خواهد؛ Hotfix بدون Sync دوباره تناقض می‌سازد.

میکروکپی را چگونه تست کنیم؟

ابتدا تست فهم انجام دهید: کاربر با خواندن دکمه چه نتیجه‌ای را پیش‌بینی می‌کند؟ پس از خطا چه کاری انجام می‌دهد؟ Cloze test، First-click، Usability task و مصاحبه کوتاه می‌توانند مشکل را پیش از Experiment آشکار کنند.

سپس رفتار و Outcome را با داده ببینید. طراحی UX داده‌آگاه کمک می‌کند Signal کیفی و کمی را ترکیب کنید؛ نرخ کلیک بدون فهم علت، معیار ناقصی است.

اگر تغییر متن را A/B می‌کنید، Conversion را با کیفیت نتیجه، شکایت، بازپرداخت و اعتماد بسنجید. افزایش کلیک با پنهان‌کردن پیامد، بهبود UX نیست. برای قرارداد آزمایش و تصمیم اقتصادی از راهنمای CRO و Experiment استفاده کنید.

شاخص‌های عملیاتی UX Writing

• Task success: کاربر بدون کمک به نتیجه درست رسید؟
• Error rate و recovery: خطا چند بار رخ داد و چند نفر اصلاح کردند؟
• Time/attempts: چند تلاش و چه مدت لازم بود؟
• Support contact: کدام پیام یا State Ticket می‌سازد؟
• Comprehension: کاربر نتیجه دکمه و وضعیت سیستم را درست توضیح می‌دهد؟
• Consistency debt: چند واژه متعارض یا String بدون مالک داریم؟
• Accessibility defects: Error، Label یا Status چند نقص دارد؟

اشتباه‌های رایج در UX Writing

• ورود در پایان پروژه: نویسنده را در کشف مسئله و State model وارد کنید.
• «کوتاه‌تر همیشه بهتر است»: پیامد و راه بازیابی را حذف نکنید.
• CTA تبلیغاتی در عمل حساس: نتیجه واقعی را نام ببرید.
• Placeholder به‌جای Label: Label پایدار و رابطه برنامه‌ای بسازید.
• خطای خام Backend: پیام امن و قابل اقدام ترجمه کنید و شناسه پیگیری بدهید.
• همه‌جا یک Tone: لحن را با ریسک و احساس موقعیت تطبیق دهید.
• ترجمه بدون Context: Screenshot، Variable و State را به Localizer بدهید.
• سنجش فقط با Conversion: Recovery، شکایت، اعتماد و نتیجه معتبر را نیز ببینید.

چک‌لیست بازبینی میکروکپی

• Task، State، مخاطب و پیامد اقدام معلوم است.
• کاربر نتیجه دکمه را پیش از کلیک پیش‌بینی می‌کند.
• Label، Hint، Example و Error نقش جدا دارند.
• خطا محل مشکل و راه اصلاح را با متن توضیح می‌دهد.
• پرداخت، حذف و امنیت مبلغ/اثر/بازیابی روشن دارند.
• واژه‌ها با Glossary و Voice/Tone هماهنگ‌اند.
• ی/ک، نیم‌فاصله، عدد، تاریخ و تومان/ریال کنترل شده‌اند.
• RTL، طول ترجمه، Zoom و Screen reader تست شده‌اند.
• تمام Stateها—خالی، Loading، موفق، شکست و Unknown—متن دارند.
• String ID، Context، Owner، Analytics و Rollback ثبت شده‌اند.

جمع‌بندی: میکروکپی خوب کاربر را سرگرم نمی‌کند؛ ابهام را کم می‌کند، State را آشکار می‌سازد و راه اقدام یا بازیابی می‌دهد. بهترین تیم‌ها کلمات را از منطق محصول، پژوهش و Design System جدا نمی‌کنند. یک جریان پرریسک—مثلاً پرداخت یا بازیابی حساب—را انتخاب کنید، Stateها و پیام‌هایش را روی کاغذ بیاورید، با کاربران فارسی‌زبان تست کنید و نتیجه را با Task success و Recovery بسنجید.

پرسش‌های متداول

تفاوت UX Writing و Microcopy چیست؟

میکروکپی یک قطعه کوچک متن مثل Label، دکمه یا پیام خطاست. UX Writing فرایند گسترده طراحی زبان کل تجربه، Stateها، Voice/Tone، واژه‌نامه، تست و نگهداشت همین قطعات است. میکروکپی خروجی است؛ UX Writing سیستم تصمیم‌گیری پیرامون آن.

متن مناسب دکمه CTA چه ویژگی دارد؟

نتیجه عمل را با فعل و شیء روشن بیان می‌کند، در Context مستقل قابل فهم است و درباره هزینه یا برگشت‌پذیری فریب نمی‌دهد. «ثبت سفارش» معمولاً از «تأیید» و «حذف حساب» از «بله» دقیق‌تر است؛ نسخه نهایی را در UI واقعی تست کنید.

پیام خطای خوب چگونه نوشته می‌شود؟

فیلد یا محل مشکل را مشخص می‌کند، خطا را به زبان ساده توضیح می‌دهد و اگر راه اصلاح معلوم است آن را می‌گوید. کاربر را سرزنش نمی‌کند، ورودی درست را حفظ می‌کند و در موضوعات امنیتی جزئیات حساس را افشا نمی‌کند.

آیا Placeholder می‌تواند جای Label فرم باشد؟

معمولاً خیر. Placeholder با تایپ ناپدید می‌شود و برای مرور، حافظه و فناوری کمکی محدودیت دارد. Label باید پایدار و به‌صورت برنامه‌ای به Input متصل باشد؛ Hint و Example نیز فقط اطلاعات تکمیلی بدهند.

اثر UX Writing را با چه KPIهایی بسنجیم؟

Task completion، First-pass success، نرخ خطا، موفقیت بازیابی، تعداد تلاش، زمان انجام، Ticket پشتیبانی و فهم نتیجه را کنار Conversion ببینید. افزایش کلیک اگر به اشتباه، شکایت یا پرداخت تکراری منجر شود، موفقیت محسوب نمی‌شود.