تیم‌ها واقعاً Design System شما رو پذیرفتن؟

وقتی درباره Adoption در Design System صحبت می‌کنیم، معمولاً اولین چیزی که سراغش می‌رویم عددهاست: چند درصد تیم‌ها از Library استفاده می‌کنند؟ چند Component در محصولات استفاده شده؟ چند تیم Package را نصب کرده‌اند؟

این عددها مهم‌اند، اما یک سؤال قبل از همه آن‌ها وجود دارد: اصلاً چه اتفاقی می‌افتد که یک Designer یا Developer تصمیم می‌گیرد Design System را وارد روش کار روزمره خودش کند؟

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

به همین دلیل، Adoption را بهتر است نه یک اتفاق، بلکه یک مسیر ببینیم؛ مسیری که از شناخت سیستم شروع می‌شود و در بهترین حالت به جایی می‌رسد که تیم‌ها نه‌تنها از سیستم استفاده می‌کنند، بلکه خودشان در رشد آن نقش دارند.

مرحله اول: تیم باید بداند راه‌حلی وجود دارد

اولین مرحله ساده به نظر می‌رسد، اما یکی از مشکلات رایج همین‌جاست. تیم محصول با مسئله‌ای روبه‌رو می‌شود، اما نمی‌داند Design System برای آن راه‌حلی دارد.

فرض کنید Designer برای یک Filter پیچیده طراحی می‌کند. اگر نداند Pattern مشابهی در سیستم وجود دارد، احتمالاً خودش چیزی می‌سازد. چند هفته بعد تیم Design System متوجه می‌شود یک Component موازی ایجاد شده و نتیجه می‌گیرد تیم محصول سیستم را رعایت نکرده است.

درحالی‌که مشکل ممکن است اصلاً مخالفت با Design System نباشد؛ مشکل Discoverability بوده است.

بنابراین Adoption قبل از Usage شروع می‌شود. تیم باید بتواند سریع بفهمد چه چیزی در سیستم وجود دارد، برای چه مسئله‌ای ساخته شده و کجا می‌تواند آن را پیدا کند.

مرحله دوم: تیم باید بتواند سیستم را بدون هزینه زیاد امتحان کند

شناختن Component کافی نیست. مرحله بعد زمانی است که Designer یا Developer برای اولین بار تصمیم می‌گیرد واقعاً از آن استفاده کند.

اینجا اصطکاک‌های کوچک اهمیت زیادی پیدا می‌کنند.

اگر Designer برای فهمیدن ساختار Component مجبور باشد چند صفحه Documentation بخواند، اگر Developer برای نصب Package با Dependencyهای پیچیده مواجه شود یا اگر برای یک تغییر کوچک نیاز به هماهنگی با تیم Design System داشته باشد، تجربه اولیه خوبی شکل نمی‌گیرد.

در مقابل، وقتی Component به‌راحتی پیدا می‌شود، مثال واقعی دارد، محدودیت‌هایش مشخص است و نسخه Design و Code رفتار مشابهی دارند، هزینه امتحان کردن سیستم پایین می‌آید.

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

مرحله سوم: استفاده باید به اعتماد تبدیل شود

به نظرم این بخش یکی از مهم‌ترین قسمت‌های Adoption است که کمتر درباره آن صحبت می‌شود.

ممکن است یک تیم چند بار از Design System استفاده کند، اما هنوز به آن اعتماد نداشته باشد.

فرض کنید Developer یک Component را در پروژه استفاده می‌کند، اما بعد متوجه می‌شود بعضی Stateها پیاده‌سازی نشده‌اند. بار دیگر نسخه جدیدی منتشر می‌شود و یک Breaking Change بدون Migration Guide اتفاق می‌افتد. دفعه بعد Documentation با رفتار واقعی Component هماهنگ نیست.

بعد از چند تجربه مشابه، اتفاق مهمی می‌افتد. دفعه بعد که Developer با مسئله جدیدی روبه‌رو شود، احتمالاً قبل از مراجعه به Design System با خودش می‌گوید: «خودم بسازم سریع‌تره.»

اینجا مسئله دیگر کیفیت یک Component نیست؛ اعتماد به خود سیستم آسیب دیده است.

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

به همین دلیل، Adoption فقط یک مسئله طراحی نیست؛ مسئله Reliability هم هست.

مرحله چهارم: Design System باید تبدیل به انتخاب پیش‌فرض شود

وقتی اعتماد شکل گرفت، رفتار تیم کم‌کم تغییر می‌کند.

در مراحل اولیه، Designer ممکن است ابتدا خودش مسئله را حل کند و بعد بررسی کند آیا Component مشابهی در Design System وجود دارد یا نه. اما در یک سیستم با Adoption بالا، ترتیب برعکس می‌شود.

وقتی مسئله جدیدی پیش می‌آید، اولین سؤال این است:

آیا برای این مسئله چیزی در Design System داریم؟

این تغییر کوچک، نشانه مهمی است. Design System دیگر یک Library جانبی نیست که تیم گاهی از آن استفاده کند؛ تبدیل به بخشی از Workflow شده است.

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

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

در سیستم‌های بالغ‌تر، مرحله دیگری هم شکل می‌گیرد: Contribution.

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

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

در چنین شرایطی، تیم Design System هم دیگر تنها سازنده سیستم نیست. نقش آن بیشتر به هدایت، بررسی، استانداردسازی و حفظ کیفیت Contributionها نزدیک می‌شود.

پس Adoption را فقط در انتهای مسیر اندازه نگیریم

اگر Adoption را یک مسیر ببینیم، Metricهای ما هم باید تغییر کنند.

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

این نگاه کمک می‌کند به جای یک عدد کلی مثل «Adoption ما ۷۰ درصد است»، بفهمیم هر تیم دقیقاً در کجای مسیر قرار دارد و چه چیزی مانع رفتن آن به مرحله بعد شده است.

ممکن است یک تیم هنوز سیستم را خوب نشناسد، تیم دیگری آن را بشناسد اما استفاده از آن را سخت بداند و تیم سوم مرتب از آن استفاده کند اما به Releaseهای جدید اعتماد نداشته باشد. هر سه «Adoption پایین» دارند، اما راه‌حل مشکلشان کاملاً متفاوت است.

جمع‌بندی

پذیرش Design System با Publish کردن یک Library شروع نمی‌شود و با شمردن تعداد Instanceها هم تمام نمی‌شود.

تیم ابتدا باید سیستم را پیدا کند، بعد بتواند آن را با اصطکاک کم امتحان کند، در استفاده مداوم به آن اعتماد کند و در نهایت آن را به انتخاب پیش‌فرض خودش برای حل مسائل مشترک تبدیل کند. در مرحله‌ای بالاتر، حتی می‌تواند از مصرف‌کننده سیستم به یکی از مشارکت‌کنندگان آن تبدیل شود.

به همین دلیل، شاید سؤال بهتر برای سنجش Adoption این نباشد که:

چند تیم از Design System ما استفاده می‌کنند؟

بلکه این باشد:

هر تیم در کدام مرحله از پذیرفتن Design System قرار دارد و چه چیزی مانع رفتن آن به مرحله بعد شده است؟

وقتی پاسخ این سؤال را بدانیم، Adoption دیگر فقط یک Metric نیست؛ تبدیل به چیزی می‌شود که می‌توانیم برای بهتر شدنش طراحی کنیم.