اختلاف در Design System چطور حل می‌شه؟

اختلاف در Design System چطور حل می‌شه؟

فرض کنید یکی از تیم‌های محصول برای یک Feature جدید به Variant متفاوتی از یک Component نیاز دارد. درخواست را برای تیم Design System می‌فرستد، اما تیم سیستم معتقد است این نیاز بیش از حد مختص همان محصول است و نباید وارد Core شود.از طرف دیگر، تیم محصول می‌گوید این یک نیاز واقعی است و بدون آن یا باید Component را تغییر دهد، یا نسخه‌ای Local بسازد، یا برای حل مسئله سراغ راه دیگری برود.هر دو طرف هم دلیل قابل‌قبولی دارند.تیم محصول باید مسئله کاربر را حل کند و Feature را به‌موقع تحویل دهد. تیم Design System هم نمی‌تواند برای هر نیاز جدید یک Variant به Core اضافه کند، چون در نهایت با Componentهایی روبه‌رو می‌شود که ده‌ها حالت دارند و استفاده و نگهداری از آن‌ها سخت شده است.حالا سؤال اینجاست:تصمیم نهایی با چه کسی است؟ تیم Design System، تیم محصول، Product Manager یا Engineering؟این دقیقاً یکی از جاهایی است که مفهوم Governance در Design System اهمیت پیدا می‌کند.

Governance فقط مجموعه‌ای از قانون‌ها نیست

وقتی درباره Governance صحبت می‌کنیم، معمولاً چیزهایی مثل نحوه Contribution، فرآیند Review، انتشار نسخه‌های جدید، Ownership و Approval به ذهن می‌رسند.همه این‌ها مهم‌اند، اما پشت آن‌ها یک سؤال اساسی‌تر وجود دارد:چه کسی درباره چه چیزی حق تصمیم‌گیری دارد؟فرض کنید یک تیم Variant جدیدی برای Button می‌خواهد، تیم دیگری Token جدیدی درخواست می‌کند و تیم سوم Pattern متفاوتی برای Filter ساخته است.اگر پاسخ همیشه این باشد که «تیم Design System تصمیم می‌گیرد»، سیستم بیش از حد متمرکز می‌شود. اگر هم هر تیم محصول بتواند براساس نیاز خودش سیستم را تغییر دهد، خیلی زود Design System تبدیل به مجموعه‌ای از تصمیم‌های محلی و پراکنده خواهد شد.بنابراین یک Governance خوب فقط قانون تعیین نمی‌کند؛ مرز تصمیم‌گیری بین تیم‌ها را مشخص می‌کند.

چرا همه تصمیم‌ها نباید دست تیم Design System باشد؟

وقتی تیم محصول و تیم Design System با هم مخالف‌اند، شاید سؤال اصلی نباید این باشد که:«حرف آخر را چه کسی می‌زند؟»سؤال بهتر این است:«این تصمیم در چه سطحی قرار دارد، روی چه کسانی اثر می‌گذارد و چه کسی باید مسئول تصمیم در آن سطح باشد؟»بعضی تصمیم‌ها می‌توانند در اختیار تیم محصول باشند، بعضی نیازمند تصمیم مشترک‌اند و بعضی به دلیل اثر گسترده‌شان باید در سطح Design System بررسی شوند.در کنار آن، معیار تصمیم‌گیری، مسیر Exception، امکان Experiment، سرعت پاسخ و شرایط بازبینی تصمیم هم باید مشخص باشد.در چنین شرایطی، Governance دیگر فقط ابزاری برای کنترل Design System نیست؛ تبدیل می‌شود به چارچوبی برای تصمیم‌گیری مشترک بین تیم‌هایی که نیازها و اولویت‌های متفاوتی دارند.و شاید نشانه یک Governance بالغ این نباشد که تیم‌ها هیچ‌وقت با هم اختلاف ندارند؛ بلکه این باشد که وقتی اختلاف دارند، دقیقاً می‌دانند چطور باید به یک تصمیم برسند.

از طرف دیگر، هر نیاز محصول هم نباید وارد Core شود

