دیزاین سیستم چند لایه توکن لازم داره ؟

در سال‌های اخیر، Design Systemهای مختلف معماری‌های متفاوتی برای Tokenها معرفی کردن. Adobe Spectrum از چهار لایه استفاده می‌کنه، Material Design سه لایه داره، Carbon ساختار متفاوت خودش رو داره و Tailwind هم مسیر کاملاً جداگانه‌ای رو انتخاب کرده. وقتی این تفاوت‌ها رو می‌بینیم، طبیعی‌ه که اولین سؤال این باشه: «بالاخره کدوم معماری درسته؟»

واقعیت اینه که همه اون‌ها درستن، چون هیچ‌کدوم برای حل یک مسئله یکسان طراحی نشدن. هر Design System بر اساس نیازهای محصولی که پشتش قرار داره شکل گرفته و معماری Tokenها هم دقیقاً از همین نیازها تأثیر گرفته.

برای مثال، Adobe Spectrum باید از ده‌ها محصول با نیازهای متفاوت، چندین تم و حتی چندین برند پشتیبانی کنه. طبیعی‌ه که برای مدیریت چنین پیچیدگی‌ای به لایه‌های بیشتری نیاز داشته باشه. در مقابل، Material Design برای یک زبان طراحی عمومی توسعه پیدا کرده و بسیاری از محصولاتی که از اون استفاده می‌کنن، با پیچیدگی یک اکوسیستم Multi-brand روبه‌رو نیستن. به همین خاطر، معماری ساده‌تری هم براش کافی بوده.

به همین دلیل، مقایسه مستقیم این Design Systemها معمولاً ما رو به تصمیم درستی نمی‌رسونه. اینکه Adobe چهار لایه داره یا Material سه لایه، به این معنی نیست که همون ساختار برای محصول ما هم بهترین انتخابه.

شاید قبل از اینکه بپرسیم «Adobe چند لایه داره؟» بهتر باشه از خودمون یک سؤال دیگه بپرسیم: محصول ما در آینده قراره چه چیزهایی رو مستقل از هم تغییر بده؟ اگر فقط یک برند و یک تم داریم، شاید دو یا سه لایه کاملاً کافی باشه. اما اگر قراره چند برند، چند تم یا حتی چند پلتفرم رو مدیریت کنیم، احتمالاً باید از همین امروز معماری انعطاف‌پذیرتری طراحی کنیم.

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

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

اما همین معماری ساده، وقتی محصول رشد می‌کنه، کم‌کم محدودیت خودش رو نشون می‌ده. فرض کنید شرکت تصمیم می‌گیره نسخه White Label ارائه بده، Dark Mode اضافه کنه یا محصول روی چند پلتفرم مختلف منتشر بشه. از اینجا به بعد، تغییراتی که قبلاً در چند دقیقه انجام می‌شدن، به تصمیم‌هایی تبدیل می‌شن که روی بخش‌های مختلف سیستم اثر می‌ذارن.

برای مثال، تغییر رنگ برند دیگه فقط عوض کردن یک کد Hex نیست. باید مشخص بشه این تغییر روی کدوم Semantic Tokenها اثر می‌ذاره، کدوم کامپوننت‌ها باید به‌روزرسانی بشن، آیا Themeهای دیگه هم تحت تأثیر قرار می‌گیرن یا نه و آیا بعضی از کامپوننت‌ها باید رفتار مستقلی داشته باشن. هرچقدر این وابستگی‌ها بیشتر می‌شن، نیاز به لایه‌های بیشتر هم منطقی‌تر می‌شه.

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

تعداد Layer معیار بلوغ Design System نیست

یکی از اشتباه‌هایی که زیاد بین تیم‌های Design System می‌بینیم اینه که معماری یک شرکت بزرگ رو بدون اینکه به نیازهای محصول خودشون نگاه کنن، کپی می‌کنن. Adobe چهار لایه Token داره، پس ما هم باید چهار لایه داشته باشیم. Material سه لایه داره، پس سه لایه بهترین انتخابه. در حالی که این نتیجه‌گیری از همون ابتدا اشتباهه.

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

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

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

یکی از اشتباه‌هایی که زیاد بین تیم‌های Design System می‌بینیم اینه که معماری شرکت‌های بزرگ رو بدون اینکه به مسئله خودشون نگاه کنن، کپی می‌کنن. Adobe چهار لایه Token داره، Material سه لایه و Carbon هم ساختار متفاوت خودش رو داره. بعد سؤال این می‌شه که «بالاخره کدوم معماری درسته؟» در حالی که شاید سؤال از همون ابتدا اشتباه باشه.

حالا ببینیم هر معماری چه مسئله‌ای را حل می‌کند

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

معماری دو لایه Token؛ زمانی که سادگی بهترین انتخاب است

ساده‌ترین مدل معمولاً شامل دو سطح است:

Primitive Tokens

↓

Semantic Tokens

در این معماری، Primitiveها مقدارهای پایه سیستم هستند:

{

"color.blue.600": "#2563EB",

"color.gray.900": "#111827",

"radius.md": "8px",

spacing.md": "16px

}

اما این مقدارها مستقیم در کامپوننت استفاده نمی‌شوند.

یک لایه معنایی روی آن‌ها قرار می‌گیرد:

{

"color.action.primary": "{color.blue.600}",

"color.text.primary": "{color.gray.900}",

button.radius": "{radius.md}

}

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

این مدل برای محصولاتی مناسب است که:

