مشارکت در Design System فقط ساختن نیست

وقتی درباره Contribution در Design System صحبت می‌کنیم، معمولاً یک خروجی مشخص در ذهن داریم: یک تیم Component جدیدی طراحی کرده، Developer کد آن را نوشته و حالا قرار است بعد از Review وارد Library شود. حتی بسیاری از Contribution Guidelineها هم حول همین مسیر شکل گرفته‌اند؛ Proposal بده، Design آماده کن، Test بنویس، Documentation را تکمیل کن و در نهایت تغییر را Merge کن.

اما این مدل یک مشکل دارد: Contribution را با Solution شروع می‌کند، درحالی‌که Design System قبل از Solution به Evidence نیاز دارد.

فرض کنید یکی از تیم‌های محصول درخواست اضافه شدن Variant جدیدی به Table را مطرح می‌کند. تیم دیگری گزارش می‌دهد که در سه محصول مختلف، کاربران برای انجام یک Task مشابه با ساختار فعلی Table مشکل دارند و Designerها هم برای حل آن مرتب Component را Override می‌کنند.

تیم اول یک Solution آورده و تیم دوم هنوز چیزی طراحی نکرده است. بااین‌حال، برای تیم Design System ممکن است Contribution دوم ارزشمندتر باشد، چون قبل از اینکه درباره راه‌حل تصمیم بگیریم، اطلاعات بیشتری درباره وجود و دامنه مسئله داریم.

شاید لازم باشد تعریفمان از Contribution را از همین‌جا تغییر دهیم.

چرا Contribution می‌تواند قبل از Solution شروع شود

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

هر Contribution می‌تواند بخشی از این عدم قطعیت را کم کند.

گزارش یک مشکل، اولین Signal را ایجاد می‌کند. اضافه شدن Context مشخص می‌کند مشکل در چه شرایطی اتفاق افتاده است. Evidence از چند محصول نشان می‌دهد مسئله احتمالاً Local نیست. یک Prototype می‌تواند فرضیه‌ای درباره Solution را آزمایش کند و Implementation واقعی هم نشان می‌دهد راه‌حل در شرایط Production چطور رفتار می‌کند.

اگر از این زاویه نگاه کنیم، ارزش Contribution فقط به اندازه چیزی که ساخته شده بستگی ندارد؛ به این بستگی دارد که چقدر به Design System کمک می‌کند تصمیم مطمئن‌تری بگیرد.

اینجا Contribution Ladder معنا پیدا می‌کند

به‌جای دو حالت «Contributor هست / Contributor نیست»، می‌توانیم مشارکت را در چند سطح ببینیم.

در پایین‌ترین سطح، یک نفر فقط Signal وارد سیستم می‌کند: مثلاً گزارش می‌دهد یک Component در Use Case مشخصی جواب نمی‌دهد.

در مرحله بعد، Signal با Context همراه می‌شود: مشکل برای چه کاربری، در چه Flowی و تحت چه محدودیتی اتفاق افتاده است؟

یک مرحله بالاتر، Evidence داریم: همان مسئله در چند تیم دیده شده، Research آن را تأیید کرده یا داده‌های Usage نشانه مشابهی نشان می‌دهند.

بعد از آن می‌توان وارد Solution Exploration شد و چند راه‌حل را بررسی کرد. تازه در مراحل بعدی ممکن است Contribution به Design، Code، Test و Documentation برسد.

این همان چیزی است که می‌توانیم Contribution Ladder بنامیم.

نکته مهم Ladder این نیست که همه باید از پله اول تا آخر بروند. اتفاقاً ارزش مدل در این است که Contribution می‌تواند در هر مرحله متوقف شود و همچنان مفید باشد.

ممکن است یک Product Designer فقط Evidence بسیار خوبی از مسئله ارائه کند و تیم Design System Solution را بسازد. در مسئله دیگری ممکن است Developer علاوه بر پیدا کردن Gap، Implementation پیشنهادی را هم ارائه دهد. هر دو Contribution هستند، فقط نوع چیزی که به تصمیم سیستم اضافه کرده‌اند متفاوت است.

چرا شروع Contribution از Solution می‌تواند خطرناک باشد؟

فرض کنید یک تیم برای نیاز خودش Component جدیدی ساخته و بعد از چند Sprint درخواست می‌دهد آن را وارد Design System کنیم.

در این نقطه اتفاق مهمی افتاده است: تیم قبلاً روی یک Solution سرمایه‌گذاری کرده.

طراحی انجام شده، Development برای آن زمان گذاشته و احتمالاً در Production هم استفاده شده است. بنابراین گفتگو دیگر کاملاً درباره این نیست که «بهترین راه‌حل برای سیستم چیست؟»؛ بخشی از گفتگو ناخواسته تبدیل می‌شود به «آیا چیزی که ساخته‌ایم پذیرفته می‌شود؟»

هرچه Contribution دیرتر وارد Design System شود، هزینه کنار گذاشتن Solution موجود بیشتر می‌شود.

