سیستم دیزاین چیست؟ Design System، توکن و Handoff

اگر می‌پرسید سیستم دیزاین چیست، پاسخ این است: منبع مشترک قواعد، توکن‌ها، کامپوننت‌ها و راهنمای استفاده که طراحی و توسعه را روی یک زبان واحد نگه می‌دارد. سیستم دیزاین فقط پوشهٔ دکمه در Figma نیست. وقتی رنگ، فاصله، وضعیت خطا و رفتار ریسپانسیو در طراحی و کد یکی باشند، محصول یکدست‌تر ساخته می‌شود و هر صفحه از صفر اختراع نمی‌شود.

جست‌وجوهایی مثل «سیستم دیزاین چیست»، «تفاوت UI Kit و Design System»، «توکن رنگ و فاصله»، «Handoff به فرانت» و «چه زمانی به سیستم دیزاین نیاز داریم» معمولاً وقتی مطرح می‌شوند که تیم از ناهماهنگی دکمه‌ها، بازکاری و سوءتفاهم طراح و برنامه‌نویس خسته شده است. در این راهنما اجزای سیستم، زمان شروع، توکن، کامپوننت، مستندات، تحویل به فرانت و هزینهٔ نداشتن سیستم را بررسی می‌کنیم. برای تمایز نقش رابط و تجربه، راهنمای تفاوت UI و UX زمینه می‌سازد و اجرای آن در خدمات UI/UX روبینش ادامه پیدا می‌کند.

“A design system is a set of interconnected patterns and shared practices coherently organized to serve the purposes of a digital product.”

سیستم دیزاین چیست و چه چیزی نیست؟

سیستم دیزاین توافق عملی تیم دربارهٔ ساخت رابط است. شامل اصول (مثلاً وضوح بر تزئین)، توکن‌های بصری، کامپوننت‌های قابل استفاده مجدد، قوانین دسترسی، نمونهٔ استفاده و در حالت بالغ، معادل همان کامپوننت در کد. هدف آن سرعت تزئینی نیست؛ کاهش تصمیم تکراری است. وقتی هر طراح دکمه را جدا می‌سازد و هر توسعه‌دهنده رنگ را از روی اسکرین‌شات برمی‌دارد، محصول به‌تدریج از هم می‌پاشد.

UI Kit مجموعهٔ کامپوننت در فایل طراحی است. Style guide معمولاً رنگ و فونت و لحن را توصیف می‌کند. سیستم دیزاین این‌ها را به هم وصل می‌کند و می‌گوید در چه شرایطی از کدام جزء استفاده شود، چه حالت‌هایی دارد و چگونه در کد پیاده می‌شود. بدون راهنمای استفاده، کتابخانه فقط انبار شکل است و تیم باز هم در هر صفحه راه خودش را می‌رود.

چه زمانی به سیستم دیزاین نیاز داریم؟

برای یک لندینگ کوتاه، ساختن سیستم کامل اتلاف است. وقتی چند صفحه، چند طراح، چند توسعه‌دهنده یا چند سطح محصول دارید، نبود سیستم خودش را نشان می‌دهد: دکمهٔ اصلی در هر صفحه فرق دارد، فاصله‌ها تصادفی‌اند، حالت خطا یکدست نیست و تغییر رنگ برند هفته‌ها طول می‌کشد. اگر همین حالا دو منبع حقیقت دارید — یکی Figma و یکی کد — زمان شروع فرا رسیده است.

• محصول بیش از چند صفحهٔ تکراری دارد یا در حال رشد است.
• بیش از یک نفر رابط را طراحی یا پیاده می‌کند.
• وب و اپ باید حس برند واحد داشته باشند.
• تغییر کوچک بصری به شکار دستی در ده‌ها فایل نیاز دارد.
• بازبینی طراحی بیشتر صرف اصلاح ناهماهنگی می‌شود تا بهبود مسیر کاربر.

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

توکن رنگ، فاصله و تایپوگرافی چیست؟

توکن واحد نام‌گذاری‌شدهٔ یک تصمیم بصری است: به‌جای کد رنگ خام در بیست فایل، نامی مثل color.text.primary یا space.md دارید. طراح و توسعه‌دهنده به همان نام ارجاع می‌دهند. وقتی برند رنگ اصلی را عوض می‌کند، یک نقطه تغییر می‌کند نه صد صفحه. توکن برای همهٔ تیم‌ها اجباری نیست؛ وقتی محصول چند سطح دارد یا تغییر سبک تکرار می‌شود، ارزشش آشکار می‌شود.

color.bg.page
color.text.primary
color.action.default
space.xs → space.xl
radius.md
font.size.body
font.weight.medium

