معماری متغیرهای Figma: چطور سیستم توکنی بسازیم که از تولید جان سالم به در ببرد

بیشتر تیم‌هایی که از متغیرهای Figma استفاده می‌کنند، روی یک مدل ذهنی مبتنی بر استایل بنا می‌کنند و مشکل دقیقاً همین است. متغیر بدون معماری فقط استایل است با چند کلیک اضافه.

تیم‌هایی که درست کار می‌کنند، متغیرهای Figma را یک لایه واقعی توکن طراحی می‌دانند: ساختاریافته، دارای alias، دارای scope و قابل export. تیم‌هایی که غلط کار می‌کنند، فقط یک درخواست دارک مود با بازسازی کامل فاصله دارند. این همان معماری‌ای است که از تولید جان سالم به در می‌برد.

متغیرها استایل نیستند، لایه توکن‌اند

استایل‌های Figma پیش‌تنظیم‌اند. یک رنگ، یک استایل متن یا یک افکت تعریف می‌کنید و مستقیم روی لایه اعمال می‌کنید. این برای فایل تک‌برندی و تک‌مودی بدون نیاز به هندآف به توسعه‌دهنده جواب می‌دهد. اما به محض اینکه چیزی تغییر کند، از کار می‌افتد.

متغیرهای Figma توکن هستند. متغیر یک مقدار نگه می‌دارد، ولی می‌تواند ارجاعی به متغیر دیگر هم نگه دارد. همین زنجیره ارجاع، و امکان عوض کردن کل مجموعه مقادیر resolve‌شده از طریق مودها، متغیرها را از نظر معماری از استایل‌ها جدا می‌کند. این تفاوت ظاهری نیست. فرق بین یک سیستم پیش‌تنظیم و یک سیستم توکن است.

معماری سه‌لایه توکن

پریمیتیو، سمانتیک، کامپوننت. هر سیستم متغیر کارآمدی این سه لایه را دارد. حذف لایه سمانتیک رایج‌ترین اشتباه معماری در فایل‌های Figma امروز است.

این سه لایه سه وظیفه دارند: پریمیتیو مقادیر خام را نگه می‌دارد، توکن‌های سمانتیک معنا را حمل می‌کنند و توکن‌های کامپوننت به یک خانواده کامپوننت محدود می‌شوند. هر لایه فقط با لایه زیرین خودش حرف می‌زند. بدون پرش، بدون میانبر.

این سه لایه بسته به اندازه پروژه اختیاری نیستند. حتی سیستم کوچکی با پنج کامپوننت هم به هر سه لایه نیاز دارد، وگرنه اولین درخواست تم آن را از هم می‌پاشد.

لایه اول: پریمیتیو

پریمیتیوها مقادیر خام‌اند. blue-500، gray-900، space-4، radius-md. پالت، مقیاس و پایه هستند. هرگز نباید مستقیم به لایه کامپوننت وصل شوند.

کار پریمیتیو این است که وجود داشته باشد، از بالا alias شود و سر راه نباشد. اگر طراحی دست به blue-500 می‌برد تا آن را روی دکمه بزند، معماری همین الان خراب شده است. پریمیتیوها در کالکشن پریمیتیو جا دارند و هیچ جای دیگر.

قرارداد نام‌گذاری اینجا مهم است. پریمیتیوها باید بر پایه مقیاس یا پالت نام بگیرند، هرگز سمانتیک. blue-500 درست است. button-blue به‌عنوان پریمیتیو یک خطای دسته‌بندی است که در مقیاس بالا دردسر می‌سازد.

لایه دوم: سمانتیک

توکن‌های سمانتیک معنا حمل می‌کنند. surface، surface-elevated، text-primary، text-muted، border-default، border-focus. به این سؤال جواب می‌دهند که «این رنگ برای چیست؟» نه اینکه «این چه رنگی است؟»

توکن‌های سمانتیک به پریمیتیوها alias می‌شوند. این تنها رابطه‌ای است که دارند. alias سمانتیک به سمانتیک ابهام می‌سازد که مقدار کجا زندگی می‌کند و override مودها را غیرقابل اعتماد می‌کند.

مودهای لایت، دارک و برند در همین لایه زندگی می‌کنند. توکن سمانتیک بسته به مود فعال به یک پریمیتیو متفاوت resolve می‌شود و تم‌سازی واقعاً همین‌طور کار می‌کند. پریمیتیو blue-500 تغییر نمی‌کند. توکن سمانتیک text-link است که بر اساس مود، مقصد resolve شدنش عوض می‌شود.

