سیستم‌های طراحی: چرا اکثرشان شکست می‌خورند و چطور یکی بسازید که کار کند

هر تیمی که به اندازه معینی برسد، سرانجام یک چیز می‌گوید: «به یک design system نیاز داریم.» بعد بیشترشان شش ماه صرف ساختن چیزی می‌کنند که کسی استفاده نمی‌کند، و یک سال بعد دوباره با همان ناسازگاری اولیه روبرو هستند.

مشکل هیچ‌وقت component‌ها نیستند. مشکل این است که با design system مثل یک پروژه رفتار می‌کنید، نه مثل یک محصول. پروژه‌ها تمام می‌شوند. محصول‌ها تکامل می‌یابند. یک design system که از تکامل می‌ایستد، از روز راه‌اندازی شروع به مردن می‌کند.

Design System واقعاً چیست

یک design system یک کتابخانه component نیست. کتابخانه component یک پوشه از عناصر UI قابل استفاده مجدد است. یک design system مجموعه کاملی از استانداردها، مستندات، و ابزارهایی است که نحوه طراحی و ساخت یک محصول را هدایت می‌کند.

شامل این موارد است:

• Design tokens. مقادیر اتمی (رنگ‌ها، فاصله‌گذاری، تایپوگرافی، سایه‌ها) که همه چیز دیگر به آن‌ها ارجاع می‌دهد.
• Components. عناصر UI قابل استفاده مجدد که از token‌ها ساخته شده‌اند.
• Patterns. راه‌حل‌های مستند برای مشکلات طراحی تکراری (فرم‌ها، ناوبری، حالات خطا).
• Guidelines. قوانینی که می‌گویند چه وقت و چطور از هر بخش استفاده کنید.
• Governance. اینکه چه کسی مالک سیستم است، چطور تغییرات پیشنهاد می‌شوند، و چطور تصمیمات گرفته می‌شوند.

هرکدام از این‌ها را بردارید، یک سیستم ناقص دارید. سیستم‌های ناقص پذیرش ناقص ایجاد می‌کنند. پذیرش ناقص همان ناسازگاری‌ای را ایجاد می‌کند که سعی داشتید حلش کنید.

چرا اکثر Design System‌ها شکست می‌خورند

شکست ۱: ساخته‌شده در انزوا. یک تیم کوچک سه ماه ناپدید می‌شود، یک سیستم زیبا می‌سازد، و آن را به سازمانی ارائه می‌دهد که هیچ نظری نداشته. سیستم انعکاس فرضیات سازندگان است، نه واقعیت کاربران. پذیرش در ابتدا محترمانه است، بعد آرام‌آرام رها می‌شود.

شکست ۲: خیلی سخت‌گیر در اول کار. سیستم با قوانین سختگیرانه برای هر سناریو راه‌اندازی می‌شود. طراحان و مهندسانی که با موردی روبرو می‌شوند که سیستم پیش‌بینی نکرده، دو گزینه دارند: با سیستم بجنگند یا دورش بزنند. بیشترشان راه دور زدن را انتخاب می‌کنند. سیستم تبدیل به مرجعی می‌شود که کسی به آن مراجعه نمی‌کند.

شکست ۳: بدون مالکیت اختصاصی. سیستم در طول یک sprint ساخته شد. کسی مسئول نگهداری آن نیست. Token‌ها از codebase فاصله می‌گیرند. Component‌ها عقب محصول می‌مانند. مستندات قدیمی می‌شود. شش ماه بعد، سیستم یک اسنپ‌شات از آن چیزی است که محصول سال پیش بود.

شکست ۴: تفکر component-first. تیم ۴۷ component می‌سازد قبل از اینکه یک token تعریف کند یا یک guideline بنویسد. Component‌ها در فایل Figma کار می‌کنند اما در production خراب می‌شوند چون مقادیر زیربنایی هرگز سیستماتیک نشدند.

شکست ۵: فلج شدن از کمال‌گرایی. تیم سعی می‌کند قبل از راه‌اندازی هر edge case را حل کند. سیستم هیچ‌وقت منتشر نمی‌شود. در این حین، محصول روزانه بدون آن منتشر می‌شود.

