Design System | سیستم طراحی
سیستم طراحی (Design System) مجموعهٔ متصل توکن‌ها، اجزا، الگوها، اصول و مستنداتی است که تجربهٔ محصول را در مقیاس یکدست، قابل ساخت و قابل نگهداری می‌کند. برخلاف یک کتابخانهٔ پراکندهٔ دکمه و رنگ، سیستم قرارداد مشترک طراحی و مهندسی است: منبع حقیقت برای «چطور می‌سازیم» تا هر تیم چرخ را از نو اختراع نکند و کاربر در هر گوشهٔ محصول زبان بصری و رفتاری آشنا ببیند.
توکن، جزء، الگو، مستند: چهار لایهٔ متصل
توکن‌ها مقادیر پایه مثل رنگ، فاصله، شعاع، تایپ و سایه را نام‌گذاری می‌کنند تا تصمیم از مقدار جادویی جدا شود. اجزا قطعات رابط قابل بازاستفاده—دکمه، ورودی، مودال، ناوبری—با حالت‌های مشخص‌اند. الگوها ترکیب اجزا برای مسائل پرتکرار مثل فرم تنظیمات یا لیست قابل فیلتر را نشان می‌دهند. مستند توضیح می‌دهد کی از چه چیزی استفاده شود، چه استثنائی مجاز است، و دسترسی چگونه رعایت شود.
اگر فقط فایل Figma بدون توکن و کد هم‌تراز باشد، سیستم نیمه‌کاره است. اگر فقط پکیج کامپوننت بدون راهنمای مصرف باشد، سیستم به جعبه‌ابزار خاموش تبدیل می‌شود. اتصال طراحی، کد و نوشتار همان چیزی است که مقیاس را ممکن می‌کند.
چرا سیستم با «کتابخانهٔ UI» یکی نیست
کتابخانهٔ UI مجموعهٔ قطعات است. سیستم طراحی علاوه بر قطعات، اصول تصمیم، قواعد محتوا، معیار دسترسی، نسخه و حاکمیت تغییر را دارد. کتابخانه می‌گوید «این دکمه وجود دارد»؛ سیستم می‌گوید «در این بافت کدام دکمه، با کدام برچسب، با کدام حالت خطا». بدون اصول، تیم‌ها جزء را درست برمی‌دارند و اشتباه ترکیب می‌کنند.
الگوهای طراحی دانش حل مسئله‌اند؛ عناصر طراحی مصالح خام‌اند؛ اصول معیار داوری‌اند. سیستم این‌ها را در یک اکوسیستم عملیاتی با مالکیت و انتشار منظم جمع می‌کند تا محصول در رشد تکه‌تکه نشود.
حاکمیت: نسخه‌بندی، درخواست تغییر، استثناء
سیستم بدون حاکمیت سریع فورک می‌شود: هر تیم نسخهٔ محلی خودش را می‌سازد و یکدستی می‌میرد. مدل سالم کانال درخواست جزء یا تغییر، بازبینی میان طراحی و مهندسی، نسخه‌بندی معنایی، و یادداشت انتشار دارد. استثناء مجاز است اگر زمان‌دار، مستند و با طرح بازگشت باشد—نه اگر هر اسپرینت «فقط این بار» تکرار شود.
نقش نگهبان سیستم—فرد یا شورای کوچک—از انسداد نوآوری جلوگیری می‌کند وقتی مسیر مشارکت روشن باشد. تیم محصول باید بداند چطور نیاز جدید را بالا ببرد، نه اینکه بی‌صدا جزء یک‌بارمصرف بسازد.
هم‌ترازی طراحی و کد؛ بدهی سیستم
منبع حقیقت دوگانه وقتی خطرناک است که نام‌ها، فاصله‌ها یا رفتارها بین فایل طراحی و پیاده‌سازی منحرف شوند. توکن مشترک، داستان‌های جزء در محیط توسعه، و تست دیداری یا قراردادی فاصله را کم می‌کنند. Design QA اغلب انطباق با سیستم را به‌عنوان معیار عبور چک می‌کند؛ سیستم سالم کار QA را ارزان‌تر می‌کند چون انحراف کمتر است.
بدهی سیستم مثل بدهی فنی است: جزء بدون حالت غیرفعال، توکن بدون تم تاریک، الگوی فرم بدون پیام خطا. نادیده گرفتن بدهی سرعت کوتاه‌مدت می‌دهد و هزینهٔ بلندمدت پخش ناهماهنگی را بالا می‌برد. بازپرداخت بدهی باید در نقشهٔ راه سیستم جا داشته باشد، نه فقط در شعار «بعداً».
محتوا و دسترسی داخل سیستم
سیستم بالغ فقط رنگ و دکمه نیست. الگوی نوشتاری—لحن دکمه، ساختار خطا، متن حالت خالی—همان‌قدر مقیاس را حفظ می‌کند که فاصلهٔ هشت‌تایی. دسترسی باید در جزء پخته شود: فوکوس، برچسب، کنتراست، ترتیب صفحه‌کلید؛ نه اینکه بعد از ساخت صفحه وصله شود.
وقتی دسترسی و محتوا در سیستم باشند، هر تیم محصول آن‌ها را به‌صورت پیش‌فرض به ارث می‌برد. وقتی بیرون سیستم باشند، هر بار وابسته به قسطای فردی طراح یا نویسنده می‌مانند و کیفیت نوسان می‌کند.
مرز با فرآیند، اسپرینت و نقش‌ها
فرآیند طراحی روش حرکت از مسئله به راه‌حل است؛ سیستم طراحی زیرساخت ساختن یکدست داخل آن روش است. دیزاین اسپرینت ممکن است برای آزمودن ایده موقتاً از سیستم منحرف شود، اما ورود به محصول معمولاً باید به اجزا و توکن‌ها برگردد وگرنه نمونهٔ اسپرینت بدهی بصری می‌کارد. نقش‌های طراحی تعیین می‌کنند چه کسی مصرف‌کننده است و چه کسی نگهبان؛ خود سیستم جایگزین نقشهٔ نقش‌ها نمی‌شود.
ساختن سیستم هدف نهایی محصول نیست؛ اهرم کیفیت و سرعت است. تیمی که ماه‌ها سیستم می‌سازد بدون اینکه محصول واقعی از آن تغذیه کند، زیرساخت را با تحویل اشتباه گرفته است. شروع لاغر با چند توکن و اجزای پرتکرار، سپس رشد بر اساس درد واقعی، معمولاً از طراحی همه‌چیز از روز اول موفق‌تر است.
اتخاذ در سازمان: از مقاومت تا عادت
مقاومت رایج «سیستم آزادی خلاقیت را می‌گیرد» است. در عمل سیستم تصمیم‌های تکراری را استاندارد می‌کند تا خلاقیت روی مسئلهٔ کاربر خرج شود نه روی سایهٔ دکمهٔ بیست‌و‌سوم. آموزش کوتاه، مثال قبل/بعد، و پشتیبانی مهاجرت صفحات قدیمی پذیرش را بالا می‌برد. اجبار بدون مسیر مهاجرت فقط سایهٔ مخفی می‌سازد.
معیار موفقیت سیستم تعداد جزء در کتابخانه نیست. کاهش زمان ساخت صفحهٔ استاندارد، کاهش انحراف در QA، کاهش تیکت «در موبایل فرق دارد»، و رضایت مصرف‌کنندگان داخلی سیگنال‌های بهترند. سیستم وقتی زنده است که به‌روز شود چون محصول واقعی آن را فشار می‌دهد.
شروع لاغر برای تیم‌های متوسط
اگر از صفر می‌سازید: رنگ و تایپ و فاصله را توکن کنید، دکمه و ورودی و دیالوگ و ناوبری را با حالت‌ها بسازید، یک الگوی فرم و یک الگوی لیست مستند کنید، و کانال درخواست تغییر را همان هفته اول روشن بگذارید. همزمان پکیج کد یا دست‌کم قرارداد نام‌گذاری با مهندسی هم‌تراز شود. زیبایی کاتالوگ بدون مصرف در اسپرینت بعدی ارزش عملی ندارد.
اگر سیستم میراثی دارید: اول ممیزی انحراف‌های پرتکرار، بعد ادغام تکراری‌ها، بعد نسخه‌بندی و بازنشستگی. بازنشستگی جزء قدیمی به‌اندازهٔ افزودن جزء جدید شجاعت می‌خواهد؛ وگرنه کتابخانه گورستان نسخه‌های نیمه‌مرده می‌شود.
تم، پلتفرم و چند برند بدون از هم پاشیدن
محصول‌هایی با تم روشن و تاریک، یا چند برند زیر یک چتر، سیستم را تحت فشار می‌گذارند. توکن معنایی—مثل رنگ سطح، رنگ خطر، رنگ تأکید—به‌جای چسباندن مستقیم هگز به جزء، اجازه می‌دهد تم عوض شود بدون بازنویسی همهٔ صفحات. برای چند پلتفرم، قرارداد رفتاری مشترک مهم‌تر از کپی پیکسل‌به‌پیکسل است: دکمه باید همان معنا را داشته باشد حتی اگر اندازه لمسی در موبایل فرق کند.
بدون لایهٔ توکن معنایی، هر تم فورک بصری جدید می‌سازد و نگهداشت غیرممکن می‌شود. سیستم اینجا همان جایی است که مقیاس برند و پلتفرم را از هنر دستی تکراری جدا می‌کند.
اندازه‌گیری سلامت سیستم در عمل
داشبورد ساده کافی است: درصد صفحه‌های جدید ساخته‌شده فقط با اجزای رسمی، تعداد درخواست تغییر باز، میانگین زمان پاسخ به درخواست، تعداد فورک‌های محلی کشف‌شده در ممیزی فصلی، و تعداد ایرادهای Design QA از نوع «ناسازگار با سیستم». اگر فورک‌ها زیاد و درخواست‌ها کم باشد، یا مشارکت سخت است یا سیستم نیازهای واقعی را پوشش نمی‌دهد.
سلامت مستند هم مهم است: صفحه‌ای که شش ماه لمس نشده و جزءش عوض شده منبع بی‌اعتمادی است. نگهبان سیستم باید تازگی راهنما را هم‌تراز با نسخهٔ کد بداند؛ وگرنه تیم‌ها دوباره به حدس و پیام خصوصی پناه می‌برند.
جمع‌بندی
سیستم طراحی قرارداد مقیاس‌پذیر توکن، جزء، الگو و مستند بین طراحی و مهندسی است که یکدستی، دسترسی و سرعت را در رشد محصول حفظ می‌کند. با کتابخانهٔ صرف، با فرآیند کشف، با اسپرینت پنج‌روزه و با نقشهٔ نقش‌ها فرق دارد—هرکدام لایهٔ دیگری از کارند. سیستم خوب تصمیم تکراری را ارزان و تجربه را در کل محصول آشنا نگه می‌دارد.
سوالات متداول
مجموعهٔ متصل توکن‌ها، اجزا، الگوها، اصول و مستندات که تجربه را در مقیاس یکدست و قابل ساخت نگه می‌دارد و قرارداد مشترک طراحی و مهندسی است.
کتابخانه قطعات را دارد؛ سیستم علاوه بر آن اصول تصمیم، قواعد محتوا، دسترسی، نسخه‌بندی و حاکمیت تغییر را هم شامل می‌شود.
مقادیر پایه مثل رنگ و فاصله را نام‌گذاری می‌کند تا طراحی و کد از یک منبع حقیقت تغذیه شوند و از عدد جادویی پراکنده جلوگیری شود.
خیر. اسپرینت برای آزمودن سریع یک سؤال است؛ سیستم زیرساخت ساخت یکدست در محصول واقعی است و معمولاً بعد از یادگیری اسپرینت دوباره محور تحویل می‌شود.
با توکن‌های پایه، چند جزء پرتکرار با حالت‌ها، یک یا دو الگو، مستند مصرف و کانال درخواست تغییر—هم‌تراز با پیاده‌سازی کد، نه فقط فایل طراحی.