روی کارت یک مقاله، کلمه «طراحی» را داخل یک شکل کوچک می‌بینید. آیا فقط موضوع مقاله را می‌گوید؟ با کلیک روی آن، مقاله‌های طراحی باز می‌شوند؟ یا همین صفحه فیلتر می‌شود؟ اگر پاسخ از ظاهر و موقعیت آن مشخص نباشد، سیستم برچسب‌گذاری هنوز درست طراحی نشده است. مشکل معمولاً از رنگ یا گردی گوشه‌ها شروع نمی‌شود؛ از این شروع می‌شود که یک شکل مشابه را برای چند رفتار متفاوت استفاده کرده‌ایم.
طراحی Tag و Label System یعنی برای نام‌ها، ظاهر و رفتار برچسب‌ها یک قرارداد روشن بسازیم. این قرارداد باید هم به کاربر کمک کند محتوای مرتبط را پیدا کند و هم به تیم اجازه بدهد محصول را بدون انبوهی از برچسب‌های تکراری گسترش دهد. در این راهنما، مثال‌ها فرضی‌اند و برای توضیح تصمیم‌های طراحی استفاده می‌شوند؛ محدودیت تعداد یا رنگ هم نسخه یکسانی برای همه محصولات ندارد.
Tag، Label، Chip و Badge چه تفاوتی دارند؟
Tag معمولاً یک ویژگی یا موضوع را به یک آیتم نسبت می‌دهد؛ مثلاً مقاله‌ای هم درباره «طراحی محصول» است و هم درباره «دسترس‌پذیری». Label معنای گسترده‌تری دارد: می‌تواند نام یک فیلد، عنوان یک کنترل یا یک برچسب دسته‌بندی باشد. بنابراین Label در فرم را نباید صرفاً همان کپسول رنگی کنار کارت دانست. نام فیلد ایمیل باید حتی بدون آن شکل کپسولی هم ارتباط مشخصی با ورودی داشته باشد.
Chip در بسیاری از کتابخانه‌های رابط کاربری برای نمایش یک انتخاب، ورودی کوچک یا فیلتر استفاده می‌شود. Badge اغلب وضعیت یا تعداد را نشان می‌دهد؛ مثل «پیش‌نویس» یا تعداد پیام‌های خوانده‌نشده. این مرزها در همه Design Systemها یکسان نیستند. برای نمونه، Carbon برای Tag چهار گونه read-only، dismissible، selectable و operational تعریف می‌کند. پس نام کامپوننت را از کتابخانه محصول بگیرید، اما رفتار را دقیق مستند کنید.
در یک فروشگاه، «چرم» می‌تواند ویژگی محصول باشد، «موجود» وضعیت آن، و «فقط کالاهای موجود» یک فیلتر قابل انتخاب. این سه مفهوم را با یک رنگ و یک حالت تعاملی ارائه نکنید. کاربر لازم نیست اصطلاحات Design System شما را بداند؛ باید بفهمد کدام عنصر اطلاعات می‌دهد و کدام عنصر کاری انجام می‌دهد.
قبل از طراحی ظاهر، واژگان را مرتب کنید
اگر هم «طراحی رابط»، هم «رابط کاربری» و هم «UI» را بدون تعریف مشخص وارد سیستم کنید، ممکن است محتوا میان سه نام نزدیک پخش شود. ابتدا فهرست موضوع‌ها را بنویسید و برای هر مفهوم یک نام اصلی انتخاب کنید. نام‌های جایگزین می‌توانند در جست‌وجو به همان مفهوم وصل شوند، اما لازم نیست همگی به‌عنوان برچسب جداگانه نمایش داده شوند. شناسه داخلی هم بهتر است از متن نمایشی مستقل باشد تا تغییر نام، ارتباط محتوا را از بین نبرد.
دسته‌بندی و Tag را نیز با هدفشان جدا کنید. دسته‌بندی معمولاً مسیر اصلی سازمان‌دهی است و Tag می‌تواند ارتباط‌های جزئی‌تر و چندگانه بسازد. در یک کتابخانه آموزشی، «طراحی» دسته اصلی است و «Figma»، «Auto Layout» و «Design Tokens» موضوع‌های دقیق‌ترند. اگر برای هر جمله یک Tag بسازید، به‌تدریج فهرستی خواهید داشت که نگهداری آن از خواندن محتوا سخت‌تر است.
برای نام‌گذاری، شکل نوشتن فارسی و انگلیسی را از ابتدا مشخص کنید. نیم‌فاصله، فاصله‌های اضافی، بزرگی حروف لاتین و نام‌های مترادف می‌توانند ورودی‌های ظاهراً متفاوت بسازند. اصطلاح رایج را حفظ کنید؛ تبدیل Design Tokens به یک عبارت نامأنوس فارسی کمکی به پیدا کردن مطلب نمی‌کند. در مقابل، برچسب‌های عمومی مانند «شروع کار» بهتر است با زبان خود مخاطب نوشته شوند.
هر برچسب یک رفتار قابل پیش‌بینی داشته باشد
Tag اطلاعاتی فقط توضیح می‌دهد. برای آن Hover شبیه دکمه، نشانگر دست یا حالت فشرده‌شدن نسازید، چون وعده تعامل می‌دهد. Tag انتخابی باید تفاوت حالت انتخاب‌شده و عادی را نشان دهد. Tag حذف‌شدنی باید کنترل حذف روشن داشته باشد. اگر عنصر به صفحه دیگری می‌رود، آن را به‌عنوان لینک موضوع طراحی و پیاده‌سازی کنید؛ این تصمیم را با فیلترکردن همین صفحه مخلوط نکنید.
این پیشنهاد یک الگوی عمومی محصول است، نه دستور مشترک همه کتابخانه‌ها. Carbon مشخصاً توصیه می‌کند Tagهایش برای هدایت کاربر به یک تجربه کاملاً جدا استفاده نشوند. اگر از آن کتابخانه استفاده می‌کنید، محدودیت همان کامپوننت را رعایت کنید و برای ناوبری سراغ الگوی مناسب بروید. کپی ظاهر یک کامپوننت بدون قرارداد رفتاری آن، بخش مهم طراحی را حذف می‌کند.
به‌خصوص علامت ضربدر را با دقت به کار ببرید. ضربدر کنار «طراحی» در نوار فیلتر باید انتخاب آن فیلتر را بردارد، نه مقاله را حذف کند. در پنل مدیریت، حذف یک Tag از یک مقاله با حذف خود Tag از کل سیستم فرق دارد. نام کنترل و پیام مربوط به آن باید این تفاوت را بگوید. برای عملی که فقط فیلتر را پاک می‌کند، پیام ترسناک حذف دائمی نمایش ندهید.
منطق ترکیب فیلترها را توضیح دهید
فرض کنید کاربر «طراحی» و «برنامه‌نویسی» را انتخاب کرده است. آیا محتوایی می‌بیند که هر دو Tag را دارد، یا مطلبی که دست‌کم یکی از آن‌ها را دارد؟ این همان تفاوت AND و OR است. تیم ممکن است جواب را بدیهی بداند، ولی کاربر از دو کپسول رنگی نمی‌تواند منطق جست‌وجو را حدس بزند. متن کوتاهی مثل «شامل یکی از موضوع‌های انتخاب‌شده» می‌تواند ابهام را کم کند.
در فیلترهای چندگروهی، رفتار را جداگانه تعریف کنید. برای مثال، انتخاب دو موضوع می‌تواند OR باشد، اما ترکیب موضوع با نوع محتوا AND باشد: مقاله‌های مربوط به یکی از موضوع‌ها که نوعشان «راهنما» است. این فقط یک انتخاب طراحی است و باید با نیاز واقعی محصول هماهنگ شود. نمایش تعداد نتایج، فیلترهای فعال و گزینه «پاک کردن فیلترها» به کاربر امکان می‌دهد اثر انتخابش را دنبال کند.
حالت بدون نتیجه را هم بنویسید. جمله «چیزی پیدا نشد» به‌تنهایی مسیر بعدی نمی‌دهد. می‌توان گفت «با این ترکیب موضوع و نوع محتوا نتیجه‌ای پیدا نشد» و امکان حذف یکی از فیلترها را همان‌جا گذاشت. اگر جست‌وجوی متنی نیز فعال است، آن را کنار انتخاب‌ها مشخص کنید تا کاربر بداند کدام عامل نتایج را محدود کرده است.
تعداد Tagها را با نیاز صفحه تعیین کنید
قاعده ثابت «حداکثر پنج یا هفت Tag» برای همه آیتم‌ها قابل دفاع نیست. کارت کوچک، صفحه جزئیات و پنل مدیریت نیازهای متفاوت دارند. روی کارت، موضوع‌هایی را نشان دهید که بیشترین کمک را به انتخاب محتوا می‌کنند. در صفحه جزئیات، می‌توان فهرست کامل‌تری داشت. در پنل مدیریت هم ممکن است کاربر برای ویرایش به همه ارتباط‌ها نیاز داشته باشد.
وقتی فضای کارت کم است، گزینه «نمایش بیشتر» باید رفتار مشخصی داشته باشد: فهرست را باز می‌کند، پنجره‌ای نمایش می‌دهد یا به جزئیات می‌رود؟ اگر تعداد برچسب‌های پنهان را نشان می‌دهید، آن عدد باید از داده واقعی بیاید. ترتیب نمایش هم بهتر است پایدار باشد؛ مثلاً موضوع اصلی قبل از ابزارها و ابزارها قبل از سطح مهارت، تا کارت‌ها هر بار ترکیب نامنظمی نداشته باشند.
برای متن بلند، ابتدا نام را بازبینی کنید. اگر کوتاه‌کردن معنا را تغییر می‌دهد، فضای بیشتری بدهید یا راه دسترسی به نام کامل فراهم کنید. گروه Tagها می‌تواند به خط بعد برود؛ این با چندخطی‌کردن متن داخل تک‌تک کپسول‌ها فرق دارد. در برخی کتابخانه‌ها مانند Carbon، متن هر Tag تک‌خطی است. نمایش نام کامل را فقط به Hover وابسته نکنید، چون روی صفحه لمسی چنین تجربه‌ای قابل اتکا نیست.
رنگ باید به معنا کمک کند، نه جای آن را بگیرد
اگر هر موضوع را با رنگ متفاوت نشان دهید، در یک فهرست بزرگ ممکن است صفحه شبیه جدول رنگ شود. قبل از افزودن رنگ، بپرسید کاربر باید چه تفاوتی را سریع ببیند. وضعیت «خطا» به تفکیک روشن نیاز دارد، اما نام ده ابزار طراحی الزاماً ده رنگ مستقل نمی‌خواهد. رنگ‌های خنثی برای موضوع‌ها و رنگ‌های معنایی برای وضعیت‌ها معمولاً نقطه شروع قابل بررسی‌اند.
طبق معیار Use of Color در WCAG، رنگ نباید تنها راه انتقال اطلاعات باشد. برای حالت انتخاب‌شده، کنار تغییر رنگ از نشانه انتخاب، متن یا تفاوت قابل تشخیص دیگری استفاده کنید. وضعیت «منتشرشده» را هم با خود این کلمه نشان دهید؛ یک نقطه سبز به‌تنهایی برای همه کاربران معنی مشترکی ندارد.
در نسخه روشن و تیره، خوانایی متن، مرز کنترل و Focus را جداگانه بررسی کنید. کم‌کردن شفافیت کل کامپوننت می‌تواند متن را بی‌خوانا کند. بهتر است رنگ متن، پس‌زمینه، Border و حالت انتخاب‌شده را با Design Tokens مشترک تعریف کنید تا تغییر Theme یا اصلاح کنتراست به ویرایش دستی همه صفحه‌ها وابسته نباشد.
کیبورد، لمس و صفحه فارسی را از ابتدا در نظر بگیرید
عنصر اطلاعاتی لازم نیست یک توقف اضافی در مسیر Tab بسازد. عنصر تعاملی باید با کیبورد قابل استفاده باشد و Focus واضح داشته باشد. برای رفتن به صفحه از لینک و برای انجام عمل از کنترل مناسب همان عمل استفاده کنید. گذاشتن رویداد کلیک روی یک عنصر معمولی، بدون رفتار کیبورد و نام قابل فهم، تجربه کامل نمی‌سازد.
کنترل حذف باید نامی مثل «حذف فیلتر طراحی» داشته باشد، نه صرفاً «ضربدر». پس از حذف نیز Focus نباید بی‌دلیل گم شود؛ مقصد بعدی را بر اساس ترتیب کنترل‌های باقی‌مانده مشخص کنید. اگر فیلترها دکمه‌های Toggle هستند، وضعیت فعال را برای فناوری کمکی هم اعلام کنید. انتخاب الگوی ARIA باید با نوع کنترل هماهنگ باشد؛ همه Chipها نقش یکسانی ندارند.
برای لمس، اندازه ناحیه فعال و فاصله کنترل‌ها مهم‌تر از اندازه خود آیکون است. معیار Target Size در WCAG 2.2 حداقل ۲۴ در ۲۴ CSS pixel را با استثناهایی از جمله شرایط فاصله‌گذاری مطرح می‌کند. این عدد را با ابعاد ظاهری هر Tag یکی ندانید. مخصوصاً دکمه حذف کوچک کنار چند فیلتر، نباید با یک لمس معمولی انتخاب اشتباه ایجاد کند.
در رابط فارسی، ترتیب متن، آیکون و کنترل حذف را با محتوای واقعی ببینید. نامی مثل CSS Grid نباید با به‌هم‌ریختگی حروف لاتین خوانده شود. گروه‌ها باید در عرض کم هم ترتیب منطقی داشته باشند. اگر هنوز تصمیم‌های صفحه کوچک مشخص نیست، راهنمای طراحی Mobile First کمک می‌کند فضای محدود را از ابتدا وارد تصمیم کنید، نه اینکه در پایان فقط اندازه‌ها را کوچک کنید.
سیستم را در Figma و توسعه با یک قرارداد تحویل دهید
برای کامپوننت، گونه‌های واقعاً مورد نیاز را بسازید: اطلاعاتی، انتخابی، حذف‌شدنی و وضعیت، اگر محصول هر چهار مورد را دارد. حالت عادی، Focus، انتخاب‌شده و غیرفعال را برای گونه مربوط تعریف کنید. آیکون تزئینی را از آیکون عملیاتی جدا نگه دارید. در کنار ظاهر، یک جمله درباره نتیجه تعامل بنویسید؛ مثلاً «انتخاب این کنترل، موضوع را به فیلترهای همین صفحه اضافه می‌کند».
در Figma با متن کوتاه، بلند و ترکیبی فارسی و انگلیسی نمونه بسازید. Auto Layout و اندازه مبتنی بر محتوا به حفظ فاصله‌ها کمک می‌کنند، اما تصمیم درباره پنهان‌شدن، شکست گروه به خط بعد و رفتار نمایش بیشتر همچنان با شماست. برای مرتب‌کردن این بخش می‌توانید از ترفندهای کاربردی Figma استفاده کنید. صرفاً یک ردیف زیبا با سه نام کوتاه، وضعیت واقعی محصول را نمایندگی نمی‌کند.
در تحویل نهایی، چند سؤال روشن کافی است: نام‌ها یکتا و قابل جست‌وجو هستند؟ کاربر اطلاعات را از عمل تشخیص می‌دهد؟ ترکیب فیلترها معلوم است؟ حذف فقط همان چیزی را حذف می‌کند که نام کنترل می‌گوید؟ نام بلند و صفحه کوچک قابل استفاده‌اند؟ پاسخ این سؤال‌ها ارزش بیشتری از زیادکردن رنگ‌ها و Variantها دارد. یک سیستم برچسب خوب، به محتوا نظم می‌دهد و تصمیم بعدی کاربر را روشن می‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!