چه چیزی در سیستم‌های بازمانده مشترک است

بعد از بررسی سیستم‌هایی که واقعاً دوام می‌آورند (Shopify Polaris، Atlassian Design System، IBM Carbon، GitHub Primer)، سه pattern مشخص می‌شود:

از کوچک شروع کردند و رشد کردند. هیچ‌کدام با ۲۰۰ component راه‌اندازی نشدند. با token‌ها، تعداد کمی از component‌های اصلی، و مستندات واضح راه‌اندازی شدند. بعد بر اساس نیازهای واقعی محصول گسترش یافتند، نه کامل بودن نظری.

تیم‌های اختصاصی دارند. نه یک نفر. یک تیم. design system‌ها در مقیاس بزرگ به حداقل یک طراح، یک مهندس، یک نویسنده مستندات، و یک product owner نیاز دارند. Shopify ده‌ها نفر دارد که روی Polaris کار می‌کنند. شما به ده‌ها نفر نیاز ندارید، اما به بیشتر از صفر نفر نیاز دارید.

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

Design Tokens پایه واقعی هستند

Token‌ها مقادیر اولیه‌ای هستند که همه چیز دیگر از آن‌ها ارث می‌برد. یک token را تغییر دهید، و هر component که به آن ارجاع می‌دهد به‌طور خودکار به‌روز می‌شود. این چیزی است که یک سیستم را سیستم می‌کند، نه یک مجموعه.

سطوح Token:

Token‌های Global مقادیر خام را تعریف می‌کنند. Semantic tokens معنا را اختصاص می‌دهند (primary، danger، surface). Token‌های Component آن معناها را به عناصر UI خاص متصل می‌کنند. این ساختار سه‌لایه یعنی می‌توانید با تغییر semantic token‌ها rebrand کنید بدون اینکه یک component را لمس کنید.

انواع Token برای تعریف اول:

• رنگ‌ها (پس‌زمینه، متن، حاشیه، حالات تعاملی)
• فاصله‌گذاری (شبکه 4px: 4، 8، 12، 16، 24، 32، 48، 64)
• تایپوگرافی (خانواده، مقیاس اندازه، وزن، ارتفاع خط)
• شعاع حاشیه (هیچ، کوچک، متوسط، بزرگ، کامل)
• سایه‌ها (سطوح ارتفاع)
• Motion (مدت زمان، منحنی‌های easing)

اگر هیچ چیز دیگری تعریف نمی‌کنید، این‌ها را تعریف کنید. ۹۰٪ از تصمیمات بصری که تیمتان روزانه می‌گیرد را پوشش می‌دهند.

ساخت Component‌هایی که دوام می‌آورند

Component‌های ساخته‌شده روی token‌ها ذاتاً مقاوم‌تر از component‌های ساخته‌شده روی مقادیر hardcode شده هستند. اما حتی component‌های مبتنی بر token هم اگر اشتباه ساخته شوند، شکست می‌خورند.

قوانین برای component‌هایی که دوام می‌آورند:

Composition به جای configuration. یک button با ۱۴ prop انعطاف‌پذیر نیست. شکننده است. به جای ساختن یک mega-component که هر variant را از طریق prop‌ها مدیریت می‌کند، قطعات کوچک قابل ترکیب بسازید که به pattern‌ها تبدیل می‌شوند. یک card یک component نیست. یک card container، یک card header، یک card body، و یک card footer است که با هم ترکیب می‌شوند.

State‌ها اختیاری نیستند. هر component تعاملی به این‌ها نیاز دارد: default، hover، active، focus، disabled، loading، و error state. ارسال یک component بدون همه هفت state یعنی کسی آن state‌ها را ad hoc می‌سازد، و با بقیه مطابقت نخواهند داشت.

«چه وقت» را مستند کنید نه فقط «چه چیزی». مستندات button شما نباید فقط نشان دهد چطور به نظر می‌رسد. باید بگوید چه وقت از یک primary button در مقابل یک secondary button در مقابل یک ghost button استفاده کنید. چارچوب تصمیم‌گیری بیشتر از مرجع بصری اهمیت دارد.

Pattern‌ها چیزی را حل می‌کنند که Component‌ها نمی‌توانند