حالا مسئله را برعکس ببینیم.اگر هر تیم بتواند هر چیزی را که برای محصول خودش مفید است وارد Design System کند، چه اتفاقی می‌افتد؟یک تیم Variant جدیدی برای Button می‌خواهد. تیم دیگر رفتار متفاوتی برای Modal نیاز دارد. محصول دیگری Pattern مخصوص خودش را برای Filter ساخته و تیم بعدی هم Token جدیدی درخواست می‌کند.هرکدام از این درخواست‌ها به‌تنهایی ممکن است منطقی باشند، اما مجموع آن‌ها می‌تواند سیستم را پیچیده کند.تعداد Variantها بیشتر می‌شود، APIها پیچیده‌تر می‌شوند، Documentation بزرگ‌تر می‌شود، Testing هزینه بیشتری پیدا می‌کند و تیم‌ها برای انتخاب راه‌حل مناسب با گزینه‌های بیشتری روبه‌رو می‌شوند.اینجا یک تفاوت مهم وجود دارد:چیزی که برای یک محصول تصمیم خوبی است، الزاماً برای کل Design System تصمیم خوبی نیست.به همین دلیل، کسی که یک نیاز را تجربه می‌کند لزوماً نباید تنها کسی باشد که درباره تبدیل آن نیاز به یک استاندارد مشترک تصمیم می‌گیرد.

همه تصمیم‌ها در یک سطح نیستند

شاید اصلاً سؤال «چه کسی تصمیم نهایی را می‌گیرد؟» سؤال دقیقی نباشد، چون پاسخ آن به نوع تصمیم بستگی دارد.بعضی تصمیم‌ها فقط روی یک Feature اثر دارند. بعضی بین چند محصول مشترک‌اند و بعضی می‌توانند روی کل Design System اثر بگذارند.هرچه دامنه اثر یک تصمیم بیشتر باشد، تصمیم‌گیری درباره آن هم باید از سطح محصول به سطح سیستم نزدیک‌تر شود.می‌توانیم تصمیم‌ها را تقریباً در سه سطح ببینیم:تصمیم‌های محلی: اگر یک Pattern فقط برای یک Feature یا محصول خاص ساخته شده و روی سایر محصولات اثری ندارد، تیم محصول باید آزادی بیشتری برای تصمیم‌گیری داشته باشد.تصمیم‌های مشترک: اگر یک نیاز در چند محصول تکرار شده یا احتمال استفاده مجدد از آن بالاست، بهتر است تیم محصول و تیم Design System با هم تصمیم بگیرند.تصمیم‌های سراسری: اگر قرار است ساختار Tokenها، API یک Component پرکاربرد، Naming Convention یا یک استاندارد Accessibility تغییر کند، تصمیم روی بخش بزرگی از سیستم اثر می‌گذارد و طبیعتاً تیم Design System باید نقش پررنگ‌تری داشته باشد.در این نگاه، Governance قرار نیست مشخص کند چه کسی قدرت بیشتری دارد؛ قرار است مشخص کند هر تصمیم متعلق به کدام سطح است.

اما براساس چه چیزی تصمیم می‌گیریم؟

برگردیم به همان Variant ابتدای مقاله.تیم محصول می‌گوید به آن نیاز دارد و تیم Design System معتقد است نباید وارد Core شود.اگر معیار مشخصی نداشته باشیم، گفتگو خیلی زود تبدیل می‌شود به «ما بهش نیاز داریم» در مقابل «ما فکر می‌کنیم نباید اضافه بشه».یک Governance خوب باید این اختلاف را به سؤال‌های قابل بررسی تبدیل کند:آیا این نیاز فقط در یک محصول وجود دارد یا تیم‌های دیگری هم آن را تجربه کرده‌اند؟آیا احتمال دارد در آینده محصولات بیشتری به آن نیاز داشته باشند؟آیا Component فعلی واقعاً نمی‌تواند این Use Case را پوشش دهد؟اضافه کردن این Variant چقدر Complexity ایجاد می‌کند؟نگهداری، Testing و Documentation آن چه هزینه‌ای دارد؟اگر وارد Core نشود، تیم محصول چه هزینه‌ای پرداخت می‌کند؟آیا می‌توان راه‌حل را فعلاً به‌صورت Local نگه داشت؟آیا بهتر است ابتدا در یک محصول آزمایش شود و بعد درباره ورودش به Core تصمیم بگیریم؟آیا راه ساده‌تری برای حل همان مسئله وجود دارد؟حالا تصمیم براساس جایگاه افراد گرفته نمی‌شود، بلکه شواهد، دامنه اثر و هزینه تصمیم وارد گفتگو می‌شوند.

هر درخواست فقط دو جواب «قبول» و «رد» ندارد

