طراحی CTA؛ از متن و دسترس‌پذیری تا تبدیل

کاربر روی «ادامه» می‌زند، اما نمی‌داند وارد پرداخت می‌شود یا فقط مرحله بعد فرم را می‌بیند. دوباره می‌زند؛ دکمه دو درخواست می‌فرستد، Spinner بی‌پایان می‌ماند و در Analytics دو Click ثبت می‌شود. داشبورد می‌گوید CTA عالی کار کرده، مشتری می‌گوید سفارش من چه شد. مسئله رنگ دکمه نیست؛ قول، عمل، State و Measurement با هم Contract ندارند.

طراحی دکمه CTA مؤثر یعنی کاربر پیش از فعال‌کردن بداند چه اقدام و هزینه‌ای در انتظار اوست، بتواند آن را با Mouse/Touch/Keyboard/Assistive technology انجام دهد، نتیجه و خطا را بفهمد و در صورت Failure بازیابی شود. تیم نیز باید Click را از Outcome واقعی جدا و اثر تغییر را با Guardrail بسنجد. رنگ نارنجی، فوریت یا ضمیر اول‌شخص نسخه جهانی نیست.

پاسخ کوتاه: CTA خوب هشت جزء دارد

1. Actor/Context: چه کسی در کدام مرحله Journey است؛
2. Job/Outcome: چرا اکنون اقدام می‌کند؛
3. Offer/Evidence: پیش از اقدام چه چیزی باید بداند و باور کند؛
4. Label: فعل و نتیجه روشن؛
5. Cost/Consequence: قیمت، داده، زمان، تعهد یا تغییر State؛
6. Interaction: Role، Focus، Keyboard، Touch و State؛
7. Recovery: Loading، Error، Duplicate، Cancel و Resume؛
8. Measurement: Exposure→Action→Verified outcome→Guardrail.

این مقاله مالک CTA در سطح Component و Journey است. برای معماری کلی صفحه و Route، راهنمای طراحی صفحه اصلی و برای Usability سراسری طراحی سایت کاربرپسند را ببینید.

CTA با Button یکی نیست

CTA ممکن است Link باشد؛ هر Button لزوماً CTA نیست. ظاهر و Semantic باید با Function سازگار باشد. لینک را با Click handler مبهم و Button را با div تقلید نکنید.

پیش از دکمه: Decision readiness را بسازید

اگر کاربر هنوز Audience fit، Offer، Price/Range، Evidence، Constraint، Risk و Next step را نمی‌داند، برجسته‌ترکردن CTA مشکل را حل نمی‌کند. پیش از Action این سؤال‌ها پاسخ داده شوند:

• چه چیزی دریافت می‌کنم و چه چیزی نه؟
• برای چه کسی مناسب/نامناسب است؟
• هزینه یا Range و زمان چیست؟
• چه داده/مجوز/تعهدی می‌دهم؟
• بعد از کلیک چه مرحله‌ای می‌آید؟
• چه Evidence یا Recovery وجود دارد؟
• لغو، برگشت یا ویرایش چگونه است؟

راهنمای اعتمادسازی مبتنی بر Evidence رابطه Claim، Proof، Policy و Recovery را عمیق‌تر می‌کند.

CTA brief یک‌صفحه‌ای

actor/context/job
current state → desired state
promise + evidence + constraints
action + data/cost/commitment
label + supporting microcopy
success/failure/recovery
primary/secondary/escape
events/outcome/guardrails
owner/source/review date

«افزایش کلیک» Outcome نیست. اگر CTA تماس را زیاد کند اما Leadهای نامرتبط و زمان پاسخ را دوبرابر کند، ممکن است کسب‌وکار بدتر شده باشد.

Label؛ فعل + موضوع + نتیجه یا مرحله بعد

Label کوتاه‌ترین متن ممکن نیست؛ کوتاه‌ترین متنِ کافی در Context است. Voice اول‌شخص یا دوم‌شخص را از Brand و زبان طبیعی مخاطب انتخاب و آزمایش کنید؛ ادعای جهانی «اول‌شخص تا ۹۰٪ بهتر است» قابل‌دفاع نیست.

Visible label و Accessible name هم‌معنا باشند

W3C APG درباره Accessible names می‌گوید نام باید Purpose را منتقل و Elementها را از هم متمایز کند. متن دیده‌شده را با aria-label نامرتبط جایگزین نکنید؛ کاربر Voice control و Screen reader ممکن است تجربه متفاوتی بگیرد.

