چرا Variant زیاد Design system رو خراب میکنه؟

مشکل اصلی، تعداد Variantها نیست؛ مشکل تصمیم‌های اضافه است

هدف اصلی Design System این نیست که تمام حالت‌های ممکن را در خود جای دهد.یک Design System خوب باید تصمیم‌گیری را ساده‌تر کند.وقتی یک طراح می‌خواهد از یک Button استفاده کند، انتظار دارد سیستم به او کمک کند که سریع‌تر تصمیم بگیرد. اما اگر با ده‌ها Variant مختلف مواجه شود، بخشی از همان تصمیم‌گیری که قرار بود توسط Design System حل شود، دوباره به خود طراح برمی‌گردد.در چنین شرایطی، سیستم به جای کاهش پیچیدگی، پیچیدگی را پنهان کرده است.فرض کنید یک طراح می‌خواهد برای صفحه پرداخت یک دکمه انتخاب کند. در یک سیستم ساده، انتخاب مشخص است: یک Primary Button برای مهم‌ترین اقدام صفحه.اما در یک سیستم بیش از حد پیچیده، سؤال‌های زیادی ایجاد می‌شود:آیا باید از Primary استفاده شود یا Strong Primary؟ آیا نسخه Compact مناسب‌تر است؟ آیا اینجا به Danger Variant نیاز داریم؟ آیا در موبایل باید حالت متفاوتی داشته باشد؟در این نقطه، Design System دیگر فقط یک ابزار نیست؛ خودش تبدیل به یک مسئله برای حل کردن می‌شود.

چرا تیم‌ها به سمت Variantهای زیاد می‌روند؟

تقریباً هیچ تیمی عمداً یک Component پیچیده نمی‌سازد. معمولاً این اتفاق به مرور و با تصمیم‌های کوچک رخ می‌دهد.یک تیم محصول درخواست می‌کند که یک Button متفاوت برای یک صفحه خاص داشته باشد. تیم Design System برای حل سریع مشکل، یک Variant جدید اضافه می‌کند.چند ماه بعد، تیم دیگری با نیاز مشابهی مواجه می‌شود و Variant دیگری اضافه می‌شود.بعد از چند سال، Componentها تبدیل به مجموعه‌ای از تصمیم‌های تاریخی می‌شوند.هر Variant یک داستان پشت خود دارد:این یکی برای یک مشتری خاص ساخته شد. آن یکی برای یک کمپین اضافه شد. یکی دیگر برای حل یک مشکل موقت ایجاد شد، اما هیچ‌وقت حذف نشد.مشکل از جایی شروع می‌شود که Design System دیگر فقط نماینده نیازهای فعلی نیست؛ بلکه تبدیل به آرشیوی از تمام تصمیم‌های گذشته می‌شود.

هر Variant باید یک دلیل قوی برای وجود داشته باشد

داشتن تفاوت ظاهری همیشه دلیل کافی برای ساخت Variant جدید نیست.قبل از اضافه کردن یک Variant، باید پرسید:آیا این تفاوت یک نیاز واقعی و تکرارشونده است؟اگر فقط یک صفحه خاص به این حالت نیاز دارد، شاید بهتر باشد آن نیاز در سطح همان محصول حل شود، نه در Core Design System.همچنین باید بررسی کرد که آیا این تفاوت، معنای متفاوتی دارد یا فقط ظاهر متفاوتی ایجاد کرده است.برای مثال، Primary Button و Danger Button فقط دو رنگ متفاوت نیستند. هرکدام پیام و کاربرد متفاوتی دارند. یکی برای انجام مهم‌ترین Action استفاده می‌شود و دیگری درباره یک اقدام حساس یا غیرقابل بازگشت هشدار می‌دهد.اما اگر فقط رنگ یک Button تغییر کرده چون در یک صفحه خاص بهتر دیده می‌شود، احتمالاً ارزش تبدیل شدن به یک Variant مستقل را ندارد.

انعطاف‌پذیری زیاد همیشه به معنی سیستم بهتر نیست

یکی از اشتباه‌های رایج در Design System این است که انعطاف‌پذیری را با کیفیت اشتباه بگیریم.یک Component که صدها حالت مختلف دارد، الزاماً بهتر از Componentی با چند حالت مشخص نیست.انعطاف‌پذیری زمانی ارزشمند است که یک نیاز واقعی را حل کند.اما زمانی که فقط گزینه‌های بیشتری ایجاد می‌کند، تبدیل به پیچیدگی می‌شود.تفاوت این دو مفهوم مهم است:Flexibility یعنی سیستم بتواند نیازهای واقعی مختلف را پوشش دهد.Complexity یعنی سیستم آن‌قدر گزینه داشته باشد که استفاده از آن دشوار شود.یک سیستم خوب همیشه تلاش نمی‌کند همه حالت‌های ممکن را پوشش دهد؛ بلکه تلاش می‌کند مهم‌ترین حالت‌ها را به بهترین شکل پشتیبانی کند.

Design System بالغ می‌داند چه چیزی را اضافه نکن

بسیاری از تیم‌ها موفقیت Design System را با این سؤال می‌سنجند:«چه Component یا Variant جدیدی باید اضافه کنیم؟»اما تیم‌های بالغ سؤال دیگری می‌پرسند:«چه چیزی نباید وارد سیستم شود؟»گاهی حذف یک Variant ارزش بیشتری از ساختن یک Variant جدید دارد، چون هر حذف، یک تصمیم غیرضروری را از صدها Designer و Developer کم می‌کند.Design System خوب فقط مجموعه‌ای از امکانات نیست؛ مجموعه‌ای از تصمیم‌های آگاهانه است.

قبل از ساخت Variant جدید چه سؤال‌هایی باید پرسید؟

قبل از اضافه کردن یک حالت جدید به Component، بهتر است چند سؤال بررسی شود:آیا این نیاز در چند بخش محصول تکرار می‌شود؟ آیا این تفاوت یک مفهوم جدید ایجاد می‌کند یا فقط ظاهر را تغییر می‌دهد؟ آیا کاربران Design System واقعاً به این Variant نیاز دارند؟ آیا این مسئله با Composition یا Component دیگری قابل حل است؟ هزینه نگهداری این Variant در آینده چقدر خواهد بود؟اگر پاسخ این سؤال‌ها مشخص نباشد، احتمالاً هنوز زمان مناسبی برای اضافه کردن Variant جدید نیست.در نهایت، یک Design System خوب با تعداد Variantهایش سنجیده نمی‌شود.سیستمی که صدها حالت مختلف دارد، الزاماً بالغ‌تر از سیستمی با تعداد محدود Component نیست.گاهی بهترین Design System همان سیستمی است که به جای ارائه ده‌ها انتخاب، چند انتخاب درست را جلوی تیم قرار می‌دهد.چون ارزش واقعی Design System در زیاد کردن گزینه‌ها نیست؛ بلکه در کاهش تصمیم‌های غیرضروری است. 💬 در Design System شما، کدام Component بیشتر از همه دچار انفجار Variant شده است؟ Button، Input یا Component دیگری؟