یک dropdown component به شما می‌گوید dropdown چطور به نظر می‌رسد. نمی‌گوید چه وقت از dropdown در مقابل یک radio group در مقابل یک segmented control استفاده کنید. آن تصمیم یک pattern است.

Pattern‌هایی که زود مستند کنید:

• چیدمان فرم. جایگذاری label، نمایش خطا، نشانه‌گذاری فیلد الزامی، جریان‌های چندمرحله‌ای.
• ناوبری. چه وقت از tab در مقابل sidebar در مقابل breadcrumb استفاده کنید. رفتار جمع شدن ناوبری موبایل.
• حالات خالی. چه چیزی نشان داده می‌شود وقتی داده‌ای وجود ندارد. تصویرسازی؟ CTA؟ محتوای آموزشی؟
• حالات بارگذاری. Skeleton screen‌ها در مقابل spinner‌ها در مقابل بارگذاری تدریجی. چه وقت هرکدام مناسب است.
• مدیریت خطا. اعتبارسنجی inline در مقابل toast notification‌ها در مقابل حالات خطای تمام صفحه.

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

Governance پذیرش را می‌سازد یا می‌شکند

یک design system بدون governance یک پیشنهاد است. Governance به سه سوال پاسخ می‌دهد:

1. چه کسی تصمیم می‌گیرد؟ آیا یک review board وجود دارد؟ یک مالک واحد؟ یک رای دموکراتیک؟ هرچه انتخاب کنید، آن را صریح کنید.
2. تغییرات چطور اتفاق می‌افتند؟ فرآیند RFC؟ GitHub issue؟ thread در Slack؟ مسیر از «فکر می‌کنم به یک component جدید نیاز داریم» تا «در سیستم است» را تعریف کنید.
3. استراتژی versioning چیست؟ Semantic versioning برای پکیج token؟ Changelog به ازای هر release؟ سیاست breaking change؟

تیم‌هایی که governance را نادیده می‌گیرند با سیستمی روبرو می‌شوند که fork می‌شود. Design از نسخه 2.3 استفاده می‌کند. Engineering از نسخه 1.8 استفاده می‌کند. سایت marketing از نسخه 2.0 با override‌های محلی استفاده می‌کند. در آن مرحله، سه design system دارید و صفر سازگاری.

سوالات متداول

چقدر طول می‌کشد یک design system بسازید؟

پایه اولیه (token‌ها، 10 تا 15 component اصلی، مستندات پایه) با یک تیم اختصاصی 2 تا 4 ماه طول می‌کشد. اما یک design system هیچ‌وقت «تمام» نمی‌شود. برای سرمایه‌گذاری مداوم 15 تا 25 درصد از ظرفیت یک تیم design engineering برنامه‌ریزی کنید.

آیا تیم‌های کوچک به design system نیاز دارند؟

بله، اما یک سیستم متناسب. یک تیم سه‌نفره به Polaris نیاز ندارد. به یک کتابخانه مشترک Figma با token‌ها، 8 تا 10 component اصلی، و یک راهنمای تصمیم‌گیری یک‌صفحه‌ای نیاز دارند. از آنچه بیشتر درد می‌کند شروع کنید (معمولاً فاصله‌گذاری و استفاده ناسازگار از رنگ‌ها) و از آنجا رشد کنید.

تفاوت بین یک design system و یک کتابخانه component چیست؟

کتابخانه component مجموعه‌ای از عناصر UI قابل استفاده مجدد است. یک design system شامل کتابخانه component به علاوه design token‌ها، دستورالعمل‌های استفاده، pattern‌ها، مستندات، و governance است. کتابخانه یک لایه از سیستم است.

با درد شروع کنید، نه بلندپروازی

یک design system نسازید چون حرفه‌ای به نظر می‌رسد. بسازید چون تیمتان وقت خود را صرف حل مکرر مشکلات یکسان می‌کند. از سه چیزی که بیشترین ناسازگاری را در حال حاضر ایجاد می‌کنند شروع کنید. آن‌ها را سیستماتیک کنید. منتشر کنید. بعد بر اساس آنچه تیم بعداً می‌خواهد گسترش دهید، نه آنچه در یک case study چشمگیر به نظر می‌رسد.