Radio Buttons | دکمه‌های رادیویی

تعریف دقیق

دکمه‌های رادیویی (radio buttons) الگوی انتخاب تک‌گزینه‌ای در فرم‌ها و تنظیمات هستند: کاربر از میان چند گزینه فقط یکی را برمی‌گزیند و انتخاب جدید به‌طور خودکار انتخاب قبلی را لغو می‌کند. نام از رادیوهای قدیمی می‌آید که با تغییر فرکانس، تنها یک ایستگاه فعال می‌ماند.

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

تعریف عملی برای تیم: وقتی پاسخ‌ها mutually exclusive اند و مقایسه هم‌زمان برای تصمیم مهم است، رادیو مناسب‌تر از dropdown یا segmented control است—مگر فضا یا تعداد گزینه‌ها مانع شود.

چرا مهم است

انتخاب اشتباه کنترل (رادیو به‌جای چک‌باکس یا برعکس) باعث خطای داده، نارضایتی و تماس پشتیبانی می‌شود. رادیو visibility همه گزینه‌ها را بالا می‌برد؛ کاربر نیاز به حدس «چه چیزهای دیگری هست» ندارد.

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

برای RTL و فارسی، طول برچسب‌ها و جهت چیدمان روی اسکن اثر دارد؛ رادیو عمودی با فاصلهٔ کافی بین گزینه‌ها خطای لمس را کم می‌کند.

چگونه کار می‌کند

طراح ابتدا cardinality را مشخص می‌کند: یک پاسخ از N. سپس گزینه‌ها را با زبان کاربر نام‌گذاری می‌کند، پیش‌فرض منطقی (یا عدم پیش‌فرض اجباری) تعیین می‌کند، و حالت خطا را طراحی می‌کند. در کد، input type=radio با name مشترک گروه را می‌سازد؛ label با for یا wrapping به input وصل می‌شود.

keyboard: فلش‌ها در برخی پلتفرم‌ها بین گزینه‌های هم‌گروه حرکت می‌کنند؛ focus ring باید دیده شود. touch: کل ناحیه label قابل ضربه باشد نه فقط دایره ۱۶px.

در design system، token اندازه، رنگ border انتخاب‌شده، و فاصله label استاندارد می‌شود تا در checkout و settings یکدست بماند.

اجزا و انواع

انواع: رادیو ساده، با توضیح ثانویه، کارت‌مانند (tile) برای گزینه‌های بصری، و segmented control در موبایل که رادیو را فشرده نشان می‌دهد. tile وقتی مفید است که هر گزینه نیاز به آیکون یا خلاصه دارد.

حالت‌ها: default، hover، focus، checked، disabled، invalid. گروه می‌تواند افقی، عمودی، یا responsive (افقی در دسکتاپ، عمودی در موبایل) باشد.

کاربرد در محصول و UX

در SaaS: انتخاب پلن billing، visibility پروژه، فرکانس اعلان. در ecommerce: روش ارسال، زمان تحویل. در onboarding: نقش کاربر. در هر جا که گزینه‌ها ۲–۵ تا و با consequence هستند، رادیو ارزش دارد.

اگر یک گزینه به‌مراتب رایج‌تر است، می‌توان آن را پیش‌فرض گذاشت اما گزینه‌های دیگر را پنهان نکنید مگر با «گزینه‌های بیشتر» شفاف.

مثال‌های عملی

مثال خوب: «روش پرداخت» با سه رادیو، برچسب واضح، آیکون کارت، و توضیح یک خطی زیر گزینه آنلاین. مثال بد: ده گزینه رادیو عمودی بدون گروه‌بندی در صفحه checkout موبایل.

مثال بد دیگر: استفاده از رادیو برای «موافقم با قوانین» که در واقع یک checkbox است. مثال خوب در B2B: انتخاب سطح SLA با consequence عددی کنار هر گزینه.

اشتباهات رایج

پیش‌فرض گذاشتن گزینه‌ای که کاربر ندیده (سوگیری). رادیو برای چندانتخاب. برچسب‌های تکراری یا اصطلاح داخلی. فاصله کم بین گزینه‌ها در موبایل. نبود feedback پس از انتخاب در جایی که step بعدی وابسته است.

در پیاده‌سازی: name متفاوت برای گزینه‌های یک گروه، یا styled div بدون نقش radio برای screen reader.

نکات پیاده‌سازی

fieldset و legend برای گروه‌های معنادار. حداقل ۴۴px ارتفاع هدف لمسی برای row. در Storybook همه حالت‌ها را مستند کنید. Design QA: RTL، zoom 200%، و keyboard-only pass.

برای analytics، event change با مقدار گزینه (بدون PII) به فهم انتخاب کاربر کمک می‌کند.

ارتباط با مفاهیم مرتبط

رادیو با checkbox، select، toggle، segmented control، فرم‌ها، design system و WCAG 2.x برای grouping و labels گره خورده است.

جمع‌بندی کاربردی

دکمه رادیویی ابزار «یکی از چند» با visibility بالاست. cardinality درست، برچسب روشن، لمسی بودن کافی، و گروه‌بندی accessible انتخاب را سریع و بدون خطا می‌کند.

نگاه از داخل تیم محصول

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

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.

چطور در جلسه تصمیم بگیریم

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

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.

بعد از انتشار چه ببینیم

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

برای تیم‌های کوچک، لازم نیست همه چیز را یک‌باره پیاده کنید. یک جریان پرتکرار را انتخاب کنید، همان‌جا اصلاح کوچک انجام دهید، و نتیجه را با داده یا بازخورد مستقیم کاربر بسنجید. اگر اثر دیدید، دامنه را گسترش دهید؛ اگر نه، فرضیه را عوض کنید—نه اینکه سراغ واژهٔ بعدی بروید. یادداشت کوتاه «چه کردیم، چه فهمیدیم» در مستند تیم، بار بعدی را سریع‌تر می‌کند. همین چرخهٔ کوچک، واژه‌نامه را از متن تئوری به ابزار کار روزمره تبدیل می‌کند.