در فهرست چند Item، «حذف» به‌تنهایی متمایز نیست؛ «حذف فاکتور ۱۴۰۵-۰۲» روشن‌تر است. اگر Icon تنها دارید، Accessible name و Tooltip/Description لازم را فراهم کنید.

Microcopy؛ هزینه و ابهام را نزدیک Action کم کنید

Microcopy زیر/کنار CTA جای پنهان‌کردن شرط نیست. فقط اطلاعات تصمیم‌ساز کوتاه را نزدیک اقدام بگذارید:

• «بدون نیاز به کارت بانکی» اگر واقعاً درست است؛
• «پس از بازبینی، زمان پیشنهادی ایمیل می‌شود»؛
• «با ادامه، سفارش هنوز پرداخت نمی‌شود»؛
• «فایل PDF، حجم ۲٫۱ مگابایت»؛
• «پاسخ معمول در روز کاری بعد» با Source/SLA واقعی؛
• «اطلاعات برای پاسخ به درخواست استفاده می‌شود» با Link جزئیات.

عبارت «اطلاعات شما کاملاً امن است» ادعای مطلق و بی‌شاهد است. Purpose، Retention یا Control مرتبط را دقیق بگویید.

Primary، Secondary، Tertiary و Escape

«یک CTA در هر صفحه» قانون نیست. یک هدف اصلی در هر Context تصمیم مفید است، اما Checkout به Back، Edit، Help و Cancel نیز نیاز دارد. Hierarchy را بر Risk/Task بسازید، نه حذف انتخاب مشروع.

رنگ جادویی وجود ندارد

Salience از Contrast، Size، Position، Spacing، Motion، Label و Competition می‌آید. دکمه ممکن است با Background Contrast خوبی داشته باشد اما متن روی آن خوانا نباشد یا Focus indicator گم شود.

• Contrast متن/آیکون و Component state را طبق Target استاندارد بررسی کنید؛
• در High contrast/forced colors نیز State قابل‌تشخیص باشد؛
• رنگ تنها نشانه Primary/Error/Disabled نباشد؛
• Hover جای Focus/Touch feedback را نگیرد؛
• Brand palette را بهانه پنهان‌شدن یا Neonشدن CTA نکنید؛
• Screenshot زیبا جای Task test نیست.

Position تابع Readiness است، نه Above-the-fold dogma

CTA ساده و کم‌هزینه ممکن است در Hero مناسب باشد؛ خرید پیچیده به Evidence، Comparison و Risk پاسخ‌داده‌شده نیاز دارد. CTA را در نقاطی بگذارید که سؤال تصمیم کامل شده است:

promise understood → evidence seen → objection resolved
→ consequence known → action available

تکرار یک CTA در صفحه بلند می‌تواند مفید باشد اگر Label و Destination ثابت و Context کافی باشد. Sticky CTA نباید Content، Cookie control، Keyboard focus یا Zoom را بپوشاند.

اندازه هدف؛ WCAG ۲.۲ را دقیق بخوانید

WCAG 2.2 Understanding Target Size (Minimum) در SC ۲.۵.۸ سطح AA، هدف Pointer را حداقل ۲۴×۲۴ CSS pixel می‌داند یا برای Target کوچک‌تر شرایط Spacing و چند استثنا تعریف می‌کند. این با ادعای «همه دکمه‌ها حتماً ۴۴ یا ۴۸ مربع» یکی نیست.

۲۴ حداقل Conformance در این معیار است، نه لزوماً اندازه بهینه. برای CTA مهم، حرکت دست، Tremor، شلوغی، موبایل، محیط حرکت و خطای لمس را بسنجید و در صورت امکان هدف بزرگ‌تر/فاصله بیشتر بدهید. Padding قابل‌کلیک باید واقعاً داخل Hit area باشد.

Native button و link را ترجیح دهید

W3C APG Button Pattern نقش، Accessible name، فعال‌سازی با Space/Enter و مدیریت Focus پس از Action را توضیح می‌دهد. APG راهنمای Informative است؛ Native HTML معمولاً Semantics و Keyboard behavior پایه را آماده می‌دهد.

<button type="submit">ارسال درخواست ارزیابی</button>
<a href="/plans">مشاهده مقایسه پلن‌ها</a>

button داخل Form بدون type ممکن است ناخواسته Submit کند. Disabled native control Focus نمی‌گیرد؛ اگر کاربر باید دلیل unavailable بودن را بفهمد، الگوی State/Description و مسیر رفع مشکل را طراحی کنید.

Focus و تغییر Context پس از فعال‌سازی

Toast بصری که Screen reader نمی‌شنود یا Focus به ابتدای DOM می‌پرد، Action را ناقص می‌کند.

State machine CTA را بنویسید

