نیروی جدید چقدر Design System شما رو می‌فهمه؟

فرض کنید یک Designer جدید وارد تیم Design System شما شده است. به Figma دسترسی دارد، Documentation را می‌بیند، Componentها را می‌شناسد و حتی می‌تواند Tokenهای سیستم را بررسی کند. از نظر دسترسی، تقریباً همه‌چیز در اختیار اوست.

اما بعد از چند روز، سؤال‌هایی مطرح می‌کند که جوابشان را در هیچ‌کدام از این منابع پیدا نمی‌کند.

چرا فاصله بین Title و Content دقیقاً این مقدار انتخاب شده است؟ چرا برای Empty State از این Pattern استفاده می‌کنیم؟ چرا Button فقط سه Variant دارد و Variant دیگری به آن اضافه نمی‌کنیم؟ چرا این Component در Core System قرار گرفته، اما Component مشابهی که در چند محصول استفاده می‌شود هنوز وارد سیستم نشده است؟

احتمالاً برای پیدا کردن پاسخ این سؤال‌ها باید سراغ یکی از اعضای قدیمی تیم برود، چون بسیاری از این تصمیم‌ها زمانی در یک Design Review، جلسه تیمی یا بحث بین Designer و Developer گرفته شده‌اند و بعد فقط نتیجه آن‌ها وارد Design System شده است.

اینجا یک مشکل مهم خودش را نشان می‌دهد: ما معمولاً خروجی تصمیم‌ها را مستند می‌کنیم، اما منطق پشت تصمیم‌ها را نه.

یک نیروی جدید فقط نباید بداند «چه چیزی» وجود دارد

فرض کنید Documentation به Designer جدید می‌گوید که برای Empty State باید از یک Illustration، یک Title، یک Description و یک Action استفاده کند. او حالا می‌داند Pattern چیست و حتی می‌تواند دقیقاً مطابق Design System آن را اجرا کند.

اما هنوز نمی‌داند چرا این Pattern انتخاب شده است.

شاید تیم قبلاً چند مدل مختلف را آزمایش کرده و متوجه شده باشد که Empty State بدون Action در بعضی Flowها کاربر را در بن‌بست قرار می‌دهد. شاید تصمیم گرفته شده باشد Illustration فقط در Empty Stateهای اصلی استفاده شود، چون استفاده بیش از حد از آن Hierarchy صفحات را ضعیف می‌کند.

اگر این منطق ثبت نشده باشد، Designer جدید فقط می‌تواند Pattern موجود را کپی کند. در اولین موقعیتی که مسئله کمی متفاوت شود، دیگر نمی‌داند باید همان Pattern را حفظ کند، آن را تغییر دهد یا Pattern جدیدی بسازد.

این تفاوت مهمی است. دانستن Rule به شما می‌گوید چه کاری انجام دهید، اما دانستن Rationale کمک می‌کند بفهمید وقتی شرایط تغییر کرد چه تصمیمی بگیرید.

مستندات معمولاً آخر تصمیم را ثبت می‌کند، نه مسیر رسیدن به آن را

بسیاری از Design Systemها Documentation خوبی دارند، اما حتی Documentation خوب هم معمولاً وضعیت فعلی سیستم را توضیح می‌دهد.

مثلاً نوشته شده است که Button سه Variant دارد: Primary، Secondary و Destructive.

اما Designer جدید ممکن است بعد از مدتی بپرسد چرا Ghost Button نداریم. اگر Documentation فقط وضعیت فعلی را توضیح داده باشد، هیچ پاسخی برای این سؤال وجود ندارد.

شاید تیم شش ماه قبل دقیقاً درباره Ghost Button بحث کرده، نمونه‌های مختلف را بررسی کرده و در نهایت به این نتیجه رسیده باشد که نیازهای مربوط به آن با Secondary Button قابل حل هستند و اضافه کردن Variant جدید فقط انتخاب‌های بیشتری وارد سیستم می‌کند.

اگر این تصمیم ثبت نشده باشد، تیم جدید ممکن است همان بحث را دوباره از ابتدا شروع کند و حتی در نهایت Ghost Button را اضافه کند. نه به این دلیل که شرایط تغییر کرده، بلکه صرفاً به این دلیل که نمی‌داند چرا قبلاً این تصمیم رد شده است.

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

