اگر فرد کلیدی Design System از تیم بره چی میشه؟

در نگاه اول، یک Design System مجموعه‌ای از چیزهای مشخص به نظر می‌رسد: Componentها، Tokenها، Documentation، فایل‌های طراحی و Packageهای کد.

اما تیم‌هایی که مدت زیادی روی Design System کار کرده‌اند، می‌دانند که بخش مهمی از ارزش یک سیستم فقط در این خروجی‌های قابل مشاهده نیست. بخش بزرگی از دانش سیستم در تجربه و تصمیم‌هایی وجود دارد که افراد تیم در طول زمان به دست آورده‌اند.

برای مثال، یک Design System Lead یا یک Senior Designer که چند سال روی سیستم کار کرده است، معمولاً پاسخ بسیاری از سؤال‌ها را می‌داند:

چرا این Token به وجود آمد؟ چرا این Component با وجود درخواست‌های زیاد وارد Core System نشد؟ چرا یک Pattern خاص انتخاب شد و گزینه‌های دیگر کنار گذاشته شدند؟ چرا یک Variant حذف شد، اما Variant دیگری باقی ماند؟

این تصمیم‌ها ممکن است هیچ‌وقت به شکل رسمی در Documentation ثبت نشده باشند، اما بخشی از منطق سیستم را تشکیل می‌دهند.

حالا تصور کنید این فرد از تیم جدا شود.

فایل‌ها همچنان وجود دارند، Componentها همچنان قابل استفاده هستند و Documentation همچنان در دسترس است؛ اما بخشی از دلیل و منطق پشت تصمیم‌ها از بین رفته است.

اینجا یک سؤال مهم مطرح می‌شود:

اگر فردا مهم‌ترین فرد تیم Design System شما شرکت را ترک کند، چه مقدار از دانش واقعی سیستم باقی خواهد ماند؟

این مسئله همان چیزی است که در مهندسی نرم‌افزار با مفهوم Bus Factor شناخته می‌شود؛ یعنی یک سیستم تا چه اندازه به دانش و حضور یک یا چند فرد خاص وابسته است.

Design System فقط مجموعه‌ای از Componentها نیست

یکی از اشتباه‌های رایج این است که Design System را فقط با خروجی‌های نهایی آن تعریف کنیم.

داشتن یک Library مرتب در Figma، یک Documentation کامل یا یک Package قابل استفاده در Codebase، بخش مهمی از یک Design System هستند، اما تمام آن را تشکیل نمی‌دهند.

یک Design System در واقع مجموعه‌ای از تصمیم‌های طراحی است.

برای مثال، ممکن است در Documentation نوشته شده باشد که یک Button سه Variant دارد، اما مشخص نباشد چرا Variant چهارم ساخته نشده است.

ممکن است مشخص باشد که یک Component وجود دارد، اما توضیحی درباره اینکه چرا Component مشابه دیگری عمداً حذف شده، وجود نداشته باشد.

ممکن است مقدار یک Token مشخص باشد، اما کسی نداند چه مشکلی باعث شد این Token به وجود بیاید.

در نتیجه، فایل‌ها معمولاً نتیجه تصمیم‌ها را نشان می‌دهند، اما همیشه منطق پشت آن تصمیم‌ها را منتقل نمی‌کنند.

بزرگ‌ترین خطر، از دست رفتن دانش پنهان است

در طول زمان، هر Design System مجموعه‌ای از تجربه‌های حل مسئله را جمع می‌کند.

گاهی یک تیم بعد از چندین جلسه تصمیم می‌گیرد که یک Pattern خاص مناسب نیست. گاهی بعد از چند Migration مشخص می‌شود که یک Component بیش از حد پیچیده شده است. گاهی هم تیم متوجه می‌شود یک نیاز فقط مربوط به یک محصول خاص است و نباید وارد Core Design System شود.

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

اما مشکل اینجاست که بسیاری از این تصمیم‌ها فقط در ذهن افراد باقی می‌مانند.

وقتی فردی که این تجربه‌ها را دارد تیم را ترک می‌کند، سازمان فقط یک نیروی متخصص را از دست نمی‌دهد؛ بخشی از حافظه Design System را هم از دست می‌دهد.

Documentation همیشه این مشکل را حل نمی‌کند

اولین راه‌حلی که بسیاری از تیم‌ها پیشنهاد می‌کنند، بهتر کردن Documentation است.

اما مشکل اینجاست که بیشتر Documentationها فقط توضیح می‌دهند چه چیزی وجود دارد، نه اینکه چرا وجود دارد.