نام توکن باید معنی داشته باشد، نه مقدار. blue-500 وقتی برند سبز شود بی‌معنی می‌شود؛ color.action.default پایدارتر است. فاصله را هم با مقیاس مشخص کنید تا هر صفحه padding دلخواه نگیرد. تایپوگرافی را به نقش محدود کنید: عنوان صفحه، عنوان بخش، بدنه، راهنما و برچسب. اگر هر تیتر اندازهٔ منحصربه‌فرد داشته باشد، سلسله‌مراتب از بین می‌رود.

کامپوننت خوب چه حالت‌هایی دارد؟

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

کامپوننت را با محتوای فارسی واقعی بسنجید. دکمه با متن کوتاه انگلیسی گمراه‌کننده است؛ «درخواست مشاوره رایگان» طول دیگری دارد. کارت با عنوان دوخطی، جدول با عدد فارسی و فرم با خطای طولانی باید در خود سیستم دیده شوند. در غیر این صورت سیستم فقط برای اسکرین‌شات کار می‌کند و در صفحهٔ واقعی می‌شکند.

مستندات و مالکیت سیستم

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

سیستم بدون مالک به‌سرعت کهنه می‌شود. یک نفر یا یک زوج طراح-توسعه‌دهنده باید درخواست جزء جدید، نسخه‌بندی و حذف موارد منسوخ را مدیریت کنند. کانال مشخص برای سؤال بگذارید تا هر تغییر از چت پراکنده وارد فایل نشود. نسخه‌بندی روشن می‌کند آیا تغییر ظاهر دکمه همهٔ محصول را خراب می‌کند یا فقط یک الگوی جدید است.

Handoff سیستم دیزاین به فرانت‌اند

تحویل موفق یعنی نام توکن، رفتار کامپوننت و استثناها برای توسعه‌دهنده قابل پیاده‌سازی باشد. ابزار و Dev Mode را در فیگما چیست جدا ببینید و قرارداد اسپرینت را در دیزاین هندآف چیست بخوانید. لینک Figma به‌تنهایی کافی نیست. باید مشخص شود فاصله از توکن می‌آید یا استثنای موقت است، تصویر با چه اندازه و فرمتی صادر می‌شود، و انیمیشن ضروری است یا تزئینی. اگر کد از قبل کتابخانه دارد، طراحی باید با همان نام‌ها حرف بزند؛ ساختن سیستم موازی در Figma اختلاف را بیشتر می‌کند.

بازبینی مشترک بعد از پیاده‌سازی بخشی از سیستم است. اختلاف یک پیکسل همیشه اولویت ندارد؛ خوانایی، کنتراست، فوکوس و رفتار فرم معمولاً مهم‌ترند. طراح و فرانت باید تصمیم بگیرند کدام انحراف عمدی است و کدام باید اصلاح شود. این گفت‌وگو هزینهٔ بازکاری را کم می‌کند، چون سیستم به‌جای فایل آرشیوی، قرارداد زندهٔ تیم می‌ماند. مسیر عملی این همکاری در راهنمای پروتوتایپ و تست پیش از کد هم دیده می‌شود: اول رفتار، بعد تثبیت جزء.

هزینه نداشتن سیستم دیزاین چیست؟

هزینهٔ نداشتن سیستم همیشه در فاکتور جدا دیده نمی‌شود. در زمان طراح برای بازسازی دکمه، در زمان توسعه‌دهنده برای حدس رنگ، در جلسهٔ بازبینی برای اصلاح ناهماهنگی و در تجربهٔ کاربری که به محصول چندچهره تبدیل شده پنهان است. تغییر برند، افزودن تم تاریک یا ساخت نسخهٔ موبایل بدون توکن، پروژهٔ جدا می‌سازد. با سیستم، همین کار به به‌روزرسانی منبع مشترک نزدیک‌تر است.

از سوی دیگر، سیستم بیش‌ازحد بزرگ هم هزینه دارد. تیمی که سه ماه فقط کتابخانه می‌سازد و محصول را جلو نمی‌برد، اولویت را عوض کرده است. تعادل این است: جزءهایی را وارد سیستم کنید که تکرار شده‌اند یا تکرار خواهند شد. الگوی یک‌بارمصرف می‌تواند در صفحه بماند تا نیاز واقعی ثابت شود. سیستم باید از محصول تغذیه شود، نه اینکه محصول منتظر کامل‌شدن سیستم بماند.

چطور سیستم دیزاین را کوچک شروع کنیم؟

1. فهرست الگوهای تکراری محصول را از صفحه‌های واقعی استخراج کنید.
2. رنگ، فاصله و تایپ را به چند نقش محدود و نام‌گذاری کنید.
3. دکمه، فیلد، لینک، کارت و پیام را با همهٔ حالت‌های لازم بسازید.
4. قاعدهٔ استفاده و مثال غلط را کنار هر جزء بنویسید.
5. نام‌ها را با توسعه‌دهنده یکی کنید و در یک صفحهٔ واقعی به کار ببرید.
6. بعد از استفاده، جزء بعدی را اضافه کنید؛ از قبل انبار نسازید.