idle → hover/focus/pressed
→ validating → submitting
→ success | field-error | system-error | timeout | unknown
→ retry | edit | cancel | resume | reconcile

State فقط Style نیست؛ چه Action مجاز است، Label چیست، Focus کجاست، چه پیام و Telemetry دارد و کاربر چگونه بازیابی می‌شود را تعریف می‌کند.

Double-click و Idempotency

فقط Disableکردن فوری دکمه کافی نیست؛ Network retry، Back button، Refresh یا Callback تکراری همچنان رخ می‌دهد. برای عملیات اثرگذار:

• Client duplicate prevention متناسب؛
• Server-side idempotency key؛
• Source-of-truth state؛
• Timeout/unknown outcome screen؛
• Reconciliation و Support lookup؛
• Safe retry و receipt/reference؛
• Telemetry بدون duplicate outcome.

Spinner بی‌پایان را موفقیت فرض نکنید. اگر نتیجه نامعلوم است، کاربر را به پرداخت/ارسال دوباره کور هدایت نکنید.

Loading و Disabled microcopy

Destructive CTA و Confirmation

برای حذف حساب، لغو اشتراک، Refund یا انتشار عمومی، Consequence را دقیق و متناسب نشان دهید. Confirmation برای هر Action کوچک خستگی می‌سازد؛ برای Action برگشت‌ناپذیر یا پرهزینه مفید است.

• Object/Scope را نام ببرید؛
• اثر فوری و دیرهنگام را بگویید؛
• Undo/Grace period اگر ممکن است؛
• Primary destructive را از Cancel جدا کنید؛
• Type-to-confirm فقط وقتی Risk توجیه می‌کند؛
• Focus و Keyboard flow را تست کنید.

فوریت و کمیابی؛ فقط اگر واقعی، دقیق و قابل‌اثبات است

گزارش Dark Patterns کمیسیون تجارت فدرال آمریکا Countdown بی‌پایه/Resetشونده، پیام محدودیت دروغین و Discount ساختگی را از الگوهای فریبنده می‌داند. این منبع قانون ایران نیست، اما ریسک اخلاقی و اعتماد را خوب نشان می‌دهد.

Deadline، Inventory، Capacity و Price comparison باید Source و Update rule داشته باشند. «فقط تا امشب» اگر فردا Reset می‌شود، آزمایش Conversion نیست؛ فریب است. برای چارچوب کامل‌تر به راهنمای طراحی اخلاقی و Dark Pattern مراجعه کنید.

CTA نباید اطلاعات مهم را پنهان کند

• قیمت کل، دوره Billing و تمدید؛
• Free trial→Paid و زمان Charge؛
• هزینه ارسال/مالیات/کارمزد مهم؛
• شرط لغو/مرجوعی/تعهد؛
• داده و Consent؛
• محدودیت محصول/خدمت؛
• Prechecked option یا Add-on؛
• Destination/Download/External context.

Microcopy کم‌رنگ یا Terms دور، Information scent را جبران نمی‌کند. Cancel و Decline را عمداً پنهان یا شرم‌آور نکنید.

اعتماد با Badge عمومی ساخته نمی‌شود

قفل Icon ممکن است فقط TLS را تداعی کند و «کاملاً امن» القا کند. Evidence متناسب نزدیک تصمیم:

CTA در Form؛ Click پایان کار نیست

Label/Instruction/Error باید با Button همکاری کنند. Form موفق یعنی Data معتبر، Consent مناسب، Backend receipt، Notification و Downstream state. اگر پیام «ارسال شد» می‌آید اما CRM هیچ Leadی ندارد، Conversion رخ نداده است.

form_view → form_start → validation_error
→ submit_attempt → server_accepted
→ lead_created(unique) → qualified/outcome
→ response/closure
guardrails: spam, duplicate, PII, latency, support

Measurement ladder برای CTA

مرجع Eventهای پیشنهادی GA4، generate_lead را برای وقتی می‌داند که Lead تولید شده، نه وقتی Button کلیک شده است. Contract Event را با Backend/CRM reconcile کنید.

Event dictionary نمونه

event: cta_activate
trigger: successful activation before navigation/action
properties: cta_id, label_version, placement, journey, experiment
privacy: no PII/free text
dedup: interaction_id
owner/source/version

event: lead_created
trigger: CRM/lead source accepts unique record
properties: lead_id_hash, source, form_version
reconcile: client interaction_id ↔ server/CRM
guardrails: duplicate, spam, error, time_to_response

Label کامل، Email/Phone یا متن آزاد را بی‌دلیل به Analytics نفرستید. Consent و Retention را طراحی کنید.

