اگر تیم Design System یک ماه نباشه، چی می‌شه؟

فرض کنید تیم Design System برای یک ماه در دسترس نباشد.در این مدت تیم‌های محصول همچنان باید تصمیم بگیرند: برای این سناریو از کدام Pattern استفاده کنیم؟ آیا می‌توانیم این Component را تغییر دهیم؟ این نیاز باید وارد Core شود یا در سطح Product باقی بماند؟ اگر Pattern موجود جواب نمی‌دهد، تا کجا اجازه داریم راه‌حل متفاوتی بسازیم؟حالا سؤال مهم این است:چند درصد از این تصمیم‌ها بدون حضور تیم Design System همچنان قابل گرفتن هستند؟اگر تقریباً برای هر سؤال نیاز باشد یکی از اعضای تیم مرکزی وارد گفتگو شود، Context را بررسی کند و تصمیم نهایی را توضیح دهد، احتمالاً Design System ما یک وابستگی پنهان دارد؛ بخشی از سیستم هنوز داخل Documentation، Components یا Governance قرار نگرفته و در ذهن Maintainerها باقی مانده است.این مسئله وقتی جدی‌تر می‌شود که سیستم Scale می‌کند.

آیا Design System می‌تواند بدون تیم Design System کار کند؟

مشکل Scale همیشه تعداد Componentها نیست

فرض کنید یک Design System ابتدا توسط ۵ تیم محصول استفاده می‌شود. تیم مرکزی آن‌ها را می‌شناسد، در جریان پروژه‌هایشان قرار دارد و حتی Context بسیاری از تصمیم‌های محصول را می‌داند.در چنین مقیاسی، یک Slack Channel فعال یا چند جلسه Critique می‌تواند بسیاری از ابهام‌ها را حل کند.حالا تعداد مصرف‌کنندگان از ۵ تیم به ۳۰ تیم رسیده است.اگر با شش برابر شدن تعداد تیم‌ها، تعداد سؤال‌ها، Reviewها، Approvalها و جلسه‌هایی که نیاز به حضور تیم Design System دارند هم تقریباً شش برابر شود، سیستم از نظر Adoption رشد کرده، اما الزاماً Scalable نشده است.حتی Atlassian در مدل پشتیبانی Design System خودش به مسئله Bottleneck اشاره می‌کند. تیم آن‌ها ابتدا کاربران را به Guidance موجود هدایت می‌کند و برای موارد دیگر کانال سؤال و Critique دارد؛ در عین حال صراحتاً می‌گوید هدف این است که تیم Design System به Bottleneck تبدیل نشود. [1]این موضوع ما را به تعریف متفاوتی از Scalability می‌رساند:یک Design System زمانی بهتر Scale می‌کند که رشد تعداد مصرف‌کنندگان، به همان نسبت نیاز به تصمیم‌گیری مرکزی را افزایش ندهد.

شاید دو نوع Scalability داشته باشیم

وقتی درباره Scalability صحبت می‌کنیم، معمولاً بخش فنی آن بیشتر دیده می‌شود.آیا Token Architecture می‌تواند چند Brand را پشتیبانی کند؟ آیا Component API برای Use Caseهای مختلف مناسب است؟ آیا Packageها می‌توانند در محصولات بیشتری استفاده شوند؟ آیا Infrastructure انتشار و Versioning جوابگوی Scale جدید است؟می‌توانیم این بخش را Technical Scalability بنامیم.اما لایه دیگری هم وجود دارد که کمتر دیده می‌شود: Decision Scalability.یعنی وقتی تعداد تیم‌ها افزایش پیدا می‌کند، آیا آن‌ها می‌توانند بدون وابستگی دائمی به تیم مرکزی، تصمیم‌هایی بگیرند که همچنان با اصول سیستم سازگار باشند؟این تفاوت مهم است.ممکن است Component Library ما از نظر فنی در ۵۰ محصول بدون مشکل اجرا شود، اما اگر Designerهای همان ۵۰ محصول برای انتخاب Pattern مناسب دائماً به تیم Design System پیام بدهند، Architecture فنی Scale کرده اما Architecture تصمیم‌گیری Scale نکرده است.

بخشی از Scalability یعنی انتقال Knowledge از افراد به سیستم