این مسیر برای استارتاپ و سایت شرکتی هر دو جواب می‌دهد، فقط عمق فرق دارد. محصول کوچک به چند توکن و چند جزء می‌رسد. محصول چندتیمی به نسخه‌بندی، مستند عمومی و فرآیند درخواست نیاز دارد. مقیاس را با تعداد تصمیم تکراری بسنجید، نه با تقلید از سیستم شرکت‌های بزرگ. کپی Material یا یک کتابخانهٔ عمومی بدون تطبیق با برند و محتوای فارسی، فقط ظاهر یکدست کاذب می‌سازد و در فرم و جدول واقعی می‌شکند.

اگر وب و اپ هم‌زمان پیش می‌روند، از روز اول دربارهٔ توکن مشترک یا نگاشت مشخص حرف بزنید. لازم نیست یک فایل واحد همهٔ پلتفرم‌ها را اداره کند؛ لازم است رنگ نقش‌دار و معنای دکمهٔ اصلی در هر دو جا یکی باشد. اختلاف کنترل‌شده بهتر از شباهت تصادفی است. تیم‌هایی که این نگاشت را به بعد از لانچ موکول می‌کنند، معمولاً دو سیستم جدا و پرهزینه می‌سازند.

اشتباهات رایج در سیستم دیزاین

• ساخت کتابخانهٔ بزرگ قبل از استفاده در محصول واقعی
• نام‌گذاری توکن بر اساس مقدار به‌جای نقش
• نادیده‌گرفتن حالت فوکوس، خطا و محتوای فارسی بلند
• دو منبع حقیقت جدا در Figma و کد
• نبود مالک برای پذیرش یا رد جزء جدید
• مستندات طولانی بدون مثال درست و غلط
• اجبار به استفاده از جزء نامناسب فقط چون «در سیستم هست»
• فراموش‌کردن دسترسی‌پذیری در تعریف کامپوننت

چک‌لیست شروع سیستم دیزاین

1. تکراری‌ترین الگوهای محصول فهرست شده‌اند.
2. توکن‌های رنگ، فاصله و تایپ نام نقش دارند.
3. کامپوننت‌های پایه همهٔ حالت‌های ضروری را دارند.
4. قاعدهٔ استفاده برای طراح و توسعه‌دهنده نوشته شده است.
5. نام‌ها بین Figma و کد هم‌خوان‌اند.
6. حداقل یک صفحهٔ واقعی با سیستم بازسازی شده است.
7. مسیر درخواست جزء جدید و مالک آن مشخص است.
8. تغییر برند یا تم با چند نقطهٔ مرکزی ممکن است، نه با جست‌وجوی دستی.

جمع‌بندی: سیستم دیزاین زبان مشترک ساخت محصول است

سیستم دیزاین منبع حقیقت برای ظاهر، رفتار و استفادهٔ رابط است. UI Kit و استایل‌گاید بخشی از آن‌اند، اما جایگزین مستند، توکن و همگامی با کد نیستند. وقتی محصول و تیم رشد می‌کنند، سیستم از ناهماهنگی و بازکاری کم می‌کند؛ اگر زود و بیش از نیاز پیچیده شود، خودش مانع تحویل می‌شود.

از الگوهای تکراری شروع کنید، نام‌ها را با فرانت یکی کنید و سیستم را با استفاده در صفحهٔ واقعی زنده نگه دارید. هر جزء جدید باید یک مسئلهٔ تکراری را حل کند، نه اینکه سلیقهٔ یک صفحه را به کل محصول تحمیل کند. اگر الگویی فقط یک‌بار ظاهر می‌شود، اول همان صفحه را تمام کنید؛ ورود زودهنگام به سیستم، کتابخانه را شلوغ و اعتماد تیم را کم می‌کند. بازبینی فصلی برای حذف جزءهای بی‌استفاده به اندازهٔ افزودن جزء جدید مهم است.

سیستم سالم با محصول حرکت می‌کند: تغییر محتوا، breakpoint موبایل و نیاز دسترسی باید در توکن و کامپوننت دیده شود، نه با وصله در هر صفحه. وقتی تیم کوچک است، یک صفحهٔ مستند زنده بهتر از ویکی طولانیِ به‌روزنشده کار می‌کند. این صفحه باید مثال فارسی، حالت خطا و نسخهٔ موبایل را نشان دهد تا استفاده از سیستم حدس شخصی نباشد. برای طراحی سیستم متناسب با محصول شما، خدمات UI/UX روبینش و صفحه تماس در دسترس‌اند.