برای مثال، یک Documentation معمولی ممکن است بنویسد:

Primary Button برای Action اصلی استفاده می‌شود.

اما یک Documentation بهتر توضیح می‌دهد:

Primary Button برای Actionهایی استفاده می‌شود که کاربر را به مرحله بعدی یک Flow هدایت می‌کنند. استفاده هم‌زمان از چند Primary Button در یک صفحه باعث کاهش Hierarchy بصری و سخت‌تر شدن تصمیم‌گیری کاربر می‌شود.

تفاوت این دو در جزئیات نیست؛ تفاوت در انتقال مدل ذهنی است.

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

یک Design System سالم نباید به یک فرد وابسته باشد

وجود افراد باتجربه در تیم Design System بسیار ارزشمند است. تصمیم‌های پیچیده همیشه به قضاوت انسانی نیاز دارند و تجربه افراد نقش مهمی در کیفیت سیستم دارد.

اما یک سیستم بالغ نباید طوری ساخته شود که تمام تصمیم‌های مهم فقط در ذهن یک نفر وجود داشته باشد.

برای کاهش این وابستگی، چند اقدام مهم وجود دارد.

اول اینکه تصمیم‌های مهم باید ثبت شوند، نه فقط نتیجه آن‌ها.

برای مثال، به جای اینکه فقط نوشته شود:

این Component Deprecated شده است.

بهتر است توضیح داده شود:

این Component Deprecated شد، زیرا API آن بیش از حد پیچیده شده بود و تیم‌های مصرف‌کننده برای استفاده از آن مجبور به ساخت راه‌حل‌های موقت شده بودند.

دوم اینکه تاریخچه تصمیم‌ها باید حفظ شود.

گاهی دانستن اینکه چرا یک تصمیم گرفته شده، از خود تصمیم مهم‌تر است. اگر یک تیم جدید بداند چرا یک Token ساخته شده یا چرا یک Pattern رد شده است، احتمال اینکه همان بحث‌ها را دوباره تکرار کند کمتر می‌شود.

سوم اینکه دانش سیستم باید بین افراد مختلف توزیع شود.

اگر تمام تصمیم‌های Design System فقط توسط یک نفر گرفته شوند، آن فرد به مرور تبدیل به یک Dependency انسانی برای سیستم می‌شود.

Design System بالغ، حافظه سازمانی ایجاد می‌کند

یکی از نشانه‌های بلوغ یک Design System این نیست که فقط Componentهای بیشتری دارد یا Documentation بیشتری تولید کرده است.

یک سیستم بالغ باید بتواند دانش خود را در طول زمان حفظ کند.

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

اگر برای هر تصمیم مهم فقط یک نفر وجود دارد که دلیل آن را می‌داند، احتمالاً بخشی از سیستم هنوز خارج از خود Design System قرار دارد.

این مسئله با ورود AI اهمیت بیشتری پیدا می‌کند

با ورود AI به فرآیند طراحی و توسعه، اهمیت ثبت تصمیم‌ها بیشتر هم می‌شود.

AI می‌تواند Component تولید کند، Code بنویسد و Documentation را تحلیل کند، اما اگر فقط خروجی‌های نهایی را ببیند، دلیل پشت آن‌ها را متوجه نمی‌شود.

سیستمی که فقط Component دارد، به AI می‌گوید چه چیزی بسازد.

اما سیستمی که تصمیم‌ها، محدودیت‌ها و منطق پشت آن‌ها را هم ثبت کرده است، به AI کمک می‌کند بفهمد چرا باید یک تصمیم مشخص گرفته شود.

جمع‌بندی

یک Design System فقط زمانی می‌تواند در مقیاس بزرگ رشد کند که دانش آن از ذهن افراد خارج شود و به بخشی از خود سیستم تبدیل شود.

Componentها، Tokenها و Documentation بخش‌های ضروری یک Design System هستند، اما ارزش اصلی سیستم در تصمیم‌هایی است که پشت این موارد قرار دارند.

سؤال مهم برای یک تیم Design System این نیست:

اگر فرد اصلی سیستم فردا از تیم خارج شود، چه فایل‌هایی باقی می‌ماند؟

سؤال مهم‌تر این است:

چه مقدار از منطق، تجربه و دلیل پشت این فایل‌ها هنوز باقی می‌ماند؟

زیرا یک Design System بالغ فقط نباید قابل استفاده باشد؛ باید بتواند دانش خود را حفظ کند، منتقل کند و بدون وابستگی به افراد خاص به رشد ادامه دهد.