شما به سیستم طراحی نیاز ندارید
بیشتر تیم‌هایی که یک سیستم طراحی منتشر می‌کنند فقط ادای بلوغ درمی‌آورند. هزینه نگهداری از سود جلو می‌زند، تولید با هوش مصنوعی حساب‌وکتاب را به هم می‌ریزد و ترکیب توکنها، پریمیتیوها و ذوق برای ۹۵٪ سازمان‌ها از یک سیستم کاملاً مستندشده بهتر است.
احتمالاً به سیستم طراحی نیاز ندارید. چیزی که لازم دارید چند توکن طراحی، یک کتابخانه کامپوننت کوچک و یک نفر در تیم با ذوق خوب است. آن چیزی که اکانت طراحی مورد علاقه‌تان در توییتر مدام درباره‌اش پست می‌گذارد، یعنی فایل Figma با ۴۰۰ کامپوننت منتشرشده و ۱۲ تم، یک محصول تمام‌وقت است که استارتاپ هشت‌نفره شما هزینه‌اش را میدهد و هیچ سودی از آن نمی‌برد.
این حرفی است که همه در این صنعت می‌دانند درست است و هیچ‌کس بلند نمی‌گوید. صورتحساب نگهداری واقعی است. سود آن بیشتر خیالی است. و هوش مصنوعی فاصله این دو را بدتر کرده است.
آن ۹۵٪ تیم‌هایی که سیستم طراحی منتشر می‌کنند فقط دارند ادای بلوغ درمی‌آورند. آن ۵٪ که واقعاً به آن نیاز دارند معمولاً همان تیم‌هایی نیستند که این سؤال را می‌پرسند.
سیستم طراحی یک محصول است، نه یک ماجراجویی فرعی
یک سیستم طراحی واقعی نقشه راه خودش، changelog خودش و مشتری‌های خودش را دارد. این مشتری‌ها مهندسان و طراحانی هستند که محصول اصلی را می‌سازند. اگر هیچ‌کس برای نگهداری سیستم نیرو نداشته باشد، آن یک سیستم نیست. یک عکس لحظه‌ای است.
ببینید چه کسانی سیستم طراحی را خوب منتشر می‌کنند. Stripe یک تیم زیرساخت طراحی اختصاصی دارد. Shopify Polaris سازمان مخصوص خودش را دارد. GitHub Primer یک ریپوی عمومی با نسخه‌بندی دارد.
Atlassian سال‌ها روی سیستمی سرمایهگذاری کرده که بیشتر تیمها هرگز به وسعت آن نمی‌رسند. هر کدام از اینها یک تیم محصولی است که برای هزاران مشتری داخلی ابزار می‌سازد.
حالا نسخه معمولی را ببینید. یک طراح ارشد شش هفته در Figma وقت گذاشت، ۸۰ کامپوننت منتشر کرد، یک صفحه Notion نوشت که هیچ مهندسی نمی‌خواند و دو تم تحویل داد. شش ماه بعد نیمی از کامپوننتها قدیمی شده‌اند، توکنها از کدبیس فاصله گرفته‌اند و تیم دوباره دارد کلاس‌های Tailwind را کپی می‌کند. سیستم شکست نخورد. تیم نتوانست برایش نیرو بگذارد.
صورتحساب نگهداری که هیچ‌کس در اسلایدها نمی‌گذارد
پیشنهاد سود این است: یک بار بسازید، برای همیشه استفاده کنید. حساب واقعی این است: یک بار بسازید، بعد برای همیشه نگهداری کنید و گاهی از بخشی از آن استفاده کنید.
هر توکن طراحی باید بین Figma و کد همگام بماند. هر واریانت کامپوننت باید هنگام ارتقای فریمورک تست شود. هر تغییر شکننده در Radix یا React یا Tailwind در همه محصولات وابسته موج می‌اندازد. مستندات ظرف یک فصل می‌پوسند.
نمونه Storybook با یک ارتقای وابستگی خراب می‌شود و سه هفته کسی متوجه نمی‌شود. کتابخانه Figma منتشرشده یک ریلیز از کدبیس عقب می‌ماند. تم‌ها از هم دور میشوند. کامپوننت‌های سیستم همان کامپوننت‌های محصول نیستند.
حساب صادقانه این است. یک «سیستم» شش‌کامپوننتی می‌تواند وقت واقعی صرفه‌جویی کند. یک سیستم ۲۰۰ کامپوننتی در شرکتی ۱۲ نفره یک مالیات است. ساعتهای سود خطی‌اند، ساعتهای نگهداری انباشته میشوند و در یک نقطه خطوط همدیگر را قطع می‌کنند. بیشتر تیمها بی‌آنکه بفهمند از این نقطه رد میشوند، چون نگهداری به شکل پیام‌های Slack بعدازظهر جمعه ظاهر می‌شود، نه یک ردیف در صورت سود و زیان.
تولید با هوش مصنوعی حساب را فروپاشاند
تمام استدلال له سیستم طراحی روی یک عدد بنا شده بود: هزینه تولید یک کامپوننت جدید با استایل خوب. آن عدد حالا یک خطای گرد کردن است.
یک مهندس جونیور می‌تواند بنویسد «یک صفحه تنظیمات با سایدبار، سه بخش و یک نوار ذخیره بده که از الگوی حالت بارگذاری پیروی کند» و ظرف بیست دقیقه یک کامپوننت کارا تحویل بدهد. v0 به‌طور پیش‌فرض خروجی به سبک Shadcn تولید می‌کند. Cursor و Claude می‌توانند یک جریان کامل را بر پایه پریمیتیوهای موجود بازنویسی کنند. سودی که سیستم طراحی می‌داد، یعنی تولید سریع UI با ظاهر یکدست، حالا خدمتی رایگان است که هر IDE بازار ارائه می‌کند.
مالیات سیستم تغییر نکرد. سود فروپاشید. کل ماجرا همین است. تیم‌هایی که در ۲۰۲۲ برای خروجی سریع‌تر سیستم طراحی ساختند حالا از تیم‌هایی که Shadcn بهعلاوه Tailwind بهعلاوه یک پرامپت تحویل میدهند کندترند، چون هر ابزار هوش مصنوعی روی گزینه دوم آموزش دیده و اولی را نادیده می‌گیرد.
آن ۵٪ که واقعاً به سیستم طراحی نیاز دارند
یک سیستم طراحی واقعی فقط وقتی هزینه خودش را درمی‌آورد که مجموعهای مشخص از شرایط همگی برقرار باشند. یکی کم باشد، حساب فرو می‌ریزد.
- چند محصول با یک هویت مشترک. Atlassian دارای Jira، Confluence، Trello و ده‌ها محصول دیگر است. یک هویت، سطوح فراوان. سیستم لایه یکپارچه‌سازی است.
- نیروی انسانی در حد صدها نفر، نه ده‌ها نفر. زیر ۵۰ مهندس محصول، هر کامپوننت یک پیام Slack تا رفع مشکل فاصله دارد. بالای ۲۰۰ نفر این روش جواب نمی‌دهد و سیستم تنها راه می‌شود.
- یک تیم design ops یا زیرساخت طراحی با نیروی مشخص. سیستم طراحی بدون مالک یک قبرستان است. مالک باید یک نقش واقعی باشد، نه پروژه ۲۰٪ وقت.
- مصرفکنندگان بیرونی. سیستم‌های طراحی متن‌باز مثل GitHub Primer یا Shopify Polaris محصولاتی هستند که توسعه‌دهندگان بیرونی هم با آنها کار می‌کنند. هزینه نگهداری با پذیرش بیرونی توجیه می‌شود.
- حوزه‌ای مقرراتمحور یا حساس به دسترس‌پذیری. سلامت، مالی، دولتی. سیستم انطباق و آمادگی ممیزی را در خود کدگذاری می‌کند، سودی که هیچ تیم تکی نمی‌تواند تکرار کند.
اگر تیمی هر پنج مورد را دارد، سیستم طراحی تصمیم درستی است. اگر یکی دو مورد را دارد و یک محصول با ۴۰ مهندس تحویل میدهد، سیستم طراحی کاستیوم است. مطلب ضد داشبورد الگویی مرتبط را بررسی می‌کند: ساختن زیرساخت برای اندازه‌ای از سازمان که هنوز به آن نرسیده‌اید.
حداقل سیستم بصری قابل‌استفاده
برای آن ۹۵٪، پاسخ یک استک سه‌لایه است که نگهداری‌اش تقریباً هیچ هزینه‌ای ندارد و تقریباً همان خروجی را میدهد.
| لایه | چیست | ابزارها | هزینه نگهداری |
|---|---|---|---|
| توکنها | رنگ، تایپوگرافی، فاصله‌گذاری، شعاع و سایه به‌صورت متغیر | Tailwind config، CSS variables، متغیرهای Figma | کم. یک فایل. هر فصل یک‌بار به‌روزرسانی. |
| پریمیتیوها | کامپوننت‌های headless یا استایل‌دار، دسترس‌پذیر به‌صورت پیش‌فرض | Shadcn، Radix، Headless UI، پریمیتیوهای Cal.com | کم. داخل پروژه کپی میشوند، نگهداری نمی‌شوند. هر وقت لازم شد به‌روزرسانی. |
| ذوق | کسی که می‌داند چه وقت قواعد را بشکند | طراح ارشد یا مهندس آشنا با طراحی | رایگان اگر خوب استخدام کنید، بی‌نهایت اگر نکنید. |
کل استک همین است. توکنها یکدستی میدهند. پریمیتیوها دسترس‌پذیری و رفتار میدهند. ذوق لایه‌ای را میدهد که هیچ سیستمی نمی‌تواند کدگذاری‌اش کند: قضاوت درباره اینکه قواعد کی باید خم شوند.
تیم‌هایی که در ۲۰۲۶ تمیزترین محصولات را تحویل میدهند از نسخه‌ای از همین استفاده می‌کنند. Linear روی یک مجموعه توکن کوچک، پریمیتیوهای سفارشی و ذوقی وسواسی کار می‌کند. Vercel یک Tailwind config سنگین بهعلاوه پریمیتیوهای خودش منتشر می‌کند.
Cal.com پریمیتیوهایش را عمومی منتشر می‌کند. Resend و Loops رابط به سبک Shadcn را با توکن‌های اختصاصی روی آن تحویل میدهند.
Notion روی مجموعه کوچکی از توکنها و واژگان عمداً محدود کامپوننتها کار می‌کند. هیچ‌کدام از اینها «سیستم طراحی» به معنای Atlassian ندارند. همه‌شان یک استک سایت بازاریابی دارند که از شرکت‌هایی ده برابر بزرگ‌تر منسجم‌تر به نظر می‌رسد.
چرا Shadcn دارد دسته سیستم طراحی را می‌بلعد
Shadcn یک کتابخانه کامپوننت نیست. یک مکانیسم تحویل برای پیش‌فرض جدید است. پریمیتیوها داخل کدبیس کپی میشوند، با Tailwind استایل می‌خورند و چون Radix زیرشان کار سنگین را انجام میدهد دسترس‌پذیرند. کاربر مالک کامپوننت‌هاست، آزادانه ویرایششان می‌کند و هرگز منتظر ریلیزهای بالادستی نمی‌ماند.
این ضربه نهایی به بیشتر سیستم‌های طراحی داخلی است. دلیل اینکه تیمها قبلاً سیستم خودشان را می‌ساختند کنترل بود. Shadcn کنترل را رایگان میدهد. دلیل اینکه تیمها Storybook منتشر می‌کردند قابلیت کشف بود.
Shadcn مستنداتش را عمومی منتشر می‌کند و ابزارهای هوش مصنوعی آنها را ایندکس می‌کنند. دلیل اینکه تیمها کتابخانه Figma منتشر می‌کردند یکدستی بود. پریمیتیوهای Shadcn آن‌قدر یکدست هستند که هر پرامپتی علیه آنها خروجی‌ای میدهد که تیم از قبل می‌داند چطور ارزیابی‌اش کند.
Shadcn بهعلاوه Tailwind بهعلاوه یک مجموعه توکن، استک بصری پیش‌فرض ۲۰۲۶ است. این همان چیزی است که هر ابزار تولید کد با هوش مصنوعی به‌طور پیش‌فرض می‌سازد. همان چیزی است که هر تیم محصول جدید اول از همه تحویل میدهد. مدل پریمیتیو بهعلاوه ذوق است در دو ریپو و یک فایل کانفیگ. سیستم طراحی به‌عنوان یک artifact جداگانه، با پایپ‌لاین انتشار و تیم خودش، حالا حالت استثنا است.
چه وقت یک سیستم واقعی بالاخره خرجش را درمی‌آورد
نسخه صادقانه سؤال «آیا به سیستم طراحی نیاز داریم؟» این است: «آیا هنوز از آستانه نگهداری رد شده‌ایم؟»
| نشانه | به سیستم نیاز هست؟ |
|---|---|
| دو مهندس در یک هفته دکمه‌های ناهمسان تحویل میدهند | نه. یک فایل توکن اضافه کنید. |
| سه محصول یک برند دارند و از نظر بصری از هم دور میشوند | شاید. با توکن‌های مشترک شروع کنید. |
| چند تیم هر فصل یک کامپوننت یکسان را متفاوت تحویل میدهند | بله. وقت پریمیتیوهای مشترک است. |
| یک کامپوننت مشخص در شش ماه توسط چهار تیم از نو ساخته شده | بله. آن را به سیستم ارتقا دهید. |
| آشنا کردن یک طراح جدید دو هفته طول می‌کشد چون قراردادها شفاهی و قبیله‌ای است | بله. حالا سیستم سود دارد. |
| توسعه‌دهندگان بیرونی از کامپوننت‌های شما استفاده می‌کنند | بله. سیستم یک محصول است. |
| ممیزی انطباق یا دسترس‌پذیری روی نقشه راه شما افتاده | بله. یک بار کدگذاری‌اش کنید. |
اگر تیمی سه نشانه یا بیشتر از اینها را دارد، سیستم واقعی توجیه دارد. اگر یکی دارد، یک فایل توکن کافی است. همین منطق در مسئله صفحه قیمت‌گذاری و آنبوردینگ بدون آنبوردینگ هم دیده می‌شود، که هماهنگی را در سطح رابط حل می‌کنند نه در سطح سیستم.
الگو، و بعد پانچ‌لاین
نمایش بلوغ وارونه است. تیم‌هایی که در ۲۰۲۶ منسجم‌ترین محصولات را تحویل میدهند آنهایی نیستند که بزرگ‌ترین سیستم طراحی را دارند. آنهایی هستند که کوچک‌ترین بدهی بصری را دارند. یک مجموعه توکن فشرده، لایه پریمیتیو نازک و طراحی با ذوق که زیاد نه می‌گوید.
سیستم‌های طراحی واقعی زیرساخت سازمان‌هایی هستند که از جایگزین‌شان بزرگ‌تر شده‌اند. نقطه عطفی نیستند که هر تیمی باید به آن برسد. نماد منزلت نیستند. جواب «می‌خواهیم حرفه‌ای‌تر به نظر برسیم» نیستند.
تیمی که پیش از کسب بودجه نگهداری یکی بسازد همان محصول را روی ساعتی کندتر با فایلی سنگین‌تر تحویل میدهد. تیمی که توکن بهعلاوه Shadcn بهعلاوه ذوق تحویل میدهد همان محصول را روی ساعتی سریع‌تر تحویل میدهد و وقت صرفهجوییشده را خرج مسئله صفحه تنظیمات می‌کند.
سؤال این نیست که «آیا سیستم طراحی داریم؟» سؤال این است که «آیا روی سطح درستی از انتزاع هزینه نگهداری می‌دهیم؟»
FAQ
تفاوت سیستم طراحی و کتابخانه کامپوننت چیست؟
کتابخانه کامپوننت مجموعهای از اجزای UI قابل استفاده مجدد است. سیستم طراحی یک کتابخانه کامپوننت است بهعلاوه توکنها، مستندات، حاکمیت، یک مالک و یک ریتم انتشار. بیشتر تیمها یک کتابخانه کامپوننت تحویل میدهند و اسمش را سیستم میگذارند. این دو یکی نیستند و دومی هزینه نگهداریای دارد که اولی ندارد.
آیا Shadcn یک سیستم طراحی است؟
نه. Shadcn یک مکانیسم تحویل پریمیتیو است. کامپوننتها داخل کدبیس کپی میشوند و مالکشان تیم است. نه کتابخانه مرکزی هست، نه برنامه ریلیز بالادستی، نه حاکمیت.
همین نکته اصلی است. سود یک سیستم را بدون صورتحساب نگهداری به تیم میدهد.
یک استارتاپ چه وقت باید روی سیستم طراحی سرمایهگذاری کند؟
وقتی دستکم سه مورد از اینها برقرار باشد: چند محصول با هویت مشترک، پنجاه مهندس یا بیشتر که UI تحویل میدهند، یک نقش design ops با نیروی مشخص، مصرفکنندگان بیرونی کامپوننتها، یا یک حوزه مقرراتمحور. زیر این سطح، توکن بهعلاوه پریمیتیو بهعلاوه ذوق تحویل بدهید و ساعتهای صرفهجوییشده را روی خود محصول بگذارید.
CTA
محصولی می‌خواهید که سیستم بصری‌اش با اندازه تیم بخواند؟ Brainy برای آن ۹۵٪ استک توکن بهعلاوه پریمیتیو و برای آن ۵٪ سیستم طراحی کامل تحویل میدهد، متناسب با بودجه نگهداری واقعی. Brainy را استخدام کنید. پیش از آنکه یک فصل را روی artifact اشتباه خرج کنید، به شما می‌گوییم در کدام سمت خط ایستاده‌اید.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
