طراح رنگ دکمه اصلی را عوض می‌کند، توسعه‌دهنده همان تغییر را در یک صفحه اعمال می‌کند و چند صفحه دیگر با رنگ قبلی باقی می‌مانند. وقتی رنگ، فاصله و اندازه‌ها به صورت مقدارهای پراکنده نگهداری شوند، هماهنگ‌کردن محصول به حافظه افراد وابسته می‌شود. Design Tokens به این تصمیم‌ها نام می‌دهند تا طراحی و کد بتوانند درباره یک مفهوم مشخص صحبت کنند.
یک Token می‌تواند رنگ متن اصلی، فاصله میان دو بخش یا شعاع گوشه دکمه را توصیف کند. ارزش آن فقط ذخیره یک عدد نیست؛ نام، نقش، نوع و مسیر تغییر هم اهمیت دارند. این مقاله با مثال یک رابط وب توضیح می‌دهد چگونه Tokenها را لایه‌بندی کنید، به CSS برسانید و بدون ساختن صدها متغیر بی‌مصرف وارد کار روزمره تیم کنید.
Design Token با مقدار خام و CSS Variable چه تفاوتی دارد؟
مقدار خام مثل یک کد رنگ، به‌تنهایی درباره کاربردش چیزی نمی‌گوید. نامی مانند color.text.primary نشان می‌دهد آن مقدار برای چه نقشی انتخاب شده است. CSS Custom Property یکی از روش‌های مصرف این تصمیم در وب است. خود Token می‌تواند پیش از تولید CSS، در فایل داده یا ابزار طراحی نگهداری شود و برای خروجی‌های دیگر هم استفاده شود.
اگر متغیری به نام --blue بسازید ولی تیم نداند کجا مجاز به استفاده از آن است، هنوز مسئله هماهنگی حل نشده است. در مقابل، توضیح «رنگ متن اصلی روی سطح پیش‌فرض» تصمیم قابل بررسی ایجاد می‌کند. مستندات CSS Custom Properties در MDN رفتار متغیرها، Scope و استفاده از var() را توضیح می‌دهد. این رفتار مرورگر را با قواعد نام‌گذاری Design System یکی نگیرید.
سه لایه پیشنهادی: Primitive، Semantic و Component
Primitive Token مقدار پایه را نگه می‌دارد؛ مثلاً یک پله از طیف آبی یا واحد فاصله. Semantic Token نقش آن را در رابط بیان می‌کند؛ مانند رنگ متن، سطح صفحه یا عمل اصلی. Component Token تصمیم محدود به یک کامپوننت است؛ مثلاً پس‌زمینه دکمه اصلی در حالت عادی. این سه لایه یک الگوی معماری پیشنهادی‌اند و الزام تمام پروژه‌ها یا تمام ابزارها نیستند.
برای پروژه کوچک، مقدار پایه و نقش معنایی اغلب نقطه شروع کافی‌اند. اگر برای هر ویژگی هر کامپوننت یک Token جدا بسازید، تغییر ساده به عبور از چند لایه تبدیل می‌شود. لایه Component زمانی دلیل روشن دارد که رفتار مستقل، تفاوت برند یا استثنای مشخصی را مدیریت کند. پیش از اضافه‌کردن آن بپرسید: اگر این نام را حذف کنیم، کدام تصمیم طراحی مبهم می‌شود؟
پیکان‌های تصویر مسیر استفاده از تصمیم‌ها را نشان می‌دهند، نه رتبه‌بندی کیفیت. مقدار پایه به نقش معنایی وصل می‌شود و کامپوننت از همان نقش استفاده می‌کند. نام‌ها ممکن است در ابزار شما ساختار متفاوتی داشته باشند؛ مهم این است که وابستگی‌ها روشن باشند و تغییر یک مقدار به شکل تصادفی معنی دیگری را عوض نکند.
با یک مثال کوچک، مسیر مقدار تا مصرف را ببینید
فرض کنید برای یک سایت نمونه، رنگ آبی پایه، فاصله کوچک و سطح روشن را انتخاب کرده‌ایم. کد زیر مثال آموزشی است و هیچ استاندارد نام‌گذاری اجباری را تحمیل نمی‌کند. مقدارهای نمونه هم به معنی تأیید دسترس‌پذیری تمام ترکیب‌های رنگی نیستند؛ نتیجه باید در رابط واقعی بررسی شود.
:root {
--color-blue-700: #1d4ed8;
--color-white: #ffffff;
--space-2: 0.5rem;
--space-4: 1rem;
--color-action-primary: var(--color-blue-700);
--color-on-action-primary: var(--color-white);
--button-primary-background: var(--color-action-primary);
}
.button-primary {
background: var(--button-primary-background);
color: var(--color-on-action-primary);
padding-block: var(--space-2);
padding-inline: var(--space-4);
}کامپوننت از نام نقش استفاده می‌کند و لازم نیست بداند رنگ از کدام پله طیف آمده است. اگر نقش عمل اصلی تغییر کند، ابتدا وابستگی آن را تغییر می‌دهید و سپس همه مصرف‌کننده‌ها را بررسی می‌کنید. استفاده از padding-inline و padding-block هم برای این مثال مناسب است چون جهت صفحه را به نام چپ و راست گره نمی‌زند؛ Token فاصله به خودی خود مسئول جهت‌چینی نیست.
برای پیاده‌سازی تازه، همین الگو را روی یک دکمه و یک کارت امتحان کنید. فهرست همه رنگ‌های پروژه را فوراً به Token تبدیل نکنید. ابتدا مشخص کنید کدام مقدار مشترک است، کدام تصمیم فقط در یک بخش معنا دارد و کدام تفاوت ناشی از ناسازگاری قدیمی است. تبدیل ناسازگاری به نام رسمی، آن را به تصمیم درست تبدیل نمی‌کند.
فرمت DTCG چه مسئله‌ای را حل می‌کند؟
Design Tokens Community Group فرمت تبادل Token را برای ارتباط ابزارها تعریف کرده است. در Format Module نسخه 2025.10، ویژگی‌هایی مانند $type و $value و ارجاع میان Tokenها توضیح داده شده‌اند. این سند گزارش گروه جامعه است و نباید آن را W3C Recommendation معرفی کرد. وجود فرمت مشترک هم به معنی پشتیبانی کامل همه ابزارها از همه ویژگی‌های آن نیست.
نمونه زیر یک مقدار فاصله و یک ارجاع آموزشی به آن را نشان می‌دهد. نام‌گذاری و مقدارها برای توضیح ساخته شده‌اند. ابزار تبدیل شما باید نوع Dimension و شیوه Resolve کردن Alias را پشتیبانی کند تا خروجی مورد انتظار تولید شود.
{
"space": {
"small": {
"$type": "dimension",
"$value": { "value": 8, "unit": "px" }
}
},
"card": {
"gap": {
"$type": "dimension",
"$value": "{space.small}"
}
}
}اگر یک ابزار JSON اختصاصی تولید کند، صرف داشتن فایل JSON کافی نیست که آن را سازگار با DTCG بدانیم. هنگام انتخاب مسیر تبادل، یک نمونه کوچک شامل مقدار ساده و Alias را وارد و خارج کنید و رفتار مورد نیاز را مشخص کنید. درباره رنگ‌های جدید، تایپوگرافی مرکب و سایر نوع‌ها، مستندات نسخه ابزار را بخوانید؛ نباید فرض کرد همه این داده‌ها مثل یک رشته ساده تبدیل می‌شوند.
Theme را با نقش معنایی مدیریت کنید
در Theme روشن و تیره، نقش‌هایی مثل متن اصلی و سطح صفحه ثابت می‌مانند ولی مقدارشان تغییر می‌کند. اگر نام Token را بر اساس ظاهر امروز انتخاب کرده باشید، فردا نامی مثل text.black در Theme تیره به یک رنگ روشن اشاره می‌کند و خواننده کد را گیج می‌کند. نامی مانند text.primary وابستگی به نقش را روشن‌تر نگه می‌دارد.
در نمونه وب می‌توانید مقدارهای معنایی را در Scope یک Attribute تغییر دهید. این تصمیم درباره معماری پروژه است، نه بخشی از تعریف عمومی Token. روش انتخاب Theme، ترجیح کاربر و تنظیمات سیستم باید جدا مدیریت شود. ماژول Resolver در DTCG هم مسئله Resolve کردن مجموعه‌ها و زمینه‌های مختلف را توضیح می‌دهد؛ پشتیبانی ابزار از آن را جدا از پشتیبانی Format Module بررسی کنید.
:root {
--color-surface: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-surface: #111827;
--color-text-primary: #f9fafb;
}
.card {
background: var(--color-surface);
color: var(--color-text-primary);
}اضافه‌کردن Theme با معکوس‌کردن همه رنگ‌ها تمام نمی‌شود. حالت Hover، Focus، Disabled، خطا و رنگ‌های روی تصویر نیاز به تصمیم جدا دارند. Tokenها فهرست این تصمیم‌ها را قابل مشاهده می‌کنند، اما درباره درست‌بودن آن‌ها قضاوت خودکار نمی‌کنند. همین تفاوت برای چند برند هم وجود دارد: مقدارهای مشترک و استثناهای برند باید مشخص باشند.
منبع تغییر و مالکیت را روشن کنید
تیم باید بداند تصمیم معتبر کجا ثبت می‌شود: فایل نسخه‌بندی‌شده، ابزار طراحی یا یک مسیر هماهنگ میان این دو. اگر هر دو طرف مستقلاً مقدارها را عوض کنند، دو منبع متفاوت خواهید داشت. برای هر تغییر مشخص کنید چه کسی پیشنهاد می‌دهد، چه کسی اثر آن را بررسی می‌کند و چه زمانی طراحی و کد به نسخه تازه می‌رسند. یک جدول مالکیت ساده از اتصال پیچیده بدون مسئول بهتر است.
برای تغییر رنگ عمل اصلی، پیشنهاد را با نمونه صفحه و فهرست مصرف‌کننده‌ها مطرح کنید. طراح وضعیت‌های بصری را بررسی کند و توسعه‌دهنده وابستگی‌ها و خروجی تولیدشده را ببیند. اگر مقدار جدید در یک بخش خاص مناسب نیست، علت استثنا را بنویسید. این یادداشت کمک می‌کند همکار بعدی تصمیم را با اشتباه پیاده‌سازی یکی نگیرد.
ابزار تبدیل را بر اساس مسیر واقعی انتخاب کنید
Style Dictionary داده Token را می‌گیرد و با تنظیم Transform و Format به خروجی مناسب پلتفرم تبدیل می‌کند. خروجی تولیدشده را دستی اصلاح نکنید؛ تغییر باید در منبع یا تنظیم تبدیل انجام شود، وگرنه اجرای بعدی اصلاح شما را پاک می‌کند. انتخاب ابزار را به خروجی مورد نیاز، ساختار داده و نحوه انتشار وابسته کنید.
اگر طراحی در Figma انجام می‌شود، ابتدا قابلیت‌های Variables و ابزار مورد استفاده تیم را بررسی کنید. افزونه‌هایی مانند Tokens Studio مسیر دیگری برای مدیریت Token ارائه می‌کنند، ولی نصب افزونه به‌تنهایی طراحی و کد را همگام نمی‌کند. درباره امکانات هر پلن و نسخه حدس نزنید. انتقال داده، Resolve شدن Alias و کنترل تغییر همچنان باید در گردش کار شما تعریف شوند.
برای یک سایت کوچک، چند فایل CSS با نام‌های روشن ممکن است کافی باشد. زمانی سراغ خط تولید چند پلتفرمی بروید که واقعاً چند مصرف‌کننده دارید. هزینه نگهداری تنظیمات و آموزش تیم را هم در تصمیم حساب کنید؛ تعداد ابزار بیشتر به‌تنهایی نشانه بلوغ Design System نیست.
Tokenها جای تصمیم درباره چیدمان و دسترس‌پذیری را نمی‌گیرند
یکسان‌بودن فاصله‌ها الزاماً چیدمان خوبی نمی‌سازد. فاصله مناسب به رابطه اجزا و اولویت اطلاعات وابسته است. برای این بخش، مقاله فضای خالی و Negative Space در طراحی توضیح می‌دهد چرا فاصله باید به خواندن محتوا کمک کند. برای ساختار صفحه هم Grid System و نظم بصری ادامه مرتبطی است.
وقتی رابط را برای صفحه کوچک می‌سازید، ممکن است اندازه عنوان یا فاصله بخش‌ها تغییر کند. این تغییر باید دلیل مشخص داشته باشد، نه اینکه همه مقدارها برای موبایل نصف شوند. مطلب طراحی Mobile First به انتخاب اولویت محتوا کمک می‌کند. Tokenها تصمیم‌های انتخاب‌شده را منتقل می‌کنند؛ تحقیق کاربر و طراحی مسیر همچنان کار مستقل تیم است.
برای دسترس‌پذیری هم رنگ متن را همراه سطح زیر آن، Focus را در کنار حالت عادی و اندازه متن را در کنار بزرگ‌نمایی بررسی کنید. معیار Contrast در WCAG درباره ترکیب متن و پس‌زمینه است. داشتن نامی مثل accessible.text تضمین ایجاد نمی‌کند. توضیح Token باید نقش و محدودیت مصرف را روشن کند تا از ترکیب آن روی سطح نامناسب جلوگیری شود.
از یک بخش کوچک مهاجرت را شروع کنید
یک کامپوننت پرتکرار انتخاب کنید، مقدارهای آن را فهرست کنید و نام‌های مشترک را جدا کنید. سپس دو صفحه واقعی را با همان Tokenها پیاده کنید. اگر نام‌ها در صفحه دوم هم معنا دارند، معماری شروع مناسبی دارد. اگر برای هر صفحه استثنا ساخته‌اید، نقش‌های انتخابی را دوباره بررسی کنید. این مسیر پیشنهادی است و نتیجه واقعی به محصول شما وابسته است.
برای حذف یا تغییر نام Token، مصرف‌کننده‌ها و زمان مهاجرت را ثبت کنید. نام قدیمی را بدون اطلاع از چند مخزن حذف نکنید و Alias موقت را هم بی‌تاریخ نگه ندارید. در پایان این مرحله، تیم باید بتواند یک تغییر کوچک را از تصمیم طراحی تا خروجی کد دنبال کند. همین قابلیت پیگیری، معیار عملی بهتری از تعداد Tokenهای ساخته‌شده است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!