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

چرا سیستم‌های طراحی می‌میرند؟

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

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

سیستم طراحی با یک تصمیم بزرگ ساخته می‌شود؛ اما با صد تصمیم کوچک از بین می‌رود.

اشتباه اول: شروع از کامپوننت‌ها به‌جای اصول

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

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

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

وقتی توکن‌های طراحی متمرکز نباشند، همان رنگ در نقاط مختلف سیستم با کدهای متفاوت استفاده می‌شود. مثلاً رنگ اصلی برند در یک کامپوننت به‌صورت #2563EB و در کامپوننت دیگر به‌صورت #2563EC. این تفاوت کوچک، بعد از چند ماه به یک فاجعه بصری تبدیل می‌شود که حل کردنش به اندازه بازسازی سیستم زمان می‌برد. مشکل وقتی جدی‌تر می‌شود که در سطح کد هم نتوانید رنگ‌ها را با اطمینان مدیریت کنید.

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

اشتباه سوم: کامپوننت‌های تک‌منظوره و بی‌انعطاف

یکی از اشتباهاتی که در پروژه‌های تازه دیده‌ام، این است که کامپوننت‌ها با یک هدف بسیار مشخص ساخته می‌شوند. مثلاً یک کامپوننت کارت فقط برای نمایش محصولات خاص، یک کامپوننت هدر فقط برای صفحه اصلی. این کامپوننت‌ها در ظاهر کار می‌کنند اما در عمل بی‌انعطاف هستند. اگر فردا بخواهید همان کامپوننت را در صفحه دیگر استفاده کنید، نیاز به یک نسخه جدید دارید. در حالی که کامپوننت درست، از همان ابتدا با امکان تغییر تعریف می‌شود: اندازه‌های مختلف، حالت‌های مختلف، تنوع محتوا. این اصل در سیستم‌های طراحی حرفه‌ای، با استفاده از Variants و Slots پیاده‌سازی می‌شود.

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

کامپوننت خوب، یک تصمیم پیش‌فرض است؛ نه یک تصمیم نهایی.

اشتباه چهارم: نادیده‌گرفتن مستندسازی

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

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

اشتباه پنجم: نبود فرآیند نسخه‌بندی و تغییرات

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

راه‌حل، تعریف یک فرآیند مشخص برای تغییرات است: درخواست تغییر، بازبینی، اعمال، انتشار، و ارتباط به تیم. در Figma، این کار با قابلیت Branching و Version History امکان‌پذیر است. در کد، با ابزارهای کنترل نسخه مثل Git پیاده‌سازی می‌شود. اگر با نقش Git در پروژه‌های وردپرس آشنا نیستید، مقایسه Figma و Sketch بخشی از این موضوع را پوشش می‌دهد، اما تمرکز اصلی روی ابزارهای مدیریت نسخه سیستم طراحی است.

اشتباه ششم: طراحی بدون در نظر گرفتن توسعه‌دهنده

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

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

اشتباه هفتم: ساخت بدون تیم مالک

سیستم طراحی بدون یک تیم یا فرد مالک، محکوم به مرگ است. اگر همه در ساخت سیستم مشارکت داشته باشند اما هیچ‌کس مسئول نگهداری آن نباشد، سیستم بعد از چند ماه رها می‌شود. در تیم‌های حرفه‌ای، یک نقش مشخص به‌عنوان Design System Owner یا تیم کوچکی برای این کار تعریف می‌شود. این نقش، مسئول بررسی درخواست‌های تغییر، تصمیم‌گیری در مورد افزودن کامپوننت جدید، و ارتباط با تیم‌های دیگر است.

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

اشتباه هشتم: نادیده‌گرفتن دسترسی‌پذیری

دسترسی‌پذیری (Accessibility) یکی از آن موضوعاتی است که در ابتدای طراحی سیستم نادیده گرفته می‌شود و بعدها جبرانش بسیار پرهزینه است. اگر رنگ‌های سیستم با کنتراست پایین طراحی شوند، بعد از مدتی نمی‌توان به‌سادگی آن‌ها را تغییر داد چون همه‌جا استفاده شده‌اند. اگر ساختار HTML (HyperText Markup Language) کامپوننت‌ها از ابتدا استاندارد نباشد، رفع آن در بلندمدت به بازسازی کامپوننت‌ها منجر می‌شود.

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

دسترسی‌پذیری، یک ویژگی اضافه در سیستم طراحی نیست؛ بخشی از تعریف کامپوننت حرفه‌ای است.

اشتباه نهم: استفاده اجباری بدون انعطاف

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

راه‌حل، طراحی سیستمی است که ۸۰ درصد نیازهای تیم را پوشش دهد و برای ۲۰ درصد باقی‌مانده، مسیرهای خروج کنترل‌شده داشته باشد. این یعنی سیستم به‌جای تصمیم نهایی، تصمیم پیش‌فرض است. برای درک این تعادل، نگاهی به طراحی بصری چیست و چه اصولی دارد بیندازید؛ چرا که بخشی از این تعادل، از اصول طراحی بصری می‌آید. اگر سیستم طراحی در پروژه‌های برندینگ هم استفاده می‌شود، چگونه یک برند قوی بسازیم نگاه مکملی می‌دهد.

اشتباه دهم: نداشتن متریک موفقیت

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

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

پرسش‌های پرتکرار درباره اشتباهات Design System

چرا سیستم‌های طراحی در تیم‌های کوچک هم شکست می‌خورند؟

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

آیا می‌توانم کامپوننت‌ها را بدون مستندات هم داشته باشم؟

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

چگونه می‌توانم تیم را به استفاده از سیستم طراحی تشویق کنم؟

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

آیا اشتباهات یکسان در پروژه‌های وردپرس هم دیده می‌شود؟

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

چگونه از فروپاشی سیستم طراحی در بلندمدت جلوگیری کنیم؟

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

آیا سیستم طراحی باید با تغییرات برند هم‌گام باشد؟

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

آیا سیستم طراحی می‌تواند در پروژه‌های چندزبانه هم پیاده شود؟

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

سیستم طراحی زنده، یک انتخاب روزانه است

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

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