Design System شما واقعاً چه چیزی را بهتر کرده؟

وقتی می‌خواهیم موفقیت یک Design System را اندازه بگیریم، معمولاً اولین چیزهایی که سراغشان می‌رویم قابل شمارش‌ترین بخش‌های سیستم هستند: چند Component داریم، چند Component مستند شده، چند تیم از Library استفاده می‌کنند، چند بار Package دانلود شده یا چند درصد Designها از Componentهای اصلی ساخته شده‌اند.این داده‌ها مفیدند، اما یک مشکل دارند: بیشتر آن‌ها نشان می‌دهند Design System چقدر استفاده شده یا چقدر خروجی تولید کرده است، نه اینکه چه چیزی را بهتر کرده است.ممکن است تعداد Componentها در یک سال دو برابر شود، Documentation کامل‌تر شود و Adoption به ۸۰ درصد برسد، اما تیم‌ها همچنان برای حل مسائل مشابه دوباره تصمیم بگیرند، Componentهای موجود را Override کنند، Patternهای موازی بسازند یا برای پیدا کردن پاسخ سؤال‌هایشان زمان زیادی صرف کنند.در چنین شرایطی آیا Design System موفق بوده است؟شاید قبل از انتخاب Metric باید سؤال بنیادی‌تری بپرسیم: Design System دقیقاً قرار بوده چه چیزی را تغییر دهد؟

تعداد Component بیشتر، الزاماً نشانه سیستم بهتر نیست

فرض کنید تیم Design System در گزارش سالانه خودش اعلام می‌کند که تعداد Componentها از ۳۵ به ۶۰ رسیده، Documentation Coverage به ۹۰ درصد رسیده و سه Release بزرگ هم منتشر شده است.همه این اعداد می‌توانند نشانه فعالیت جدی تیم باشند، اما هنوز چیزی درباره Impact سیستم به ما نمی‌گویند.حتی ممکن است افزایش تعداد Componentها نتیجه خوبی نباشد. شاید بخشی از آن‌ها نیازهای بسیار Local باشند که وارد Core شده‌اند، چند Component مسئله مشابهی را حل کنند یا Complexity سیستم آن‌قدر افزایش پیدا کرده باشد که انتخاب Component مناسب برای تیم‌ها سخت‌تر شده باشد.همین موضوع درباره Documentation هم وجود دارد. داشتن Documentation بیشتر زمانی ارزشمند است که تیم‌ها بتوانند سریع‌تر جواب سؤال‌هایشان را پیدا کنند و تصمیم بهتری بگیرند. تعداد Pageها به‌تنهایی این موضوع را نشان نمی‌دهد.پس شاید لازم باشد بین دو نوع Measurement تفاوت بگذاریم:Output Metrics به ما می‌گویند Design System چه چیزی تولید کرده است.Outcome Metrics به ما می‌گویند بعد از وجود Design System چه چیزی در نحوه ساخت محصول بهتر شده است.تعداد Component، تعداد Release، تعداد Documentation Page یا تعداد Contribution بیشتر به سمت Output قرار می‌گیرند. در مقابل، کاهش Rework، افزایش سرعت رسیدن از Design به Production، کاهش Accessibility Issueهای تکراری یا کاهش ساخت Solutionهای موازی به Outcome نزدیک‌ترند.مشکل زمانی ایجاد می‌شود که Output را به‌جای Outcome گزارش کنیم.

Adoption مهم است، اما موفقیت نیست

یکی از رایج‌ترین معیارهای Design System، Adoption است. این Metric مهم است، چون سیستمی که کسی از آن استفاده نمی‌کند احتمالاً نمی‌تواند Impact زیادی هم ایجاد کند.اما Adoption بیشتر شبیه یک شرط لازم برای Impact است تا خود Impact.فرض کنید ۹۰ درصد تیم‌ها از Button رسمی Design System استفاده می‌کنند. این عدد به ما می‌گوید Component توزیع شده و وارد محصولات شده است، اما نمی‌گوید استفاده از آن چه تغییری ایجاد کرده است.آیا زمان Development کمتر شده؟ آیا Accessibility Problemهای مربوط به Button کاهش پیدا کرده؟ آیا تیم‌ها کمتر Component موازی ساخته‌اند؟ آیا تجربه Actionهای مشابه در محصولات قابل پیش‌بینی‌تر شده؟ آیا تغییر Foundation حالا سریع‌تر در چند محصول منتشر می‌شود؟ممکن است Adoption بالا باشد اما بسیاری از Instanceها Override یا Detach شده باشند. ممکن است تیم‌ها Component را استفاده کنند اما برای Patternهای اطراف آن همچنان Solutionهای کاملاً متفاوت بسازند. حتی ممکن است استفاده از Component اجباری شده باشد، بدون اینکه تیم‌ها واقعاً به سیستم اعتماد داشته باشند.بنابراین سؤال «چند نفر از Design System استفاده می‌کنند؟» باید کنار سؤال دیگری قرار بگیرد:«استفاده از Design System چه چیزی را برای آن‌ها بهتر کرده است؟»