لایه سوم: کامپوننت

توکن‌های کامپوننت به یک خانواده کامپوننت محدود می‌شوند. button-bg، button-text، button-border، card-surface، card-border، input-bg. به توکن‌های سمانتیک alias می‌شوند، هرگز به پریمیتیو.

کار توکن کامپوننت، اختصاصی بودن بدون وابستگی شدید است. button-bg به surface-action resolve می‌شود و آن به blue-500. وقتی برند عوض شود، لایه سمانتیک را به‌روز می‌کنید و دکمه هم همراهش به‌روز می‌شود. توکن کامپوننت دست‌نخورده می‌ماند.

ایراد رایج این است که این‌ها توکن اضافه بدون دلیل به نظر می‌رسند. دلیلش این است که button-bg و surface-action می‌توانند از هم جدا شوند. یک جایی تصمیم محصولی می‌خواهد دکمه سطح کمی متفاوت استفاده کند. توکن‌های کامپوننت نقطه override را بدون دست زدن به سیستم سمانتیک به شما می‌دهند.

مود در برابر کالکشن: درخت تصمیم

مودها مقادیر را داخل یک کالکشن عوض می‌کنند. کالکشن‌ها دغدغه‌ها را از هم جدا می‌کنند. این دو یکی نیستند و قاطی کردنشان منشأ بیشتر سردرگمی‌های معماری در راه‌اندازی متغیرهای Figma است.

قاعده این است: برای هر دغدغه یک کالکشن، و مود برای حالت‌های مختلف همان دغدغه. رنگ یک دغدغه است. فاصله‌گذاری یک دغدغه است. لایت و دارک دغدغه‌های جدا نیستند. مودهای همان دغدغه رنگ‌اند.

کِی مود و کِی کالکشن جدید:

• مقدار متفاوت از همان چیز؟ مود.
• چیزی کاملاً متفاوت؟ کالکشن.
• جابه‌جایی بین لایت و دارک؟ مود داخل کالکشن رنگ.
• جابه‌جایی بین فاصله‌گذاری فشرده و راحت؟ مود داخل کالکشن فاصله‌گذاری.
• اضافه کردن برند؟ مود داخل لایه سمانتیک، نه کالکشن جدید.

چهار قاعده scope

Scope متغیر تعیین می‌کند متغیر در کجای Figma قابل اعمال باشد. اگر این را غلط بگیرید، طراح‌ها ممکن است به‌جای توکن سمانتیک اتفاقی سراغ پریمیتیو بروند و انضباط معماری درست در لحظه استفاده فرو بریزد.

این چهار قاعده چانه‌بردار نیستند:

1. scope پریمیتیوها را روی هیچ‌جا بگذارید. پریمیتیوها نباید در هیچ جایی قابل اعمال باشند. مقادیر داخلی‌اند، نه توکن رو به مصرف‌کننده. آن‌ها را کاملاً از dropdown اعمال پنهان کنید.
2. scope توکن‌های سمانتیک را به نوعشان محدود کنید. توکن سمانتیک رنگ به fill و stroke محدود می‌شود. توکن فاصله‌گذاری به فیلدهای gap، padding و size. scope را تنگ نگه دارید.
3. scope توکن‌های کامپوننت را به خانواده‌شان محدود کنید. توکن دکمه نباید روی کارت قابل اعمال باشد. اگر scope خیلی گسترده باشد، مرز کامپوننت بی‌معنی می‌شود.
4. هرگز پریمیتیوها را در معرض مصرف‌کننده‌ها نگذارید. اگر طراح یا توسعه‌دهنده‌ای پریمیتیو را روی لایه‌ای اعمال می‌کند، سیستم در لایه scope شکست خورده است. این شکست فرایند است، نه شکست کاربر.

زنجیره aliasای که تم را ممکن می‌کند

یک تم کارآمد زنجیره‌ای از aliasهاست: کامپوننت به سمانتیک alias می‌شود، سمانتیک به پریمیتیو، و پریمیتیو مقدار را نگه می‌دارد. طول زنجیره سه است، همیشه سه.