به همین دلیل شاید یکی از مشکلات بعضی Contribution Modelها این باشد که مشارکت را بیش از حد دیر شروع می‌کنند. تیم Design System زمانی وارد گفتگو می‌شود که Solution تقریباً نهایی شده، درحالی‌که نقطه مناسب‌تر می‌توانست زمانی باشد که تیم محصول تازه متوجه یک مسئله تکرارشونده شده است.

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

یک Contribution Ladder یک کاربرد دیگر هم دارد: Friction نباید برای همه یکسان باشد

اگر فردی یک Accessibility Issue پیدا کرده، منطقی نیست برای ثبت آن همان فرآیندی را طی کند که برای پیشنهاد یک Component جدید لازم است. به همان شکل، تغییر Architecture یک Component نباید به‌اندازه اصلاح یک مثال اشتباه در Documentation ساده باشد.

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

Ladder اجازه می‌دهد Friction را براساس Impact تصمیم تنظیم کنیم.

ثبت Signal باید بسیار ساده باشد. اضافه کردن Evidence کمی ساختار بیشتری نیاز دارد. پیشنهاد تغییر در Pattern باید Review دقیق‌تری داشته باشد و تغییر Foundation یا API مشترک طبیعتاً Evidence، Review و هماهنگی بیشتری می‌خواهد.

در این مدل، هدف «ساده کردن همه Contributionها» نیست؛ هدف این است که هزینه مشارکت با ریسک تصمیم متناسب باشد.

یک Contribution خوب الزاماً چیزی به Library اضافه نمی‌کند

این شاید بخش مهم‌تر ماجرا باشد.

فرض کنید سه تیم گزارش می‌دهند برای یک مسئله مشابه به Component جدیدی نیاز دارند. تیم Design System مسئله را بررسی می‌کند و متوجه می‌شود Component موجود قابلیت لازم را دارد، اما Documentation آن باعث شده تیم‌ها نتوانند آن قابلیت را پیدا کنند.

نتیجه Contribution چیست؟

هیچ Component جدیدی ساخته نشده، اما یک Gap واقعی شناسایی و برطرف شده است.

در مثال دیگری ممکن است بررسی Evidence نشان دهد مسئله فقط در یک Product وجود دارد و بهتر است همان‌جا Local باقی بماند. این هم می‌تواند نتیجه موفق Contribution باشد، چون از اضافه شدن Abstraction غیرضروری به Core جلوگیری کرده است.

بنابراین شاید معیار موفقیت Contribution نباید تعداد Componentها یا PRهای Mergeشده باشد.

گاهی بهترین نتیجه یک Contribution این است که چیزی وارد Design System نشود، اما تصمیم بهتری گرفته شود.

Article content

شاید لازم باشد Contribution را با سؤال دیگری بسنجیم

به‌جای اینکه بپرسیم «این تیم چه چیزی به Design System اضافه کرده؟»، می‌توانیم بپرسیم:

بعد از این Contribution، چه چیزی را درباره مسئله می‌دانیم که قبل از آن نمی‌دانستیم؟

اگر پاسخ این باشد که فهمیده‌ایم مسئله در چهار محصول تکرار می‌شود، Contribution اتفاق افتاده است. اگر متوجه شده‌ایم Pattern فعلی در Context مشخصی جواب نمی‌دهد، Contribution اتفاق افتاده است. اگر یک Experiment نشان داده Solution پیشنهادی مقیاس‌پذیر نیست، حتی همان نتیجه منفی هم می‌تواند جلوی یک تصمیم پرهزینه را بگیرد.

با این تعریف، Contribution از «تحویل Asset به تیم Design System» به افزایش کیفیت تصمیم‌های سیستم تبدیل می‌شود.

جمع‌بندی

شاید یکی از محدودیت‌های مدل‌های رایج Contribution این باشد که مشارکت را خیلی دیر و خیلی نزدیک به Solution تعریف می‌کنند. از تیم محصول انتظار داریم چیزی طراحی یا پیاده‌سازی کند و بعد آن را برای ورود به سیستم پیشنهاد دهد، درحالی‌که بخش مهمی از ارزش تیم‌های محصول می‌تواند خیلی قبل‌تر وارد Design System شود.

یک Signal می‌تواند شروع Contribution باشد، Context آن را قابل بررسی می‌کند، Evidence عدم قطعیت را کاهش می‌دهد و بعد، اگر واقعاً نیاز باشد، Solution ساخته می‌شود.

این همان تغییری است که Contribution Ladder ایجاد می‌کند: به‌جای اینکه بپرسیم چه کسی چیزی برای Design System ساخته، بررسی می‌کنیم هر تیم در کدام مرحله می‌تواند به بهتر شدن یک تصمیم کمک کند.

و شاید مهم‌ترین نتیجه این نگاه این باشد که Contribution موفق همیشه چیزی به Design System اضافه نمی‌کند؛ گاهی کمک می‌کند چیزی را که نباید بسازیم، نسازیم.