Design Tokens: چگونه سیستمهای طراحی واقعی یکپارچگی خود را حفظ میکنند
توکنهای طراحی چیستند، مدل سهلایهای که سیستمهای واقعی استفاده میکنند (Shopify Polaris، IBM Carbon، GitHub Primer)، چگونه آنها را نامگذاری کنیم، تمبندی برای حالت تاریک، و زمانی که توکنها بیش از حد پیچیدهاند.
Design Tokens: چگونه سیستمهای طراحی واقعی یکپارچگی خود را حفظ میکنند
یک کد hex یک مقدار است. یک توکن یک تصمیم با نام است. سیستمهای طراحی از تصمیمات ساخته میشوند، نه مقادیر.
این تفاوت، اصل ماجراست. #0EA5E9 را در چهارده کامپوننت Figma هاردکد کنید، درخواست حالت تاریک را دریافت کنید، و با یک هفته جستجو و جایگزینی روبرو خواهید شد. آن را color-interactive-primary بنامید و با تغییر یک مقدار، همه سطوح بهروزرسانی میشوند. این جادو نیست، فقط تصمیمات نامگذاریشده است.
یک توکن طراحی واقعاً چیست
یک توکن طراحی یک متغیر نامگذاریشده است که یک تصمیم طراحی را ذخیره میکند. میتواند یک رنگ، یک مقدار فاصله، یک اندازه فونت، یک شعاع حاشیه، یک سایه، یا یک مدت زمان نگهداری کند. نام، قرارداد است. مقدار پشت نام میتواند تغییر کند بدون اینکه چیزی که از توکن استفاده میکند خراب شود.
رویکرد کلاسیک بدون توکن زمانی شروع میشود که یک طراح #1D4ED8 را برای دکمههای اصلی انتخاب میکند، آن را در کامپوننت دکمه هاردکد میکند، سپس آن hex را در کارت، بج و لینک کپی میکند. شش ماه بعد، برند بهروز میشود. اکنون یک مشکل نگهداری دارید که با هر کامپوننتی که ارسال کردهاید مقیاس میگیرد.
توکنها این را برعکس میکنند. تصمیم را نام میگذارید (color-action-default)، یکبار مقدار را تخصیص میدهید، و همه چیزی که به توکن اشاره میکند هماهنگ میماند. مقدار، جزئیات پیادهسازی است. نام، سیستم است.
سه لایهای که توکنها را کارآمد میکند
توکنهای خام فقط متغیر هستند. آنچه یک سیستم توکن را واقعاً مفید میکند، سلسلهمراتب است. هر سیستم تولیدی ارزش مطالعه از سه لایه استفاده میکند.
| لایه | نام دیگر | آنچه ذخیره میکند | مثال |
|---|---|---|---|
| اولیه | Global، Base | مقادیر خام، بدون معنا | color.blue.500 = #3B82F6 |
| معنایی | Alias، Role | نقشهای نامگذاریشده نگاشتشده به اولیهها | color.interactive.default = color.blue.500 |
| کامپوننت | Specific | تصمیمات محدودهبندیشده کامپوننت | button.background.default = color.interactive.default |
اولیهها پالت شما هستند. هر آبی، هر گام فاصله، و هر شعاع در اینجا به عنوان یک مقدار نامگذاریشده بدون نظر درباره محل استفاده وجود دارد. شما اولیهها را مستقیماً در کامپوننتها مصرف نمیکنید.
توکنهای معنایی نقشها را به اولیهها نگاشت میکنند. توکن color-surface-default ممکن است در حالت روشن به نزدیکسفید و در حالت تاریک به نزدیکسیاه اشاره کند، و کامپوننت هرگز نمیداند کدام مقدار خام دریافت میکند. فقط نقش را میداند.
توکنهای کامپوننت مشخصترین هستند. زمانی وجود دارند که یک کامپوننت به تصمیمی نیاز دارد که عمداً با پیشفرض معنایی متفاوت است. یک دکمه خطرناک پسزمینه خود را به یک نقش بازخورد بحرانی به جای نقش تعاملی پیشفرض اشاره میدهد. اکثر کامپوننتها به توکنهای خود نیاز ندارند؛ آنها مستقیماً توکنهای معنایی را مصرف میکنند.
چرا توکنها از مقادیر هاردکد بهترند
سرعت تغییر استدلال آشکار است، اما دلیل واقعی نیست. دلیل واقعی دقت است.
وقتی یک طراح فایلی پر از کدهای hex خام تحویل میدهد، توسعهدهنده نمیداند کدامها عمدی و کدامها تصادفی هستند. آیا #1A1A2E پسزمینه است، یا کسی لایه اشتباهی را eyedrop کرده؟ توکنها ابهام را از بین میبرند. یک نام توکن معنایی مستنداتی است که با مقدار همراه میشود.
توکنها همچنین قرارداد handoff بین ابزارهای طراحی و کد در سال ۲۰۲۶ هستند. متغیرهای Figma مستقیماً به CSS custom properties نگاشت میشوند. یک توکن تعریفشده در فایل Figma میتواند بدون یک مرحله دستی export، commit و در کد مصرف شود. شکاف بین طراحی و پیادهسازی زمانی فرو میریزد که هر دو طرف با نامهای توکن یکسان صحبت میکنند.
برای تیمهایی که کارهای دسترسیپذیری انجام میدهند، توکنها یک لایه ایمنی اضافه میکنند. پالت معنایی را در یک مکان بازرسی میکنید و تضمین میکنید که color-text-default همیشه کنتراست 4.5:1 را در برابر color-surface-default برآورده میکند، صرفنظر از اینکه کدام تم فعال است.
چگونه سیستمهای طراحی واقعی توکنهای خود را ساختاردهی میکنند
سه سیستم ارزش دانستن دارند: Shopify Polaris، IBM Carbon، و GitHub Primer. آنها مدل سهلایه را به شکلهای مختلف مدیریت میکنند، و تفاوتها آموزنده هستند.
Shopify Polaris اولیهها را در یک مقیاس رنگ نگه میدارد (color-sky-100 تا color-sky-900) و آنها را به نقشهای معنایی مانند --p-color-bg-fill-active نگاشت میکند. توکنهای کامپوننت پراکنده هستند، بنابراین اکثر کامپوننتها توکنهای معنایی را مصرف میکنند. قرارداد نقش-سپس-حالت است که در کد بهطور طبیعی خوانده میشود، چون میدانید bg-fill-disabled برای چه چیزی است بدون زمینه اضافه.
IBM Carbon در لایههای معنایی عمیق میشود. مجموعه رنگ آن شامل توکنهای بازخورد صریح مانند support-error و support-success، توکنهای حالت تعاملی، و توکنهای لایه برای سطوح تو در تو است (یک کامپوننت روی یک پانل روی یک صفحه هر کدام به یک مقدار سطح متفاوت نیاز دارند). پیچیدهتر است، اما IBM نرمافزار سازمانی ارسال میکند که هر حالت تودرتو اهمیت دارد.
مشاهده در carbondesignsystem.com
GitHub Primer لایه اولیه خود را به عنوان "primitives" و لایه معنایی خود را به عنوان "functional tokens" در primer.style به صورت عمومی مستند میکند. تمبندی Primer به GitHub اجازه میدهد حالت روشن، تاریک، روشن با کنتراست بالا، و تاریک کمرنگ را از یک مجموعه کامپوننت ارسال کند. هر تم یک تخصیص مقدار متفاوت به همان نامهای توکن است.
الگو در هر سه ثابت است: اولیهها به عنوان یک مقیاس، توکنهای معنایی به عنوان نامهای نقش، و تمبندی به عنوان تعویض مقدار در لایه معنایی. کامپوننتها بدون تغییر باقی میمانند.
Brainy به طراحان کمک میکند سیستمهایی بسازند که مقیاس میگیرند، نه صفحات یکباره. ببینید ما برای سازندگان چه میسازیم در /creators.
نامگذاری توکنها بدون از دست دادن عقل
نامگذاری توکن تیمها را از هم جدا میکند. خیلی کلی و نامها اطلاعاتی حمل نمیکنند. خیلی خاص و برای هر کامپوننت یک توکن جدید مینویسید.
یک قرارداد نامگذاری که کار میکند چهار بخش را نامگذاری میکند: دستهبندی، نقش، نوع و حالت. همیشه از همه چهار بخش استفاده نخواهید کرد، اما ساختار از آشفتگی تصادفی جلوگیری میکند.
| بخش | آنچه ضبط میکند | مثالها |
|---|---|---|
| دستهبندی | خاصیت طراحی | color، spacing، radius، shadow، font |
| نقش | هدف معنایی | surface، text، border، interactive، feedback |
| نوع | زیرنقش یا اصلاحکننده | primary، secondary، danger، subtle |
| حالت | شرایط تعاملی | default، hover، active، disabled، focus |
مثالهای عملی، نوشتهشده به عنوان CSS custom properties که یک توسعهدهنده واقعاً مصرف میکند:
color-surface-defaultپسزمینه پیشفرض صفحه را تعیین میکندcolor-text-subtleمتن ثانویه با کنتراست پایینتر استcolor-interactive-primary-hoverحالت hover یک عمل اصلی استspacing-component-mdpadding داخلی متوسط برای کامپوننتها استradius-interactiveشعاع گوشه برای عناصر قابل کلیک است
دو قانون بیشترین بحث را نجات میدهند. هرگز مقدار خام را در نام کدگذاری نکنید، چون color-blue-500 چیزی درباره نقش نمیگوید. هرگز در لایه معنایی با نام کامپوننت نامگذاری نکنید، چون button-primary-color در لایه معنایی یعنی لایه معنایی را کاملاً نادیده گرفتهاید.
برای سیستمهای تایپوگرافی که مقیاس میگیرند، همان قرارداد اعمال میشود، و font-size-body-lg همیشه بر text-18px برتری دارد.
یک مجموعه توکن، حالت روشن و تاریک
حالت تاریک جایی است که سیستمهای توکن بیشترین بازدهی مرئی را دارند. اگر توکنهای خود را با نقش نامگذاری کردید، حالت تاریک یک تعویض مقدار است، نه یک طراحی مجدد.
مکانیزم ساده است. توکن معنایی شما color-surface-default به یک اولیه اشاره میکند که در حالت روشن نزدیکسفید و در حالت تاریک نزدیکسیاه است. کامپوننتی که آن را مصرف میکند هرگز تغییر نمیکند. با تعویض نگاشت مقدار در لایه معنایی، تم را تغییر میدهید.
CSS custom properties این را مکانیکی میکند:
:root {
--color-surface-default: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-surface-default: #0f172a;
--color-text-primary: #f8fafc;
}
هر کامپوننتی که به var(--color-surface-default) اشاره میکند اکنون با صفر کد اضافی به attribute تم پاسخ میدهد. Shopify Polaris، GitHub Primer، و IBM Carbon همگی از این الگو در مقیاس تولید استفاده میکنند.
حالت شکست مخلوط کردن توکنهای معنایی و اولیه در کامپوننتها است. وقتی یک کامپوننت مستقیماً به color-blue-600 به جای color-interactive-primary اشاره میکند، آن کامپوننت دیگر به تمبندی پاسخ نمیدهد. یک اشاره اولیه بیدقتانه کل مدل را خراب میکند. قوانین lint که مصرف مستقیم اولیه در کد کامپوننت را علامتگذاری میکنند ارزش زمان راهاندازی را دارند.
درک چگونگی انتقال انتخابهای رنگ پایه مفهومی را به شما میدهد، و توکنها ساختار عمل بر اساس آن را در هر تم فراهم میکنند.
زمانی که توکنهای طراحی بیش از حد پیچیدهاند
توکنها غیرمستقیم بودن اضافه میکنند. غیرمستقیم بودن هزینه دارد. درباره زمانی که این هزینهها ارزش پرداخت دارند صادق باشید.
| وضعیت | توکن؟ | دلیل |
|---|---|---|
| سیستم طراحی خدمتدهنده به ۳+ محصول | بله | توکنهای مشترک فوراً هزینه خود را جبران میکنند |
| محصول واحد، ۵+ طراح | بله | از انحراف پالت در سراسر تیم جلوگیری میکند |
| محصول واحد، ۱-۲ طراح، تکرار فعال | شاید | فقط لایه معنایی، توکنهای کامپوننت را نادیده بگیرید |
| سایت بازاریابی، بدون کتابخانه کامپوننت | خیر | یک stylesheet سریعتر قابل تغییر است |
| پروتوتایپ یا MVP زیر ۳ ماه | خیر | پس از تثبیت طراحی انتزاع کنید |
| افزودن حالت تاریک به سیستم موجود | بله | این دقیقاً همان چیزی است که توکنها برایش هستند |
تیمهای کوچک بدون توکن سریعتر حرکت میکنند. یک استارتاپ سهنفره که به دنبال تناسب محصول-بازار است به یک سلسلهمراتب سهلایه نیاز ندارد. وقتی هر دو هفته جهت بصری تغییر میکنید، یک کتابخانه استایل Figma کافی است.
الگوی ضد که باید از آن اجتناب کرد نامگذاری معنایی زودهنگام است. توکنهایی که color-blue و color-gray نامگذاری میشوند غیرمستقیم بودن را بدون معنا اضافه میکنند. یا با color-surface و color-text با نقش نامگذاری کنید، یا به اولیهها پایبند باشید تا کامپوننتهای کافی داشته باشید تا بدانید نقشها واقعاً چه هستند.
نامگذاری بد توکن بدتر از نداشتن توکن است. یک توکن به نام button-color-for-the-checkout-page در لایه معنایی یک تله نگهداری است. نظم نامگذاری اختیاری نیست، دلیل کارکردن توکنهاست.
سوالات متداول
آیا توکنهای طراحی جایگزین استایلهای Figma میشوند؟
خیر، اما آنها را گسترش میدهند. متغیرهای Figma که در سال ۲۰۲۳ منتشر شدند، نزدیکترین معادل بومی داخل Figma هستند و زمانی که قراردادهای نامگذاری را در هر دو طرف به اشتراک میگذارید به توکنهای کد نگاشت میشوند. استایلهای Figma تایپوگرافی و پر رنگ را مدیریت میکنند، در حالی که متغیرها سلسلهمراتب کامل توکن شامل حالتها و تصمیمات سطح کامپوننت را مدیریت میکنند.
آیا توکنها بدون سیستم طراحی کار میکنند؟
توکنها بیشترین ارزش را در داخل یک سیستم طراحی دارند، اما حتی یک محصول واحد از نامگذاری معنایی در سطح CSS custom property بهرهمند میشود. برای توقف هاردکدینگ مقادیر hex نیازی به یک سیستم رسمی ندارید.
از چه ابزاری برای مدیریت توکنها استفاده کنم؟
برای تیمهای کوچک، متغیرهای Figma به اضافه یک export از نوع JSON کافی است. برای تیمهای بزرگتر، Style Dictionary (متنباز، توسط Amazon) ابزار build استاندارد است. یک ساختار JSON توکن میگیرد و CSS custom properties، ثابتهای iOS Swift، و XML اندروید را خروجی میدهد. Tokens Studio برای Figma پلاگین پل محبوب بین Figma و Style Dictionary است.
توکنهای کامپوننت تا چه حد باید دقیق باشند؟
فقط به اندازهای که نیاز دارید. اکثر کامپوننتها میتوانند توکنهای معنایی را مستقیماً مصرف کنند. توکنهای خاص کامپوننت زمانی منطقی هستند که یک کامپوننت عمداً از لایه معنایی منحرف میشود، مانند یک دکمه عمل مخرب یا یک بنر با سطح غیرمعمول. در صورت تردید، معنایی مصرف کنید و توکنهای کامپوننت را فقط زمانی ایجاد کنید که خود را در حال نوشتن استثنا مییابید.
آیا توکنها میتوانند فاصلهگذاری و تایپوگرافی را هم مدیریت کنند، یا فقط رنگ؟
توکنها برای هر چیزی با یک مقدار گسسته کار میکنند: رنگ، فاصلهگذاری، تایپوگرافی، شعاع حاشیه، box shadow، مدت زمان حرکت، easing حرکت، و z-index. پختهترین سیستمها مانند IBM Carbon و Atlassian Design System برای همه اینها توکن دارند. با رنگ و فاصلهگذاری شروع کنید، سپس با بلوغ سیستم موارد دیگر را اضافه کنید.
توقف هاردکدینگ مقادیر
مسیر عملی پیچیده نیست:
- اولیههای خود را به عنوان یک مقیاس نامگذاری کنید
- آن اولیهها را به نقشهای معنایی نگاشت کنید
- هر کامپوننت توکنهای معنایی را مصرف کند، نه اولیهها را
- مقادیر توکن را از یک منبع (متغیرهای Figma، یک فایل JSON، یا یک پکیج سیستم طراحی) export کنید و به ابزارهای build اجازه دهید آنها را به CSS، iOS، و Android توزیع کنند
نیازی به یک مهاجرت سهماهه برای شروع ندارید. یک کامپوننت را انتخاب کنید، تصمیماتش را نامگذاری کنید، و تفاوت را احساس کنید وقتی یک مقدار را یکبار تغییر میدهید و همه چیز بهروزرسانی میشود. آن تجربه، استدلال است.
برای نوشتارهای بیشتر درباره سیستمهای طراحی، ببینید Brainy در /paper چه موضوعات دیگری پوشش میدهد.
Brainy helps designers build systems that scale, not one-off screens. See what we are building for creators.
Get Started