زنجیره دوتایی (کامپوننت به پریمیتیو) لایه ترجمه را رد می‌کند و مودها را بدون override دستی روی تک‌تک توکن‌های کامپوننت غیرممکن می‌سازد. زنجیره چهارتایی ابهام می‌سازد که کدام لایه سمانتیک مود را حمل می‌کند و ممیزی آن به‌جای یک جست‌وجو به یک جلسه دیباگ تبدیل می‌شود.

button-bg → surface-action → blue-500 → #0066FF

Copy

این زنجیره با به‌روز کردن surface-action تا در مود دارک کالکشن سمانتیک به blue-300 اشاره کند، از دارک مود جان سالم به در می‌برد. توکن button-bg خودکار به‌روز می‌شود. پریمیتیو blue-500 همچنان به #0066FF resolve می‌شود. هیچ چیز دیگری نیاز به تغییر ندارد.

مودهای لایت، دارک و برند

سه مودی که بیشتر سیستم‌های متغیر نیاز دارند لایت، دارک و برند است. فقط لایه سمانتیک آن‌ها را حمل می‌کند. هرگز لایه پریمیتیو.

اعمال مود روی پریمیتیوها یک خطای دسته‌بندی است. blue-500 همیشه #0066FF است. پریمیتیو است. نسخه لایت یا دارک ندارد چون معنایی حمل نمی‌کند. توکن سمانتیک text-link نسخه لایت و دارک دارد چون معنایی حمل می‌کند که در زمینه‌های مختلف متفاوت resolve می‌شود.

مودهای برند هم همین‌طورند. برند دوم به پالت پریمیتیو دوم نیاز ندارد مگر اینکه واقعاً مقادیر خام متفاوتی داشته باشد. بیشتر وقت‌ها یک مود برند در لایه سمانتیک که به زیرمجموعه دیگری از پریمیتیوهای موجود اشاره کند انتخاب درست است. دو کالکشن کامل پریمیتیو برای دو برند معمولاً زیاده‌روی است. برای اینکه تصمیم‌های رنگ در بالادست چطور این را شکل می‌دهند، مقاله سیستم رنگ دارک مود قبل از قفل کردن ساختار لایه سمانتیک ارزش خواندن دارد.

متغیرهای عددی، رشته‌ای و بولین

متغیرهای Figma فقط رنگ نیستند. متغیرهای عددی فاصله‌گذاری، اندازه و radius را کنترل می‌کنند. متغیرهای رشته‌ای متن داخل فایل‌های طراحی را. متغیرهای بولین نمایش لایه‌ها را، که مستقیم به propهای کامپوننت نگاشت می‌شود.

این بخشی از سیستم متغیر است که بیشتر تیم‌ها از آن استفاده نمی‌کنند، و بخشی است که شکاف بین طراحی و کد را از همه چیز بیشتر می‌بندد. مقیاس فاصله‌گذاری که به‌صورت متغیر عددی تعریف شده و روی gapهای auto-layout اعمال شده، یعنی تغییر در متغیر هر کامپوننتی را که از آن توکن استفاده می‌کند به‌روز می‌کند. کار یک سیستم توکن واقعی همین است.

متغیرهای رشته‌ای با مودهای locale به طراح‌ها اجازه می‌دهند فایل را بین انگلیسی و عربی جابه‌جا کنند و خراب شدن چیدمان را زنده ببینند. متغیرهای بولین که به propهای کامپوننت نگاشت می‌شوند یعنی کامپوننت Figma و کامپوننت کد رابطه prop یک‌به‌یک دارند، و همین هندآف به توسعه‌دهنده را قابل بازبینی می‌کند نه قابل تفسیر.

هندآف به کد: الگویی که جواب می‌دهد

یک سیستم متغیر فقط به اندازه export آن خوب است. الگوی هندآف کارآمد Tokens Studio یا Figma Variables REST API است، به‌علاوه یک پایپ‌لاین تبدیل، به‌علاوه یک اسکریپت import سمت کد.

Tokens Studio کالکشن‌های متغیر را به فرمت JSON ساختاریافته‌ای export می‌کند که با Style Dictionary سازگار است. Style Dictionary آن JSON را به هر خروجی که کدبیس نیاز دارد تبدیل می‌کند: CSS custom properties، Swift color sets، فایل‌های resource کاتلین، کانفیگ Tailwind. مرحله تبدیل جایی است که قراردادهای نام‌گذاری نرمال می‌شوند و هر نام‌گذاری مختص Figma که با قراردادهای کد جور نیست پاک‌سازی می‌شود.