یکی از اشتباه‌هایی که می‌تواند Governance را بیش از حد سخت کند این است که هر درخواست را دوحالتی ببینیم: یا وارد Design System می‌شود یا رد می‌شود.درحالی‌که گزینه سومی هم وجود دارد:فعلاً خارج از Core بماند.مثلاً تیم محصول Pattern جدیدی ساخته است که هنوز فقط در همان محصول استفاده می‌شود. به‌جای اینکه فوراً آن را وارد Design System کنیم یا کاملاً ردش کنیم، می‌توانیم اجازه بدهیم مدتی به‌صورت Local استفاده شود.اگر بعداً تیم دیگری با همان نیاز روبه‌رو شد، حالا شواهد بیشتری برای بررسی داریم.حتی ممکن است بعد از مدتی بفهمیم Pattern اولیه نیاز به تغییر دارد. در این صورت، آزمایش آن در سطح محصول جلوی اضافه شدن زودهنگام یک راه‌حل ناپخته به Core را گرفته است.بنابراین Governance خوب باید برای Experiment و یادگیری هم فضا داشته باشد.

وجود Exception لزوماً به معنی شکست Governance نیست

گاهی تصور می‌کنیم یک Design System بالغ باید بتواند تمام نیازهای محصولات را پوشش دهد و هیچ تیمی نباید از استانداردها خارج شود.اما محصولات Contextهای متفاوتی دارند.ممکن است یک محصول محدودیت فنی متفاوتی داشته باشد، تیمی در حال آزمایش Interaction جدیدی باشد یا یک Domain به Pattern خاصی نیاز داشته باشد که برای سایر محصولات کاربردی نیست.در چنین شرایطی، داشتن Exception می‌تواند کاملاً منطقی باشد.مسئله اصلی وجود Exception نیست؛ مسئله این است که آیا می‌دانیم چرا ایجاد شده، چه کسی آن را تأیید کرده، کجا استفاده می‌شود و چه زمانی باید دوباره بررسی شود.اگر این اطلاعات وجود نداشته باشد، Exceptionها به‌مرور تبدیل به Debt می‌شوند. اما اگر ثبت و مدیریت شوند، می‌توانند بخشی طبیعی از Governance باشند.

تصمیم امروز ممکن است شش ماه دیگر اشتباه باشد

فرض کنید امروز تیم Design System درخواست یک Pattern جدید را رد می‌کند، چون فقط یک محصول به آن نیاز دارد.شش ماه بعد، تیم دوم همان درخواست را مطرح می‌کند.کمی بعد تیم سوم هم Pattern مشابهی می‌سازد.حالا Context تغییر کرده است.تصمیم اولیه لزوماً اشتباه نبوده؛ براساس اطلاعات همان زمان تصمیم درستی گرفته شده است. اما شواهد جدید می‌توانند باعث شوند تصمیم دوباره بررسی شود.به همین دلیل، بهتر است فقط نتیجه تصمیم را ثبت نکنیم.به‌جای اینکه فقط بنویسیم:«این Pattern وارد Core نمی‌شود.»بهتر است بدانیم چرا وارد نشد، چه گزینه‌های دیگری بررسی شدند و چه شرایطی باعث می‌شود دوباره آن را بررسی کنیم.اینجاست که ثبت Decisionها اهمیت پیدا می‌کند. هدف این نیست که تمام بحث‌های تیم را مستند کنیم؛ هدف این است که چند ماه بعد بدانیم چرا چنین تصمیمی گرفته شده است.

سرعت تصمیم‌گیری هم بخشی از Governance است

حتی بهترین فرآیند تصمیم‌گیری هم اگر بیش از حد کند باشد، خودش تبدیل به مشکل می‌شود.فرض کنید برای اضافه کردن یک تغییر کوچک، تیم محصول مجبور باشد Proposal بنویسد، جلسه برگزار کند، چند Approval بگیرد و دو هفته منتظر پاسخ بماند.از دید Governance شاید فرآیند کاملی داشته باشیم، اما تجربه تیم محصول چیز دیگری است:«استفاده از Design System سرعت ما را کم می‌کند.»اگر این اتفاق مرتب تکرار شود، تیم‌ها کم‌کم راه‌های میان‌بر پیدا می‌کنند.به همین دلیل، همه تغییرات نباید فرآیند یکسانی داشته باشند.یک تغییر کوچک در یک Component نباید همان مسیری را طی کند که تغییر معماری Tokenها طی می‌کند.هرچه دامنه اثر و ریسک تصمیم کمتر باشد، فرآیند تصمیم‌گیری هم می‌تواند سبک‌تر باشد. هرچه تصمیم روی محصولات بیشتری اثر بگذارد و برگشت از آن سخت‌تر باشد، Review عمیق‌تر منطقی‌تر می‌شود.به زبان ساده:وزن Governance باید متناسب با وزن تصمیم باشد.

اختلاف بین تیم‌ها همیشه نشانه بدی نیست