پس دقیقاً چه چیزی باید ثبت شود؟

راه‌حل این نیست که برای هر Pixel و هر تصمیم کوچک یک سند چندصفحه‌ای بنویسیم. چنین سیستمی خیلی زود آن‌قدر سنگین می‌شود که کسی آن را به‌روز نمی‌کند.

موضوع اصلی این است که تصمیم‌هایی را ثبت کنیم که احتمال دارد در آینده دوباره مورد سؤال قرار بگیرند.

برای مثال، اگر تیم تصمیم گرفته Component خاصی بیشتر از سه Variant نداشته باشد، فقط محدودیت را ثبت نکنیم. توضیح دهیم که این محدودیت چرا ایجاد شده، چه مشکلی قرار است حل کند و در چه شرایطی امکان بازنگری آن وجود دارد.

اگر Pattern مشخصی برای Empty State انتخاب شده است، فقط Anatomy آن را نمایش ندهیم. توضیح دهیم چه گزینه‌های دیگری بررسی شده‌اند، چرا این گزینه انتخاب شده و در چه Use Caseهایی نباید از آن استفاده شود.

اگر فاصله مشخصی بین Title و Content وجود دارد و این مقدار بخشی از یک منطق بزرگ‌تر برای Hierarchy یا Rhythm محصول است، بهتر است همان منطق ثبت شود. در این صورت فرد جدید به جای حفظ کردن یک عدد، سیستم پشت آن عدد را می‌فهمد.

یک Decision Record ساده می‌تواند بخش زیادی از این مشکل را حل کند

برای تصمیم‌های مهم لازم نیست Documentation پیچیده‌ای داشته باشیم. یک Decision Record کوتاه می‌تواند چهار سؤال را پاسخ دهد: مسئله چه بود، چه تصمیمی گرفتیم، چرا این تصمیم را گرفتیم و چه گزینه‌هایی را کنار گذاشتیم.

فرض کنید درخواست اضافه شدن Variant جدیدی به Button مطرح شده است. به جای اینکه نتیجه جلسه فقط به شکل «درخواست رد شد» باقی بماند، می‌توان ثبت کرد که این Variant برای چه Use Caseای درخواست شده، چرا تیم تشخیص داده Secondary همان نیاز را پوشش می‌دهد و تحت چه شرایطی ممکن است این تصمیم در آینده دوباره بررسی شود.

حالا اگر یک سال بعد Designer جدیدی همان سؤال را مطرح کند، لازم نیست دنبال فردی بگردد که در جلسه قبلی حضور داشته است. خود Design System می‌تواند منطق تصمیم را به او منتقل کند.

این کار فقط برای Onboarding نیست

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

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

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

بنابراین ثبت Rationale فقط از تصمیم‌های گذشته محافظت نمی‌کند؛ گاهی به ما کمک می‌کند بفهمیم چه زمانی باید از تصمیم‌های گذشته عبور کنیم.

یک Design System بالغ فقط جواب نمی‌دهد؛ دلیل جواب را هم نگه می‌دارد

یک آزمایش ساده برای Design System وجود دارد. یک Designer باتجربه اما کاملاً جدید را وارد تیم کنید و ببینید بعد از مطالعه سیستم چه نوع سؤال‌هایی مجبور است از اعضای قدیمی بپرسد.

اگر بیشتر سؤال‌ها درباره این باشند که «این Component کجاست؟» یا «چطور از این Variant استفاده کنم؟»، احتمالاً Documentation شما مشکل دارد.

اما اگر سؤال‌ها بیشتر شبیه «چرا این Pattern را انتخاب کردیم؟»، «چرا این حالت وجود ندارد؟» یا «چرا این Component این محدودیت را دارد؟» باشند، مسئله عمیق‌تر است. بخشی از منطق Design System هنوز در ذهن افراد قرار دارد.

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

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

شاید یکی از معیارهای بلوغ Design System همین باشد: فردی که امروز وارد تیم می‌شود، چقدر می‌تواند بدون حضور سازندگان اولیه سیستم بفهمد نه فقط چه چیزی ساخته شده، بلکه چرا این‌طور ساخته شده است؟