پایپ‌لاین باید با هر به‌روزرسانی متغیر اجرا شود، نه دستی. یک GitHub Action که با push در Tokens Studio فعال شود یا یک webhook در Figma که با تغییر متغیرها اجرا شود، توکن‌های سمت کد را بدون اینکه کسی یادش بیاید export کند هماهنگ نگه می‌دارد. این همان الگویی است که Stripe و Atlassian در مقیاس بالا اجرا می‌کنند و در هر کدبیسی که مرحله build دارد قابل دستیابی است. برای تصمیم‌های فرمت توکن رنگ در آن خروجی، رنگ OKLCH قبل از قفل کردن مقادیر CSS custom property ارزش خواندن دارد.

---

سیستم متغیر Figma می‌خواهید که بدون بازنویسی از مودها، برندها و هندآف به توسعه‌دهنده جان سالم به در ببرد؟ Brainy معماری توکن آماده تولید را در Figma طراحی می‌کند، با مدل سه‌لایه، زنجیره alias و پایپ‌لاین export که تمیز در کدبیس شما می‌نشیند. Brainy را استخدام کنید

---

هفت اشتباه رایج که سیستم‌های متغیر را می‌شکنند

بیشتر این اشتباه‌ها ریشه مشترک دارند: پنل متغیرها را یک پنل استایل بهتر دانستن به‌جای اینکه آن را یک لایه معماری ببینیم. اصلاح مدل ذهنی همان درمان است. بقیه چیزها از آن نتیجه می‌شوند.

ممیزی سیستم متغیر

این ممیزی را روی هر سیستم متغیر Figma اجرا کنید تا بدهی معماری را پیش از انتشار بگیرید.

ساختار

• حداقل سه کالکشن: پریمیتیو، سمانتیک، کامپوننت (یا نام‌گذاری معادل)
• هر کالکشن یک دغدغه واحد و روشن دارد
• هیچ کالکشنی انواع را قاطی نمی‌کند (رنگ و فاصله‌گذاری در یک کالکشن یعنی شکست)

زنجیره alias

• هر توکن کامپوننت به توکن سمانتیک alias می‌شود، نه پریمیتیو
• هر توکن سمانتیک به پریمیتیو alias می‌شود، نه توکن سمانتیک دیگر
• هیچ توکنی جز پریمیتیوها مقدار خام ندارد
• طول زنجیره alias برای همه توکن‌های رنگ دقیقاً سه است

مودها

• لایت و دارک مودهای کالکشن سمانتیک‌اند، نه کالکشن‌های جدا
• نسخه‌های برند مودهای کالکشن سمانتیک‌اند، نه فایل‌های جدا
• کالکشن پریمیتیو مود ندارد

Scope

• متغیرهای پریمیتیو روی هیچ‌جا scope شده‌اند (در هیچ جا قابل اعمال نیستند)
• متغیرهای سمانتیک به نوعشان scope شده‌اند (رنگ به fill/stroke، فاصله‌گذاری به فیلدهای layout)
• متغیرهای کامپوننت به خانواده کامپوننتشان scope شده‌اند

هندآف

• متغیرها از طریق Tokens Studio یا REST API قابل export هستند
• پایپ‌لاین تبدیل وجود دارد و خودکار است
• توکن‌های سمت کد با قرارداد نام‌گذاری متغیرهای Figma می‌خوانند و استثناها مستند شده‌اند

اگر بیش از سه مورد از این‌ها رد شود، سیستم به بازسازی نیاز دارد نه وصله. یک پالت رنگ برند تصمیم‌های رنگ بالادستی را که به لایه پریمیتیو می‌رسند پوشش می‌دهد، اگر ممیزی بیشترین بدهی را همان‌جا نشان داد.

FAQ

تفاوت متغیرهای Figma و استایل‌های Figma چیست؟

استایل‌ها پیش‌تنظیم‌هایی هستند که مستقیم روی لایه‌ها اعمال می‌شوند. متغیرها توکن‌هایی هستند که می‌توانند به هم ارجاع دهند و مقادیرشان را از طریق مودها عوض کنند. متغیرها هر کاری که استایل‌ها می‌کنند انجام می‌دهند، به‌علاوه تم‌سازی، به‌علاوه هندآف به توسعه‌دهنده از طریق export. برای یک سیستم طراحی جدید، متغیرها انتخاب درست‌اند. برای فایل موجودی با سیستم استایل بالغ، قبل از تغییر ارزش دارد یک برنامه مهاجرت بنویسید.