CTR را با Conversion rate قاطی نکنید

CTA CTR = unique eligible activators / eligible exposed users
Submit success = accepted submissions / submit attempts
Verified conversion = unique verified outcomes / eligible users
Qualified rate = qualified outcomes / verified outcomes
Value/guardrail = incremental value with error/refund/support/privacy

Denominator و Window را ثابت کنید. CTA تکرارشده، چند Device، Refresh و Event duplicate می‌تواند نسبت را خراب کند.

Diagnosis؛ وقتی CTA کم کلیک می‌گیرد

رنگ تنها یکی از فرض‌هاست و اغلب اولین سؤال نیست.

تحقیق کیفی پیش از A/B

• آیا کاربر Offer را با زبان خودش توضیح می‌دهد؟
• پیش‌بینی می‌کند کلیک چه می‌کند؟
• هزینه و محدودیت را می‌بیند؟
• Primary و Escape را تشخیص می‌دهد؟
• با Keyboard/Touch/Screen reader انجام می‌دهد؟
• در Error/Timeout/Unknown چگونه بازیابی می‌شود؟
• Success را از رسید/Reference می‌فهمد؟

برای ساخت Task، Sample و Observation از راهنمای تست کاربردپذیری استفاده کنید.

A/B test؛ Hypothesis نه «رنگ A در برابر B»

because evidence...
for eligible audience/context...
changing promise/label/placement/state...
will improve verified outcome...
measured by primary metric...
without harming guardrails...
for minimum sample/window...
decision: ship/hold/iterate/rollback

یک تغییر کوچک تفسیر را آسان‌تر می‌کند، اما Multivariate interaction ممکن است واقعی باشد. Sample size، seasonality، novelty، SRM، multiple comparisons و implementation QA را قبل از نتیجه ببینید. هر افزایش مشاهده‌شده Cause قطعی نیست.

Experiment unit و Contamination

• User/Session/Account assignment بر اساس Journey؛
• Variant persistence بین Page/Device تا حد ممکن؛
• Bot/internal traffic filtering؛
• هم‌زمانی Campaign/Price/Inventory؛
• Cross-device و Anonymous→Logged-in identity؛
• Exposure event فقط بعد از Variant delivery؛
• Server outcome join و duplicate control؛
• Predefined stop/decision rule.

Peeking روزانه و توقف در اولین عدد مثبت False positive می‌سازد. برای معماری Measurement از راهنمای UX داده‌آگاه استفاده کنید.

Guardrailهای اخلاقی و عملیاتی Experiment

Performance؛ CTA دیده اما دیر قابل‌استفاده

Hero CTA ممکن است HTML دیده شود ولی Hydration/Third-party آن را دیر Interactive کند؛ Layout shift نیز لحظه کلیک Target را جابه‌جا می‌کند. RUM را برای Visibility→Interaction→Response به Template/Device/Network متصل کنید.

• Server-rendered Link/Button در صورت امکان؛
• کمینه‌کردن JS/third-party blocker؛
• Stable dimensions برای Font/Icon/Layout؛
• Response feedback سریع و قابل‌اعلان؛
• Timeout/retry/recovery واقعی؛
• Field INP/CLS و action latency.

برای Field diagnosis از راهنمای Core Web Vitals و RUM کمک بگیرید.

فارسی، RTL و CTA

• فعل و Outcome طبیعی، نه ترجمه لفظی «Get started»؛
• ریال/تومان و رقم با Context واضح؛
• تاریخ شمسی/میلادی و Timezone؛
• شماره/Email/URL با BiDi صحیح؛
• Label کوتاه و بلند، Font load و Zoom؛
• Icon جهت‌دار متناسب با RTL و معنای واقعی؛
• نیم‌فاصله/ی/ک در Search/Analytics ID نه Label خام؛
• Touch روی شبکه ضعیف و Device میان‌رده.

CTA audit؛ از صفحه تا Backend

برنامه ۱۰روزه بهبود CTA

روز ۱ و ۲: Inventory و Outcome

CTA ID، Page/Journey، Label، Destination/Action، Owner، event و Verified outcome را فهرست کنید.

روز ۳: Research و Support evidence

ابهام، Failure، Ticket، Form error و Drop را به Hypothesis تبدیل کنید.

روز ۴ و ۵: Contract و Prototype

Promise/Cost/Label/State/Recovery را بازنویسی و با Content واقعی Prototype کنید.

روز ۶: Accessibility و Performance

Name/Role/Keyboard/Focus/Target/Reflow و Interaction latency را تست کنید.

روز ۷: Backend و Measurement