شاید هر Design System نباید Metricهای یکسانی داشته باشد

یکی از مشکلات Measurement این است که معمولاً دنبال یک Dashboard استاندارد برای همه Design Systemها می‌گردیم؛ انگار مجموعه‌ای از Metricها وجود دارد که اگر همه آن‌ها را اندازه بگیریم، می‌توانیم درباره موفقیت هر سیستمی قضاوت کنیم.اما Design Systemها همیشه برای حل مسئله یکسانی ساخته نمی‌شوند.ممکن است یک سازمان Design System را ایجاد کرده باشد چون تیم‌ها برای ساخت Featureهای مشابه زمان زیادی صرف می‌کردند. در این حالت Speed و Rework اهمیت زیادی دارند.در سازمان دیگری مشکل اصلی این بوده که پنج محصول متعلق به یک Brand تجربه‌های کاملاً متفاوتی داشته‌اند. اینجا Consistency و استفاده از Patternهای مشترک اهمیت بیشتری پیدا می‌کند.در سازمان دیگری Accessibility Problemها در محصولات مختلف بارها تکرار شده‌اند. در این شرایط یکی از Outcomeهای مهم می‌تواند کاهش تکرار همان دسته از Accessibility Issueها باشد.برای همین Measurement بهتر است از Metric شروع نشود، بلکه از Problem شروع شود.می‌توانیم مسیر را این‌طور ببینیم: Problem → Expected Change → Signal → Metric اگر مسئله ما Duplicate Implementation است، انتظار داریم تیم‌ها کمتر Solution موازی بسازند. Signal می‌تواند کاهش Local Componentهای مشابه باشد و بعد برای آن Metric تعریف کنیم.اگر مسئله کند بودن Delivery است، انتظار داریم زمان لازم برای حل مسائل تکراری کمتر شود. Signal می‌تواند کاهش زمان Design یا Development برای Flowهای استاندارد باشد.اگر مسئله Accessibility است، انتظار داریم مشکلاتی که یک بار در سطح سیستم حل شده‌اند کمتر در محصولات تکرار شوند.در این مدل، Metric آخرین مرحله است، نه اولین مرحله.

سرعت را هم باید با احتیاط اندازه بگیریم

یکی از وعده‌های رایج Design System این است که تیم‌ها سریع‌تر محصول می‌سازند. منطقی هم هست؛ وقتی Componentها و Patternهای مشترک وجود دارند، نباید هر تیم همه‌چیز را از ابتدا طراحی و پیاده‌سازی کند.اما حتی «سرعت» هم اگر Context نداشته باشد می‌تواند Metric گمراه‌کننده‌ای باشد.اگر تیم‌ها سریع‌تر Design تحویل دهند اما Developerها مجبور باشند Componentها را دائماً Override کنند، بخشی از زمان فقط از Design به Engineering منتقل شده است. اگر Development سریع‌تر شود اما Design System Team برای هر Exception ساعت‌ها Review انجام دهد، هزینه از Product Team به تیم مرکزی منتقل شده است.بنابراین بهتر است به‌جای اندازه‌گیری سرعت یک نقطه، هزینه کل انجام کار را ببینیم.آیا زمان تصمیم‌گیری کمتر شده است؟ آیا Handoff سؤال‌های کمتری ایجاد می‌کند؟ آیا Engineering کمتر چیزی را دوباره می‌سازد؟ آیا Reviewهای تکراری کاهش پیدا کرده‌اند؟ آیا تغییر یک تصمیم مشترک در چند محصول آسان‌تر شده است؟Design System زمانی Efficiency ایجاد کرده که هزینه را کاهش داده باشد، نه اینکه فقط آن را به بخش دیگری منتقل کرده باشد.

Consistency هم با Screenshot قابل اندازه‌گیری نیست

ممکن است یکی از اهداف سیستم افزایش Consistency باشد، اما اینجا هم باید مشخص کنیم منظورمان از Consistency چیست.اگر فقط بررسی کنیم چند درصد محصولات از همان Button، Color Token یا Typography استفاده می‌کنند، بیشتر Visual Consistency را اندازه گرفته‌ایم. درحالی‌که بخش مهم‌تری از Consistency در Behavior و Decisionها شکل می‌گیرد.ممکن است دو محصول دقیقاً از همان Modal استفاده کنند، اما در یکی Delete همیشه Confirmation داشته باشد و در دیگری رفتار مشابه بدون هیچ هشدار انجام شود.از نظر Component Usage هر دو محصول کاملاً Adopted هستند، اما از نظر Predictability تجربه یکسانی ایجاد نکرده‌اند.پس اگر Consistency یکی از Outcomeهای مورد انتظار Design System است، باید مشخص کنیم کدام نوع Consistency برای ما ارزش ایجاد می‌کند و اختلاف در کدام تصمیم‌ها واقعاً برای کاربر هزینه دارد.در غیر این صورت ممکن است عدد Adoption بالا برود، درحالی‌که مسئله‌ای که Design System برای حل آن ساخته شده همچنان باقی مانده باشد.