یک سیستم متغیر Figma چند کالکشن باید داشته باشد؟

سه تا پنج برای بیشتر سیستم‌ها: پریمیتیو، سمانتیک، کامپوننت، و در صورت نیاز کالکشن‌های جدا برای فاصله‌گذاری و تایپوگرافی اگر آن مقیاس‌ها آن‌قدر پیچیده باشند که قاعده scope خودشان را بخواهند. بیش از پنج کالکشن معمولاً نشانه این است که دغدغه‌ها درست گروه‌بندی نشده‌اند.

آیا متغیرهای Figma می‌توانند جای Tokens Studio را بگیرند؟

برای ساخت و ویرایش داخل Figma، بله. پنل بومی متغیرها بیشتر کارهایی را که Tokens Studio پیش از آمدن API متغیرها انجام می‌داد پوشش می‌دهد. برای export و تبدیل، Tokens Studio هنوز ارزش اضافه می‌کند چون پایپ‌لاین بالغی به Style Dictionary دارد و موارد لبه‌ای را که export بومی پوشش نمی‌دهد مدیریت می‌کند. این دو ابزار فعلاً مکمل‌اند، نه رقیب.

اگر یک توکن سمانتیک را به توکن سمانتیک دیگر alias کنم چه می‌شود؟

resolve شدن مود مبهم می‌شود. اگر text-secondary به text-primary alias شود و به دارک مود بروید، Figma زنجیره را resolve می‌کند و ممکن است override دارک مود را آنجا که انتظار دارید اعمال نکند. alias سمانتیک به سمانتیک ممیزی سیستم را هم در مقیاس بالا تقریباً غیرممکن می‌کند. قاعده سفت و سخت است: توکن‌های سمانتیک فقط به پریمیتیوها alias می‌شوند.

چطور برند سوم را بدون بازسازی سیستم مدیریت کنم؟

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

آیا مدل سه‌لایه برای پروژه‌های کوچک لازم است؟

بله، اما اندازه هر لایه کوچک‌تر می‌شود. یک پروژه کوچک ممکن است پانزده پریمیتیو، هشت توکن سمانتیک و دو توکن کامپوننت برای هر کامپوننت داشته باشد. معماری همچنان سه لایه است. وسوسه حذف سمانتیک در پروژه‌های کوچک دلیل اینکه این‌همه پروژه کوچک به‌محض ظهور طراح دوم یا درخواست دارک مود به بدهی معماری تبدیل می‌شوند. برای اینکه معماری توکن در تصمیم پشته گسترده‌تر کجا می‌نشیند، مقاله Framer در برابر Webflow در برابر Next.js زمینه دارد.

تغییری که متغیرهای Figma واقعاً باز می‌کنند

یک سیستم متغیر واقعی در Figma نزدیک‌ترین چیزی است که طراحی و توسعه تا امروز به یک منبع واحد حقیقت رسیده‌اند. نه سند هندآف. نه لینک Zeplin. یک لایه توکن زنده، قابل export و ساختاریافته که هر دو طرف از همان تعریف‌ها می‌خوانند.

تیم‌هایی که متغیرها را معماری می‌دانند بدهی سیستم طراحی را نصف می‌کنند، نه چون متغیرها جادویی‌اند، بلکه چون انضباط معماری‌ای که یک سیستم متغیر خوب می‌خواهد، تصمیم‌هایی را هم اجبار می‌کند که سیستم‌های طراحی مدام به تعویق می‌انداختند. این توکن چه معنایی دارد؟ به چه چیزی می‌تواند alias شود؟ صاحب پریمیتیو کیست؟ این سؤال‌ها حالا جواب دارند و جواب‌ها در خود فایل زندگی می‌کنند.

متغیر بدون معماری فقط استایل است با چند کلیک اضافه. متغیر با مدل سه‌لایه، زنجیره alias، قاعده‌های scope و پایپ‌لاین export یک سیستم طراحی است که می‌تواند برند دوم، دارک مود و توسعه‌دهنده‌ای را که هرگز Figma را باز نکرده تاب بیاورد.

معماری را بسازید، نه فقط توکن‌ها را.