CTA باید معلوم کند کاربر با انتخاب آن چه کاری انجام می‌دهد. در صفحه معرفی یک سرویس، «مشاهده طرح‌ها» با «ایجاد حساب» یا «پرداخت اشتراک» یکسان نیست. اگر همه را با عبارت «شروع کنید» نمایش دهید، کاربر تا مرحله بعد نتیجه را حدس می‌زند. طراحی Call to Action از روشن کردن همین نتیجه شروع می‌شود؛ رنگ و اندازه بعد از آن معنا پیدا می‌کنند.
CTA همیشه مهم‌ترین عنصر هر صفحه نیست. در صفحه اعلام اختلال، توضیح وضعیت و در فرم پرداخت، مبلغ و خطا می‌توانند اولویت داشته باشند. برجسته کردن عمل پیش از اطلاعات لازم، تصمیم را بهتر نمی‌کند. ابتدا مشخص کنید کاربر در این صفحه چه چیزی باید بفهمد و سپس چه اقدامی برای او و محصول مناسب است. این ترتیب از انتخاب یک رنگ «پرفروش» قابل اتکاتر است.
عمل مطلوب را دقیق تعریف کنید
در نمونه فرضی یک سرویس مدیریت پروژه، بازدیدکننده ممکن است بخواهد قیمت را بداند، نمونه محیط را ببیند یا حساب بسازد. این مثال، گزارش نتیجه یک مشتری واقعی نیست. اگر صفحه برای مقایسه طرح‌ها نوشته شده، CTA اصلی باید کاربر را به همان مقایسه برساند. درخواست ثبت‌نام فوری قبل از پاسخ قیمت، ممکن است با سؤال فعلی او هماهنگ نباشد.
برای هر CTA بنویسید چه چیزی تغییر می‌کند: صفحه مقصد باز می‌شود، فرم ارسال می‌شود یا عملی روی داده انجام می‌گیرد؟ این تعریف به انتخاب عنصر HTML هم کمک می‌کند. رفتن به یک URL معمولاً وظیفه link است و اجرای عمل وظیفه button. ظاهر شبیه دکمه، به تنهایی دلیل تغییر معنای عنصر نیست. رفتار Keyboard و امکان باز کردن مقصد در تب دیگر باید طبیعی بماند.
هدف کسب‌وکار را به یک کلیک محدود نکنید. ممکن است افزایش کلیک همراه با کاهش تکمیل ثبت‌نام رخ دهد، چون متن وعده‌ای داده که مرحله بعد برآورده نمی‌کند. موفقیت باید به نتیجه معنادار مربوط شود: درخواست معتبر، خرید آگاهانه یا انجام وظیفه. CTA مناسب، کاربر را به مسیری می‌برد که با توضیح صفحه و انتظار او هماهنگ است.
نام کنترل نتیجه واقعی را بیان کند
راهنمای Button در GOV.UK Design System متن توصیف‌کننده عمل را پیشنهاد می‌کند و بین ذخیره، ادامه و پرداخت فرق می‌گذارد. در فارسی هم «ذخیره و ادامه» زمانی درست است که داده واقعاً ذخیره شود. اگر فقط مرحله بعد باز می‌شود، واژه ذخیره وعده اضافی می‌دهد. این مرجع را برای اصل وضوح بخوانید؛ محل و لحن رابط انگلیسی آن را به فارسی تحمیل نکنید.
«شروع رایگان» فقط وقتی مناسب است که شرایط رایگان بودن روشن باشد. دوره آزمایشی، نیاز به اطلاعات پرداخت و هزینه پس از پایان باید در محل قابل یافتن توضیح داده شوند. لازم نیست همه شرط‌ها روی دکمه نوشته شوند، اما نباید نتیجه مهمی تا بعد از کلیک پنهان بماند. متن کمکی کنار CTA می‌تواند همین اطلاعات مرتبط را ارائه کند.
برای عمل نهایی، واژه‌های مبهم خطر بیش‌تری دارند. «تأیید» ممکن است مرور اطلاعات یا پرداخت را نشان دهد. نامی مانند «پرداخت و ثبت سفارش» نتیجه را روشن‌تر می‌کند، اگر رفتار محصول همین باشد. واحد و مبلغ را در زمینه نزدیک نگه دارید. متن دکمه نباید جای فهرست هزینه را بگیرد و نباید با مبلغ مرحله بعد اختلاف داشته باشد.
وزن عمل اصلی و جایگزین را جدا کنید
در یک بخش تصمیم، عمل اصلی را از گزینه‌هایی مانند خواندن راهنما یا ذخیره پیش‌نویس جدا کنید. تفاوت وزن دیداری باید با ترتیب کار هماهنگ باشد. همه گزینه‌ها لازم نیست زمینه پررنگ داشته باشند. اگر چند عمل هم‌ارزش واقعاً وجود دارند، با عنوان و توضیح تفاوتشان را روشن کنید؛ انتخاب تصادفی یکی به عنوان اصلی ممکن است نیاز کاربر را محدود کند.
تکرار CTA در صفحه بلند زمانی مفید است که کاربر پس از خواندن یک بخش آماده همان اقدام باشد. متن و مقصد تکرارها باید هماهنگ بمانند. اگر یک دکمه به طرح‌ها و دیگری به ثبت‌نام می‌رود، با نام یکسان نمایش ندهید. تعداد زیاد دکمه با هدف‌های متفاوت، مرور صفحه را به رقابت دائمی برای توجه تبدیل می‌کند.
عمل مخرب را با عمل ادامه اشتباه نگیرید. حذف حساب، لغو سفارش و ارسال درخواست قراردادهای متفاوتی دارند. برای عمل برگشت‌ناپذیر، نام و توضیح نتیجه باید روشن باشد و مرحله تأیید متناسب طراحی شود. رنگ هشدار به تنهایی کافی نیست؛ کاربران باید بدون تشخیص رنگ هم بفهمند چه چیزی حذف خواهد شد و چه چیزی باقی می‌ماند.
محل CTA از مسیر اطلاعات بیاید
قرار دادن CTA بالای صفحه همیشه انتخاب بهتر نیست. در یک سرویس ساده، معرفی کوتاه ممکن است برای شروع کافی باشد. در تصمیم پرهزینه، کاربر به شرایط و مقایسه نیاز دارد. می‌توانید در ابتدای صفحه مسیر دیدن جزئیات بدهید و پس از اطلاعات لازم، عمل نهایی را نشان دهید. موقعیت باید با آمادگی تصمیم هماهنگ باشد، نه با قانون عمومی above the fold.
ارتفاع fold ثابت نیست؛ دستگاه، اندازه متن و نوارهای مرورگر فضای قابل مشاهده را تغییر می‌دهند. چیدمانی که در یک screenshot دکمه را کامل نشان می‌دهد، ممکن است در دستگاه دیگر چنین نباشد. کاربر باید از عنوان و ساختار بفهمد محتوا ادامه دارد. برای نگه داشتن CTA در قاب اولیه، توضیح ضروری را ریز یا حذف نکنید.
CTA ثابت در پایین صفحه می‌تواند دسترسی را آسان کند، اما نباید فیلد یا محتوای دارای Focus را بپوشاند. در عرض کوچک، فضای اشغال‌شده و safe area را در نظر بگیرید. اگر دکمه به بخشی از صفحه می‌رود، مقصد و عنوان آن روشن باشند. مقاله Visual Hierarchy برای هماهنگی محل، برجستگی و ترتیب محتوا ادامه مرتبط است.
اندازه و Contrast را با معیار درست بررسی کنید
ارتفاع 44 pixel یک قانون عمومی AA برای هر CTA نیست. Target Size Minimum در WCAG 2.2 اندازه 24 در 24 CSS pixel یا شرایط فاصله‌گذاری و استثناهای مشخص را بیان می‌کند. برای استفاده راحت، می‌توانید هدف بزرگ‌تری طراحی کنید، اما عدد پیشنهادی محصول را با متن استاندارد یکی ننامید. ناحیه فعال باید با ظاهر کنترل هماهنگ باشد.
متن دکمه با زمینه آن یک جفت رنگ است. Contrast آن را برای حالت عادی، hover و Focus بررسی کنید. رنگ accent روشن با متن سفید همیشه خوانا نیست. مرز ضروری و نشانه Focus هم باید دیده شوند. کم‌رنگ کردن دکمه جای توضیح وضعیت را نمی‌گیرد؛ کاربر باید بفهمد آیا کنترل disabled است یا فقط یک عمل کم‌تأکیدتر است.
از رنگ به عنوان تنها نشانه عمل استفاده نکنید. نام، شکل متعارف و زمینه قرارگیری کمک می‌کنند کنترل شناخته شود. برای لینک داخل متن، نشانه مناسب مانند underline را حفظ کنید. مقاله دسترسی‌پذیری از روز اول این رفتارها را همراه Keyboard و نام قابل دسترس بررسی می‌کند. زیبایی CTA بدون امکان انتخاب، هدف آن را برآورده نمی‌کند.
حالت انتظار و خطا بخشی از CTA هستند
بعد از ارسال، کاربر باید بداند درخواست در حال پردازش است. اگر تکرار عمل هزینه دارد، کنترل تکرار را در رابط و سرور هماهنگ کنید. تغییر متن به «در حال ارسال» کمک می‌کند، اما نتیجه قطعی را پیش از پاسخ معتبر اعلام نکنید. در خطا، مسیر تلاش دوباره را ارائه دهید و داده معتبر را حفظ کنید تا کاربر کار قبلی را بی‌دلیل تکرار نکند.
استفاده از disabled را با نیاز واقعی توجیه کنید. دکمه‌ای که از ابتدا بی‌توضیح غیرفعال است، به کاربر نمی‌گوید کدام شرط کم است. گاهی اجازه ارسال و نمایش خطای دقیق روشن‌تر است. اگر عمل واقعاً در آن وضعیت ممکن نیست، دلیل را کنار کنترل بیان کنید. تفاوت «هنوز اطلاعات کامل نیست» و «شما اختیار ندارید» باید در پیام دیده شود.
برای مسیر خارجی مثل درگاه پرداخت، رفتار خروج و بازگشت را طراحی کنید. بستن صفحه به تنهایی وضعیت مالی را تعیین نمی‌کند. پیام بعد از بازگشت باید از نتیجه معتبر سیستم بیاید. CTA «دوباره پرداخت کنید» در وضعیت نامعلوم می‌تواند مشکل ایجاد کند؛ ابتدا راه بررسی وضعیت را مشخص کنید. این بخش به قرارداد عمل مربوط است و با رنگ بهتر حل نمی‌شود.
آزمایش را با فرضیه و نتیجه معنادار انجام دهید
A/B Test وقتی مفید است که حجم و روش مناسب و تفاوت قابل توضیح داشته باشید. فرضیه می‌تواند این باشد که نام دقیق‌تر، انتظار کاربر از مرحله بعد را بهتر می‌کند. نتیجه را با تکمیل کار و خطا بخوانید، نه فقط کلیک. تغییر هم‌زمان متن، رنگ و مسیر، تشخیص علت تفاوت را دشوار می‌کند. هر پروژه نیز برای هر CTA داده کافی ندارد.
قبل از اجرای آزمایش، رویداد موفقیت و دوره بررسی را تعریف کنید. توقف صرفاً وقتی یک عدد مطلوب دیده می‌شود، نتیجه قابل اتکایی نمی‌سازد. کاربران تکراری، تفاوت دستگاه و تغییر کمپین ورودی می‌توانند تحلیل را تحت تأثیر قرار دهند. اگر طراحی آزمایش معتبر ندارید، نتیجه را مشاهده محدود بنامید و از آن ادعای عمومی درباره بهترین رنگ یا چند برابر شدن تبدیل نسازید.
در محصول کم‌ترافیک، بررسی فهم متن و مشاهده انجام وظیفه می‌تواند مسئله‌های مهمی را پیدا کند. از کاربر بخواهید پیش از کلیک بگوید انتظار چه نتیجه‌ای دارد. اگر پاسخ با رفتار واقعی متفاوت است، متن یا زمینه نیاز به اصلاح دارد. این روش جای همه اندازه‌گیری‌ها را نمی‌گیرد، اما برای یافتن ابهام مشخص به حدس درباره ترجیح رنگ وابسته نیست.
قرارداد CTA را همراه طراحی تحویل دهید
برای هر کنترل، نام، مقصد یا عمل، حالت انتظار و نتیجه خطا را ثبت کنید. UX Writing برای متن این حالت‌ها و Loading States برای بازخورد انتظار ادامه‌های مرتبط‌اند. وقتی مسیر محصول تغییر می‌کند، متن CTA نیز باید بازبینی شود؛ دکمه‌ای با نام درست نسخه قبل ممکن است در نسخه جدید وعده نادرستی بدهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!