Idempotency، Receipt، Event dictionary و CRM/order reconciliation را کنترل کنید.

روز ۸ تا ۱۰: Pilot/Experiment

یک Journey پرارزش را با Guardrail منتشر، مشاهده و تصمیم را ثبت کنید.

خطاهای رایج طراحی CTA

• رنگ جادویی به‌جای Offer/Readiness؛
• Click به‌عنوان Conversion؛
• Label «ارسال/ادامه» بدون Consequence؛
• Accessible name متفاوت از متن دیده‌شده؛
• Link با Button یا div کلیک‌پذیر؛
• قانون ساختگی ۴۴–۴۸ برای WCAG AA؛
• Hover بدون Focus و Touch؛
• Disabled بی‌دلیل و بی‌راه رفع؛
• Spinner بی‌پایان و Submit تکراری؛
• Primary hierarchy با حذف Cancel/Back؛
• Sticky CTA پوشاننده Content/Focus؛
• فوریت/کمیابی دروغین؛
• Badge امنیتی و وعده مطلق؛
• A/B روی رنگ بدون Hypothesis/Guardrail؛
• Analytics client بدون Backend reconciliation.

منابع و وضعیت زمانی

این راهنما در ۱۲ اوت ۲۰۲۶ بازبینی شده است. Standard، Browser، Analytics و مقررات تغییر می‌کنند؛ نسخه و Applicability را برای محصول خود ثبت کنید.

• W3C: WCAG 2.2 Target Size (Minimum)
• W3C APG: Button Pattern
• W3C APG: Accessible Names and Descriptions
• FTC: Bringing Dark Patterns to Light
• Google Analytics: Recommended Events

سؤالات متداول طراحی CTA

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

رنگ برنده جهانی وجود ندارد. CTA باید در Context قابل‌یافتن، متن/آیکون آن خوانا، Focus و State آن قابل‌تشخیص و Hierarchy آن متناسب با Task باشد. Offer، Label، Evidence و Failure اغلب از Hue مهم‌ترند؛ با کاربر و Outcome واقعی بسنجید.

در هر صفحه چند CTA داشته باشیم؟

تعداد ثابت نداریم. برای هر Context یک هدف اصلی روشن بسازید، اما Secondary، Help، Back، Cancel یا Compare مشروع را حذف نکنید. چند Placement با Action ثابت در صفحه بلند ممکن است مناسب باشد؛ چند هدف هم‌وزن و بی‌Hierarchy معمولاً گیج‌کننده است.

حداقل اندازه دکمه در WCAG ۲.۲ چقدر است؟

SC ۲.۵.۸ سطح AA حداقل ۲۴×۲۴ CSS pixel را مقرر می‌کند یا برای Target کوچک‌تر Spacing و استثناهایی دارد. این حداقل Conformance لزوماً بهترین UX نیست؛ CTA مهم ممکن است به Hit area بزرگ‌تر و فاصله بیشتر نیاز داشته باشد.

چرا کلیک CTA زیاد است اما فروش یا Lead کم است؟

Click فقط Intent است. Validation/API/Payment/CRM ممکن است Fail کند، Event duplicate باشد، Offer مخاطب نامرتبط جذب کند یا Downstream quality پایین باشد. Exposure→Action→Server accepted→Verified/qualified outcome را با Error/Spam/Refund/Support reconcile کنید.

برای CTA چه A/B تستی انجام دهیم؟

از Evidence یک Hypothesis بسازید: تغییر Promise/Label/Placement/State برای Audience واجد باید Verified outcome را بدون آسیب به Guardrail بهتر کند. Assignment، Exposure، Sample/window، Backend join و Decision rule را پیشاپیش ثبت کنید؛ رنگ تصادفی نقطه شروع اجباری نیست.

جمع‌بندی: CTA یک قول اجرایی است

CTA خوب فریاد نمی‌زند؛ تصمیم را روشن و عمل را قابل‌اعتماد می‌کند. کاربر Purpose و Consequence را می‌فهمد، با Inputهای مختلف اقدام می‌کند، State و Failure را می‌بیند و می‌تواند بازیابی شود. کسب‌وکار نیز Outcome یکتا را از Click جدا می‌سنجد.

یک CTA پرارزش را انتخاب کنید و زنجیره‌اش را تا Backend روی کاغذ بنویسید: «چه کسی، چرا، چه قولی، چه هزینه‌ای، چه Stateهایی، چه نتیجه‌ای و چه Guardrailی». هر جا پاسخ ندارید، همان‌جا احتمالاً فرصت اصلی Conversion است—نه الزاماً در Color picker.