فرض کنید یک Designer می‌پرسد:«برای این Flow بهتره Modal استفاده کنم یا Drawer؟»اگر تنها راه رسیدن به پاسخ این باشد که یکی از Senior Designerهای تیم Design System Context را بررسی کند و براساس تجربه‌اش جواب بدهد، دانش وجود دارد؛ اما هنوز در سیستم توزیع نشده است.حالا فرض کنید Documentation به‌جای معرفی صرف Modal و Drawer، توضیح دهد هرکدام برای چه نوع Taskهایی مناسب‌اند، چه Trade-offهایی دارند، در چه Contextهایی نباید استفاده شوند و چه سؤال‌هایی باید قبل از انتخابشان پرسیده شود.در حالت دوم، جواب مشخصی را به تیم محصول نداده‌ایم؛ منطق رسیدن به جواب را منتقل کرده‌ایم.این تفاوت برای Scalability مهم است.مدل بلوغ USWDS هم Design System را فقط Code و Component نمی‌بیند. این مدل از Principles شروع می‌شود، بعد Guidance را قرار می‌دهد و در نهایت به Code می‌رسد. خود USWDS توضیح می‌دهد که Principles باید به‌عنوان یک Lens برای ارزیابی تصمیم‌های طراحی و پیاده‌سازی عمل کنند. [2]این یعنی بخشی از ارزش سیستم در این نیست که برای هر مسئله Solution آماده داشته باشد؛ بلکه در این است که تیم‌ها بتوانند با استفاده از Principles و Guidance تصمیم‌های جدید بگیرند.شاید یکی از نشانه‌های Scalability همین باشد:Knowledge باید سریع‌تر از Headcount تکثیر شود.

اما Documentation به‌تنهایی مسئله را حل نمی‌کند

اینجا ممکن است نتیجه بگیریم که کافی است همه‌چیز را Document کنیم.اما این هم راه‌حل کاملی نیست.اگر برای هر سؤال یک صفحه Documentation جدید بسازیم، خیلی زود مشکل جدیدی ایجاد می‌شود: تیم‌ها باید صدها Rule، Guideline و Exception را بخوانند تا بتوانند یک تصمیم ساده بگیرند.پس هدف انتقال تمام دانش تیم Design System به Documentation نیست.هدف این است که مشخص کنیم چه نوع دانشی باید در سیستم Encode شود و چه تصمیم‌هایی همچنان نیاز به قضاوت انسانی دارند.مثلاً یک Rule پرتکرار که ده‌ها تیم هر هفته درباره آن سؤال می‌کنند، احتمالاً نباید فقط در ذهن Maintainer باقی بماند. اما یک Edge Case بسیار خاص که به Context یک محصول وابسته است، شاید اصلاً نیازی به تبدیل شدن به Guideline سراسری نداشته باشد.اینجا Scalability به معنی «Documentation بیشتر» نیست؛ به معنی کاهش وابستگی غیرضروری به دانش متمرکز است.

یک سؤال مهم: تیم Design System کجا واقعاً باید وارد شود؟

برای بررسی این مسئله می‌توانیم تصمیم‌ها را روی یک طیف قرار دهیم.در یک سمت، تصمیم‌هایی هستند که سیستم باید تقریباً به‌تنهایی پاسخ آن‌ها را بدهد. استفاده پایه از Component، Accessibility Requirements، Token Usage، Patternهای تثبیت‌شده و بسیاری از مسائل تکرارشونده نباید هر بار نیازمند جلسه با تیم مرکزی باشند.در سمت دیگر، تصمیم‌هایی قرار دارند که اثرشان می‌تواند کل سیستم را تغییر دهد؛ مثلاً تغییر API یک Component پرمصرف، اضافه‌کردن Foundation جدید یا تغییر Patternی که محصولات زیادی به آن وابسته‌اند.اینجا حضور تیم Design System همچنان ارزشمند و حتی ضروری است.مدل Contribution در Atlassian نمونه خوبی از همین تفاوت Impact است. Fixهای کوچک و Enhancementهای محدود قابل Contribution هستند، اما تغییرات بزرگ‌تر نیازمند بررسی System-wide هستند، چون می‌توانند روی Applicationهای مختلف، Brandها، API و Guidance اثر بگذارند. [3]پس هدف Scalability حذف تیم مرکزی از تصمیم‌گیری نیست.هدف این است که تیم مرکزی فقط جایی وارد تصمیم شود که ارزش تصمیم واقعاً به Context یا نگاه System-level آن نیاز دارد.

یک Stress Test ساده برای Scalability

می‌توانیم برای بررسی Design System یک آزمایش ذهنی انجام دهیم:اگر تیم Design System یک ماه در دسترس نباشد، چه چیزهایی متوقف می‌شوند؟نه به این دلیل که واقعاً بخواهیم تیم را حذف کنیم؛ بلکه برای پیدا کردن Dependencyهای پنهان.مثلاً:اگر تیم‌ها نتوانند Component مناسب را پیدا کنند، شاید Discoverability مشکل دارد.اگر Component را پیدا می‌کنند اما نمی‌دانند چه زمانی باید از آن استفاده کنند، شاید Guidance ناقص است.اگر درباره Exceptionها دائماً نیاز به Approval دارند، شاید Decision Rights مشخص نیست.اگر نمی‌دانند نیاز جدید را چطور مطرح کنند، Contribution Model واضح نیست.اگر فقط یک نفر می‌داند چرا بعضی Ruleها وجود دارند، Institutional Knowledge هنوز به سیستم منتقل نشده است.USWDS یکی از مزایای Design System را دقیقاً ایجاد Institutional Memory می‌داند؛ یعنی تجربه و بهبودهای تیم‌های مختلف باید بتوانند به چیزی تبدیل شوند که تیم‌های بعدی هم از آن استفاده کنند. [4]بنابراین این Stress Test درواقع نمی‌پرسد «آیا تیم Design System اضافه است؟»می‌پرسد:چه چیزهایی هنوز فقط به‌خاطر حضور افراد مشخص کار می‌کنند؟