بعضی Metricها باید درباره چیزهایی باشند که دیگر اتفاق نمی‌افتند

یک بخش جالب Measurement این است که ارزش Design System همیشه در چیزی که ایجاد کرده دیده نمی‌شود؛ گاهی در چیزی دیده می‌شود که دیگر لازم نیست اتفاق بیفتد.اگر قبلاً چهار تیم چهار Date Picker متفاوت می‌ساختند و حالا یک Solution مشترک دارند، بخشی از ارزش سیستم در چهار Implementation جدیدی است که دیگر ساخته نشدند.اگر قبلاً یک Accessibility Bug در پنج محصول جداگانه Fix می‌شد و حالا یک بار در Component اصلی حل می‌شود، ارزش Design System فقط تعداد Fixها نیست؛ بخشی از ارزش در Rework جلوگیری‌شده قرار دارد.اگر قبلاً Designer برای انتخاب Pattern مناسب مجبور بود از چند نفر سؤال کند و حالا Documentation پاسخ را می‌دهد، بخشی از Impact در سؤال‌هایی است که دیگر لازم نیست پرسیده شوند.این نوع ارزش را می‌توان Avoided Cost دید؛ هزینه‌ای که به‌دلیل وجود سیستم دیگر ایجاد نمی‌شود.اندازه‌گیری آن سخت‌تر از شمردن Componentهاست، اما به دلیل وجود Design System نزدیک‌تر است

شاید مهم‌ترین Metric اصلاً داخل Design System نباشد

اگر هدف Design System بهتر کردن نحوه ساخت محصول است، بخشی از مهم‌ترین Evidenceها احتمالاً خارج از خود Library قرار دارند.در Product Teamها.در Pull Requestها.در Figma Fileهای واقعی.در Support Questionها.در Accessibility Auditها.در زمانی که تیم‌ها برای Delivery صرف می‌کنند.در تعداد Solutionهای Local که همچنان ساخته می‌شوند.اگر فقط Analytics خود Documentation، Package یا Figma Library را ببینیم، درواقع رفتار خود سیستم را اندازه گرفته‌ایم، نه اثری که سیستم روی سازمان گذاشته است.برای همین یک Measurement Strategy بالغ باید بتواند بین System Data و Product Data ارتباط برقرار کند.

موفقیت را از مسئله‌ای که قرار بود حل کنیم تعریف کنیم

شاید به‌جای ساخت یک Dashboard بزرگ با ده‌ها Metric، بهتر باشد ابتدا سه سؤال ساده داشته باشیم:قبل از Design System چه چیزی برای تیم‌ها سخت بود؟انتظار داشتیم Design System چه تغییری در آن ایجاد کند؟چه Evidenceای نشان می‌دهد این تغییر واقعاً اتفاق افتاده است؟اگر پاسخ سؤال اول «تکرار Implementation» باشد، موفقیت باید جایی در کاهش آن تکرار دیده شود.اگر پاسخ «تصمیم‌گیری کند» باشد، باید بتوانیم کاهش زمان یا وابستگی تصمیم‌گیری را ببینیم.اگر پاسخ «تجربه‌های غیرقابل پیش‌بینی» باشد، باید تغییر را در Consistency تصمیم‌های مهم محصول بررسی کنیم.اگر پاسخ «Accessibility Problemهای تکراری» باشد، باید ببینیم آیا مشکلات حل‌شده در سطح سیستم واقعاً کمتر در محصولات ظاهر می‌شوند.در این نگاه، هیچ Metric جهانی وجود ندارد که به‌تنهایی بگوید یک Design System موفق است.چون موفقیت سیستم باید نسبت به مسئله‌ای سنجیده شود که برای حل آن ساخته شده است.

جمع‌بندی

تعداد Componentها، Documentation Coverage، Adoption، Contribution و Release Frequency همگی داده‌های مفیدی هستند، اما بیشتر درباره فعالیت و Reach سیستم اطلاعات می‌دهند.موفقیت واقعی زمانی مشخص می‌شود که بتوانیم نشان دهیم وجود Design System چیزی را در نحوه ساخت محصول بهتر کرده است؛ تیم‌ها کمتر دوباره‌کاری می‌کنند، تصمیم‌های تکراری را سریع‌تر می‌گیرند، Solutionهای موازی کمتری می‌سازند، مشکلات Accessibility کمتر تکرار می‌شوند یا تغییرات مشترک با هزینه کمتری در محصولات منتشر می‌شوند.بنابراین شاید سؤال اصلی Measurement این نباشد:«Design System ما چند Component دارد و چند تیم از آن استفاده می‌کنند؟»بلکه این باشد:«از زمانی که Design System را ساخته‌ایم، چه چیزی در نحوه ساخت محصول واقعاً بهتر شده است؟»اگر نتوانیم برای این سؤال Evidence پیدا کنیم، ممکن است Design System بسیار فعال، پرکاربرد و حتی محبوب باشد، اما هنوز ندانیم آیا واقعاً موفق بوده است.

منابع