یک Brand دارند.

تعداد Theme محدود دارند.

تیم کوچک یا متوسط دارند.

نیاز به تغییرات پیچیده ندارند.

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

معماری سه لایه Token؛ جایی که Design System بالغ می‌شود

اما این پایان ماجرا نیست. وقتی Design System از مرز یک محصول عبور می‌کنه و باید چند برند یا چند محصول رو هم‌زمان مدیریت کنه، خیلی از تیم‌ها یک لایه دیگه هم به معماری Tokenها اضافه می‌کنن.

Primitive

↓

Semantic

↓

Component

دلیل اضافه شدن این Layer یک سؤال ساده است: آیا همه تصمیم‌ها باید در سطح Semantic حل شوند؟ مثلاً:

Semantic Token:

{

"color.action.primary":

{color.blue.600}

}

برای چندین Component استفاده می‌شود.اما Button ممکن است تصمیم‌های مخصوص خودش را داشته باشد:

Radius

Padding

Height

Stateها

Disabled behavior

پس یک Component Token ایجاد می‌کنیم:

{

"button.primary.background":

"{color.action.primary}",

"button.primary.radius":

"{radius.md}",

"button.primary.padding":

{spacing.md}

}

با این ساختار، تغییر Button دیگه به معنی تغییر کل سیستم نیست. هر کامپوننت می‌تونه تصمیم‌های اختصاصی خودش رو داشته باشه، بدون اینکه بقیه اجزای Design System تحت تأثیر قرار بگیرن. به همین دلیل، خیلی از تیم‌ها این معماری رو نقطه تعادل مناسبی بین سادگی و مقیاس‌پذیری می‌دونن.

معماری چهار لایه Token؛ وقتی Design System تبدیل به Platform می‌شود

چهار لایه معمولاً زمانی لازم می‌شن که یک Design System قرار باشه چند محصول رو هم‌زمان پشتیبانی کنه. در چنین شرایطی، مسئله فقط تغییر یک رنگ یا اضافه کردن Dark Mode نیست؛ هر محصول ممکنه برند، Theme یا حتی قوانین طراحی متفاوتی داشته باشه و معماری باید این تغییرها رو بدون دست زدن به کامپوننت‌ها مدیریت کنه.

Global

↓

Brand

↓

Semantic

↓

Component

فرض کنید یک شرکت هم‌زمان چند محصول مختلف داره. یکی با برند آبی منتشر می‌شه، یکی با برند نارنجی و دیگری نسخه سازمانی با Theme اختصاصی خودش رو داره. احتمال داره همه این محصولات از یک Design System مشترک استفاده کنن و حتی Primitive Tokenهای یکسانی داشته باشن. اما چیزی که باید بین اون‌ها تغییر کنه، خود مقدارها نیست؛ نقش و نگاشت اون مقدارهاست. اگر این تغییرها از قبل در معماری پیش‌بینی نشده باشن، هر برند جدید به معنی تغییر مستقیم در کامپوننت‌ها خواهد بود؛ در حالی که با یک معماری چندلایه، همین تغییر می‌تونه فقط با اصلاح یک لایه انجام بشه

{

purple.500": "#6B4FB8

}

اما Brand Layer تصمیم می‌گیرد کدام رنگ در هر محصول استفاده شود:

{

"brand.primary":

{purple.500}

}

بعد Semantic Layer معنا ایجاد می‌کند:

{

"action.primary":

{brand.primary}

}

و در نهایت Component از آن استفاده می‌کند:

{

"button.primary.background":

{action.primary}

}

این معماری اجازه می‌دهد تغییر برند بدون بازنویسی کل سیستم انجام شود.

پس کدام معماری را انتخاب کنیم؟

جواب این سؤال را نمی‌شود با نگاه کردن به معماری Adobe، Material یا هر Design System دیگری پیدا کرد. معماری درست از دل نیازهای خود محصول بیرون می‌آید، نه از روی تعداد Layerهایی که یک شرکت دیگر استفاده کرده است.

بهتر است به این فکر کنیم که محصول امروز کجاست و احتمال دارد در آینده به کجا برسد. آیا قرار است برندهای جدید به آن اضافه شوند؟ آیا Dark Mode یا Themeهای مختلف در برنامه محصول هستند؟ آیا قرار است روی چند Platform منتشر شود یا چند تیم مستقل هم‌زمان روی آن کار کنند؟ شاید هم قرار باشد محصول به‌صورت White Label در اختیار مشتری‌های مختلف قرار بگیرد.

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

در نهایت، معماری خوب آن معماری نیست که بیشترین تعداد Layer را داشته باشد؛ معماری خوب، معماری‌ای است که به اندازه پیچیدگی محصول طراحی شده باشد، نه بیشتر و نه کمتر.

جمع‌بندی

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

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

به نظر ما، معماری Token نباید از روی Adobe، Material یا هر Design System معروف دیگه‌ای کپی بشه. معماری باید از روی آینده محصول طراحی بشه؛ از روی تغییراتی که احتمال داره چند ماه یا چند سال بعد با اون‌ها روبه‌رو بشیم.

شاید قبل از اینکه بپرسیم «چند لایه Token لازم داریم؟» بهتر باشه از خودمون یک سؤال دیگه بپرسیم: «چه چیزهایی باید بتونن مستقل از هم تغییر کنن؟»

جواب همین سؤال، معمولاً معماری درستی رو که Design System بهش نیاز داره، مشخص می‌کنه.