Scalability را شاید بتوان از روی Coordination Cost دید

از اینجا می‌توانیم یک Lens دیگر برای بررسی Scale تعریف کنیم.فرض کنید تعداد تیم‌های مصرف‌کننده در یک سال دو برابر شده است. حالا چند شاخص دیگر را هم بررسی کنیم:تعداد سؤال‌هایی که نیازمند پاسخ مستقیم تیم Design System هستند چقدر رشد کرده؟ تعداد Reviewها چطور؟ تعداد Approvalها؟ جلسه‌های Alignment؟ درخواست‌هایی که فقط یک Maintainer خاص قادر به پاسخ‌گویی به آن‌هاست؟اگر تمام این موارد تقریباً با همان نرخ تعداد مصرف‌کنندگان رشد کنند، ممکن است با یک Coordination Scaling Problem مواجه باشیم.برای این مقاله می‌توانیم آن را به‌صورت یک رابطه مفهومی ببینیم:Consumer Growth ↔ Coordination Growthهدف این نیست که Coordination را به صفر برسانیم. ارتباط با تیم‌های محصول برای Research، Feedback و Evolution خود سیستم ضروری است. حتی سیستم‌هایی مثل USWDS مشارکت Community را بخشی از رشد سیستم می‌دانند و از تیم‌ها می‌خواهند Research، Guidance، Issues و Components را دوباره به سیستم برگردانند. [2][5]مسئله این است که Coordination نباید برای انجام هر تصمیم روزمره ضروری باشد.تفاوت بزرگی وجود دارد بین تیم محصولی که برای Feedback دادن به سیستم با تیم مرکزی صحبت می‌کند و تیم محصولی که برای استفاده روزمره از سیستم بدون تیم مرکزی قادر به تصمیم‌گیری نیست.اولی نشانه یک Community فعال است.دومی می‌تواند نشانه یک Dependency باشد.

شاید هدف نهایی حذف تیم Design System نباشد

اگر یک Design System بسیار Scalable شود، همچنان به افرادی نیاز دارد که آن را نگهداری کنند، Research انجام دهند، تغییرات را ارزیابی کنند، Foundations را تکامل دهند و جهت سیستم را حفظ کنند.حتی USWDS هم تأکید می‌کند که Design System جایگزین مهارت‌های تخصصی Designer و Engineer نیست؛ هدف این است که با فراهم کردن Foundations و Guidance، این افراد زمان بیشتری برای حل مسائل خاص کاربران داشته باشند. [6]پس سؤال «آیا Design System می‌تواند بدون تیم Design System کار کند؟» عمداً کمی افراطی است.سؤال دقیق‌تر شاید این باشد:Design System برای چه چیزهایی نباید به تیم Design System وابسته باشد؟اگر تیم مرکزی بیشتر زمانش را صرف پاسخ دادن به سؤال‌هایی کند که قبلاً پاسخ داده شده‌اند، Approve کردن تصمیم‌های کم‌ریسک یا توضیح شفاهی Ruleهایی کند که می‌توانستند در سیستم Encode شوند، بخش بزرگی از ظرفیت آن صرف اجرای خود سیستم می‌شود.اما اگر تیم‌های محصول بتوانند مسائل روزمره را مستقل حل کنند، نقش تیم Design System تغییر می‌کند: به‌جای پاسخ دادن به هر تصمیم، می‌تواند روی بهبود قواعدی کار کند که تصمیم‌های آینده را ممکن می‌کنند.شاید یکی از نشانه‌های واقعی Scalability همین باشد:با بزرگ‌تر شدن Design System، تعداد تصمیم‌هایی که تیم مرکزی باید خودش بگیرد با همان سرعت بزرگ نشود.و شاید بهترین Stress Test برای فهمیدن این موضوع همچنان همان سؤال اول باشد:اگر فردا تیم Design System برای یک ماه در دسترس نباشد، کدام بخش سیستم از کار می‌افتد و چرا؟پاسخ به این سؤال می‌تواند دقیق‌تر از تعداد Componentها یا تعداد محصولاتی که Library را نصب کرده‌اند نشان دهد Design System ما واقعاً تا چه اندازه Scale کرده است.

منابع