وقتی یک Design System شروع به رشد میکنه، معمولاً یک اتفاق قابل پیشبینی میافته: تعداد درخواستها برای اضافه شدن Componentهای جدید بیشتر میشه. یک تیم User Card ساخته و فکر میکنه تیمهای دیگه هم ممکنه بهش نیاز داشته باشن. تیم دیگه یک Transaction List طراحی کرده که در چند صفحه تکرار شده. جای دیگه هم یک Filter جدید ساخته شده که احتمالاً در آینده کاربردهای بیشتری خواهد داشت. در نگاه اول، اضافه کردن همه این موارد به Library تصمیم منطقیای به نظر میرسه؛ بالاخره یکی از اهداف Design System جلوگیری از دوبارهکاریه.اما اینجا یک سؤال مهم وجود داره: آیا هر چیزی که چند بار استفاده میشه، باید وارد Design System بشه؟به نظر ما پاسخ منفیه. یکی از مهارتهای مهم تیم Design System فقط تشخیص چیزهایی نیست که باید وارد Library بشن؛ بخش مهمتر، تشخیص چیزهاییه که نباید وارد اون بشن.دلیلش هم اینه که اضافه کردن یک Component به Design System با اضافه کردن یک Component معمولی به محصول فرق داره. وقتی یک Component وارد سیستم میشه، عملاً تیم یک تعهد بلندمدت ایجاد میکنه. از اون لحظه باید API مشخصی داشته باشه، Stateها و Variantهاش تعریف بشن، Accessibility بررسی بشه، نسخه Design و Code با هم هماهنگ بمونن، Documentation نوشته بشه و هر تغییری در آینده با در نظر گرفتن تمام مصرفکنندههای اون انجام بشه.بنابراین سؤال اصلی نباید این باشه که «آیا میتونیم این Component رو به Library اضافه کنیم؟» تقریباً همیشه میتونیم. سؤال مهمتر اینه که «آیا این Component ارزش هزینهای رو که در آینده برای سیستم ایجاد میکنه، داره؟»
تکرار، بهتنهایی معیار خوبی نیست
یکی از رایجترین معیارها برای اضافه کردن Component اینه که بگیم «این Pattern چند بار تکرار شده، پس باید وارد Design System بشه.»فرض کنید در یک محصول بانکی، Transaction Card در ۱۰ صفحه مختلف استفاده شده. این Card اطلاعاتی مثل مبلغ، تاریخ، وضعیت تراکنش، شماره پیگیری و Actionهای مرتبط رو نمایش میده. چون استفاده از اون زیاده، ممکنه در نگاه اول کاملاً منطقی باشه که وارد Design System بشه.اما اگر دقیقتر نگاه کنیم، مسئله فرق میکنه. Transaction Card احتمالاً به قوانین و اطلاعات Domain تراکنش وابسته است. اگر فردا تیم دیگهای در محصولی غیرمالی بخواد از Design System استفاده کنه، این Component تقریباً هیچ ارزشی براش نداره.در این شرایط، Design System میتونه اجزای پایه موردنیاز برای ساخت اون رو فراهم کنه؛ مثلاً Card، Badge، Icon، Button، Typography و Tokenهای موردنیاز. اما ترکیب این اجزا برای ساخت Transaction Card میتونه همچنان متعلق به Domain تراکنش باقی بمونه.اینجا یک تفاوت مهم بین Reuse داخل محصول و Reuse در سطح سیستم وجود داره. یک Component ممکنه صد بار در یک محصول استفاده بشه و همچنان Product Component باشه. در مقابل، Component دیگهای شاید فقط در چند نقطه استفاده بشه، اما چون مسئلهای عمومی و پایدار رو حل میکنه، جای مناسبی در Design System داشته باشه.بنابراین تعداد استفاده مهمه، اما بهتنهایی تصمیم رو مشخص نمیکنه.
کامنتها
…