وجود اختلاف بین تیم Design System و تیم محصول الزاماً به معنی مشکل داشتن Governance نیست.این دو تیم اساساً از دو زاویه متفاوت به مسئله نگاه می‌کنند.تیم محصول معمولاً می‌پرسد: چطور مسئله کاربر را حل کنیم؟ چطور Feature را تحویل دهیم؟ چه چیزی برای Context محصول ما بهتر است؟تیم Design System علاوه بر این‌ها باید سؤال‌های دیگری هم مطرح کند: اگر این تصمیم وارد Core شود چه اثری روی محصولات دیگر دارد؟ آیا قابل نگهداری است؟ آیا Complexity سیستم را بالا می‌برد؟ آیا واقعاً Reusable است؟هر دو نگاه لازم‌اند.هدف Governance این نیست که این اختلاف را حذف کند. هدف این است که اختلاف را از یک بحث سلیقه‌ای به یک فرآیند تصمیم‌گیری قابل پیش‌بینی تبدیل کند.

یک Governance خوب چه چیزهایی را روشن می‌کند؟

اگر Governance درست طراحی شده باشد، تیم‌ها نباید برای هر درخواست دوباره از صفر مذاکره کنند.باید از قبل بدانند:درباره چه چیزهایی خودشان می‌توانند تصمیم بگیرند؟چه تغییراتی نیاز به هماهنگی با تیم Design System دارند؟چه کسی مسئول بررسی هر نوع تغییر است؟درخواست‌ها براساس چه معیارهایی بررسی می‌شوند؟حدوداً چه زمانی باید منتظر پاسخ باشند؟اگر با تصمیم موافق نباشند، مسیر بررسی دوباره چیست؟در چه شرایطی می‌توانند Exception داشته باشند؟چه زمانی یک تصمیم قبلی دوباره بررسی می‌شود؟اگر راه‌حلی ساخته‌اند که برای تیم‌های دیگر هم مفید است، چطور می‌توانند آن را Contribute کنند؟اگر پاسخ این سؤال‌ها فقط در ذهن Leadها و اعضای قدیمی تیم باشد، Governance هنوز به یک سیستم واقعی تبدیل نشده است.

یک Governance خوب درباره کنترل بیشتر نیست

گاهی با اضافه کردن Rule، Approval و Process بیشتر احساس می‌کنیم Governance قوی‌تری ساخته‌ایم.اما هدف Governance این نیست که تیم Design System روی تمام تصمیم‌ها کنترل داشته باشد.هدف این است که تیم‌ها بدانند چه کسی درباره چه چیزی تصمیم می‌گیرد، چه معیارهایی برای تصمیم وجود دارد و اگر اختلافی شکل گرفت چطور باید آن را حل کنند.درواقع یک Governance خوب می‌تواند به تیم‌ها استقلال بیشتری بدهد، چون مرزها مشخص‌اند. تیم محصول برای هر تصمیم کوچک منتظر اجازه نمی‌ماند و تیم Design System هم مجبور نیست در تمام جزئیات محصولات دخالت کند.هر تیم می‌داند کجا می‌تواند مستقل حرکت کند و کجا تصمیمش روی سیستم مشترک اثر می‌گذارد.

جمع‌بندی

وقتی تیم محصول و تیم Design System با هم مخالف‌اند، شاید سؤال اصلی نباید این باشد که:«حرف آخر را چه کسی می‌زند؟»سؤال بهتر این است:«این تصمیم در چه سطحی قرار دارد، روی چه کسانی اثر می‌گذارد و چه کسی باید مسئول تصمیم در آن سطح باشد؟»بعضی تصمیم‌ها می‌توانند در اختیار تیم محصول باشند، بعضی نیازمند تصمیم مشترک‌اند و بعضی به دلیل اثر گسترده‌شان باید در سطح Design System بررسی شوند.در کنار آن، معیار تصمیم‌گیری، مسیر Exception، امکان Experiment، سرعت پاسخ و شرایط بازبینی تصمیم هم باید مشخص باشد.در چنین شرایطی، Governance دیگر فقط ابزاری برای کنترل Design System نیست؛ تبدیل می‌شود به چارچوبی برای تصمیم‌گیری مشترک بین تیم‌هایی که نیازها و اولویت‌های متفاوتی دارند.و شاید نشانه یک Governance بالغ این نباشد که تیم‌ها هیچ‌وقت با هم اختلاف ندارند؛ بلکه این باشد که وقتی اختلاف دارند، دقیقاً می‌دانند چطور باید به یک تصمیم برسند.