سیستم طراحی چیست؟ توکن، کامپوننت، حاکمیت و مقیاس

اگر طراح در Figma دکمه «اصلی» را آبی کند، توسعه‌دهنده همان دکمه را با رنگ دیگری بسازد و تیم پرداخت برای حالت Loading رفتاری جدا اختراع کند، مشکل کمبود UI Kit نیست؛ مشکل نبود قرارداد مشترک است. سیستم طراحی خوب قرارداد تصمیم، Token، رفتار، دسترس‌پذیری، کد، مستندات و مسیر تغییر را کنار هم نگه می‌دارد.

سیستم طراحی قرار نیست همه صفحه‌ها را شبیه هم یا تیم را کند کند. باید تکرار بی‌ارزش را کم کند تا طراح و توسعه‌دهنده وقتشان را صرف مسئله محصول کنند. اگر مالک، مصرف‌کننده، Governance و معیار Adoption ندارد، حتی زیباترین کتابخانه کامپوننت به موزه‌ای از نمونه‌های بلااستفاده تبدیل می‌شود.

سیستم طراحی چیست؟

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

سیستم طراحی «منبع واحد حقیقت» را فقط وقتی محقق می‌کند که منشأ هر تصمیم، نسخه و Artifact روشن باشد. یک فایل Figma و یک Package کد که دستی همگام می‌شوند، دو حقیقت واگرا هستند. بهتر است قرارداد Source-of-truth و Provenance تعریف شود: Tokenها از Registry نسخه‌پذیر تولید شوند، Design asset و Package همان Release را نشان دهند و Documentation نسخه مصرف‌شده را اعلام کند.

آیا واقعاً به سیستم طراحی نیاز دارید؟

سیستم طراحی برای هر تیمی ضرورت مطلق نیست. یک سایت بازاریابی کوچک با یک تیم و عمر محدود شاید با Style guide و چند Component تمیز بهتر اداره شود. سرمایه‌گذاری زمانی توجیه دارد که تکرار، چند تیم/محصول/پلتفرم، ناهماهنگی، Accessibility debt یا هزینه تغییر بالا باشد.

برای فهم مسئله کاربر، Journey و مرز UI/UX، راهنمای جامع تجربه کاربری را ببینید. سیستم طراحی فرایند تحقیق و طراحی محصول را حذف نمی‌کند؛ خروجی‌های تکرارپذیر آن را قابل‌استفاده مجدد می‌کند.

Snapshot استانداردها: ۱۹ مرداد ۱۴۰۵

این راهنما بر مبنای منابع رسمی موجود در ۱۰ اوت ۲۰۲۶ نوشته شده است. مشخصات Design Tokens Format Module 2025.10 اولین نسخه پایدار DTCG و Final Community Group Report است. خود سند صریح می‌گوید W3C Standard یا Recommendation Track نیست. پس برای Interoperability مفید و Production-ready است، اما برنامه سازگاری و Export را حفظ کنید.

سیستم طراحی را به‌عنوان Product اداره کنید

Consumerها کاربران سیستم‌اند. تیم سیستم طراحی باید Problem، Roadmap، Service level، Research، Support و Outcome داشته باشد. تعداد کامپوننت منتشرشده به‌تنهایی ارزش نیست؛ کامپوننتی که مصرف نمی‌شود یا Migration ندارد، هزینه نگهداری است.

Product brief یک‌صفحه‌ای

Audit فقط شمارش رنگ و دکمه نیست

Visual audit لازم است اما کافی نیست. Inventory باید Design، Code، رفتار، محتوا، Accessibility، Platform و Usage را پوشش دهد. Screenshot بدون Repository و Owner نشان نمی‌دهد کدام نسخه Production است.

آیتم‌ها را به «Canonical»، «Candidate merge»، «Local pattern»، «Deprecated» و «Unknown» تقسیم کنید. پیش از حذف، مصرف و وابستگی را بسنجید. Debt سیستم طراحی را می‌توان در همان Register و مدل ریسک راهنمای مدیریت بدهی فنی ثبت کرد.

اصل طراحی باید تصمیم را حل کند

«ساده، زیبا، انسانی» به‌تنهایی Principle عملی نیست. اصل خوب تعارض را حل می‌کند و Trade-off دارد: «شفافیت بر فشردگی»، «Recovery بر جلوگیری کامل از خطا» یا «دسترسی پیش‌فرض، نه افزونه». برای هر اصل مثال درست/نادرست و Evidence بنویسید.

معماری Token سه‌لایه

Token نامی انسانی برای یک تصمیم طراحی است. معماری سه‌لایه، مقدار خام را از معنا و نیاز Component جدا می‌کند:

Primitive: color.blue.600 = یک مقدار رنگ
Semantic: color.action.primary = {color.blue.600}
Component: button.background.default = {color.action.primary}

این سه‌لایه یک الگوی معماری سازمانی است؛ DTCG نام، Value، Type، Group، Alias، Composite، Extension و Deprecation را استاندارد می‌کند و شما را مجبور به نام‌گذاری Primitive/Semantic/Component نمی‌کند. لایه زیاد بدون نیاز، Indirection و Debug را سخت می‌کند؛ لایه کم نیز Theme و Migration را به Hardcode تبدیل می‌کند.

Primitive: مقدار بدون قصد محصول

رنگ، Spacing، Typography، Radius، Shadow، Duration، Easing و Z-index پایه‌اند. Scale باید محدود، دارای دلیل و قابل‌تبدیل میان پلتفرم‌ها باشد. نام blue-600 در Primitive قابل‌قبول است؛ مصرف مستقیم آن در Button معمولاً معنا را قفل می‌کند.

Semantic: قصد و نقش

surface.default، text.muted، border.focus و feedback.danger می‌گویند مقدار برای چه است. Dark mode یا Brand دوم عمدتاً این لایه را Override می‌کند. نام‌هایی مثل grayText با تغییر Theme دروغ می‌شوند؛ نام باید Purpose را بگوید.

Component: قرارداد محلی

وقتی Button واقعاً نیاز مستقل دارد، button.label.default یا button.border.focus به Semantic alias می‌شود. برای هر Property کامپوننت Token نسازید؛ فقط جایی که استقلال، Theme یا Extension لازم است. Component token نباید بهانه‌ای برای شکستن Semantic باشد.

نمونه DTCG ۲۰۲۵.۱۰

{
  "color": {
    "$type": "color",
    "blue-600": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0.145, 0.388, 0.922]
      }
    },
    "action-primary": {
      "$value": "{color.blue-600}"
    }
  }
}

در نسخه ۲۰۲۵.۱۰، Token حداقل $value دارد و Type باید صریح یا از Group/Alias قابل‌حل باشد. نام Token یا Group نباید با $ شروع شود یا نویسه‌های {، } و نقطه داشته باشد. $deprecated برای اعلام Deprecation و دلیل آن در خود Format وجود دارد.

یک منبع، چند خروجی پلتفرم

Registry Token باید به CSS variable، Android، iOS و فایل طراحی خروجی بدهد، اما خروجی‌ها همیشه یک‌به‌یک نیستند. Color space، Unit، Font availability، Shadow و Dynamic type تفاوت پلتفرم دارند. Transformها را Version و تست کنید؛ فایل Generated را دستی ویرایش نکنید.

Theme، Mode و Brand را مخلوط نکنید

Light/Dark یک Mode، Brand A/B یک Theme و Density یا High-contrast ممکن است Axis جدا باشد. ترکیب بی‌قاعده آن‌ها تعداد حالت‌ها را انفجاری می‌کند. Matrix پشتیبانی را مشخص و Pairهای Contrast را در هر Mode تست کنید.

قرارداد کامپوننت چه دارد؟

Component فقط ظاهر Default نیست. Contract خوب آناتومی، API، رفتار، State، Variant، محتوا، Accessibility، Responsive، RTL، داده، Performance، آزمون و Lifecycle را یکجا توضیح می‌دهد.

State matrix، نه Screenshot خوش‌حال

برای عناصر تعاملی، Default، Hover، Focus-visible، Active، Selected، Disabled، Read-only، Loading، Success، Warning، Error، Empty و Offline را بر حسب نیاز پوشش دهید. State فقط رنگ نیست؛ Behavior، ARIA، Cursor، Announcement و Recovery هم دارد.

Variant با State فرق دارد

Primary/Secondary/Destructive یا Compact/Comfortable Variant هستند؛ Hover/Error/Loading State. Propهای ترکیبی بی‌حد، حالت‌های نامعتبر می‌سازند. Matrix مجاز را محدود و Type-safe کنید. «Destructive + Loading + Disabled + Icon-only» باید رفتار تعریف‌شده یا ممنوع داشته باشد.

Pattern از Component بزرگ‌تر است

Form submission، Search/filter، Checkout، Empty state و Delete confirmation Pattern هستند و چند Component را با جریان، محتوا و Recovery ترکیب می‌کنند. سیستم طراحی باید مشخص کند چه زمانی Modal مناسب نیست، خطا کجا نمایش داده شود و Back چه رفتاری داشته باشد؛ نه فقط Pixel و Radius.

دسترس‌پذیری بخشی از Definition of Done

WCAG 2.2 توصیه رسمی W3C و معیار قابل‌آزمون برای Perceivable، Operable، Understandable و Robust است. برای Widgetهای پیچیده، ARIA Authoring Practices Guide Patternهای Keyboard و Semantics را نشان می‌دهد؛ اما Semantic HTML و آزمون با کاربر/فناوری کمکی را جایگزین نمی‌کند.

• Keyboard، Focus order و Focus not obscured را دستی تست کنید.
• Contrast متن، UI و Focus را در همه Modeها بسنجید.
• نام، Role، Value و State برنامه‌پذیر باشد.
• Error فقط با رنگ نشان داده نشود و Recovery داشته باشد.
• Zoom، Reflow، Text spacing و Target size بررسی شود.
• Motion به prefers-reduced-motion احترام بگذارد.

Storybook accessibility testing می‌تواند Violationهای خودکار را در Story و CI اجرا کند، اما نتایج Incomplete و خطاهای غیرقابل‌کشف خودکار نیازمند بررسی دستی‌اند. برای برنامه کامل، راهنمای طراحی فراگیر و ممیزی دسترس‌پذیری وب را بخوانید.

سیستم طراحی فارسی و RTL

RTL یک Flip تصویری ساده نیست. Typography فارسی، BiDi، اعداد و واحد، Iconهای جهت‌دار، فرم، تاریخ و پیام خطا باید در Contract و Storyهای واقعی باشند.

CSS Logical Properties مفاهیم inline-start/end و block-start/end را برای Writing mode تعریف می‌کند. در Token و Component از spacing.inline.start و Propertyهای منطقی استفاده کنید؛ بااین‌حال موقعیت فیزیکی واقعی مانند نمودار قطب‌نما یا کنترل ویدئو ممکن است Mirror نشود.

ماتریس QA فارسی

• فارسی RTL، انگلیسی LTR و محتوای Mixed-direction.
• رقم فارسی/لاتین، مبلغ ریال/تومان و جداکننده هزارگان.
• نام و نشانی بلند، کد پستی، موبایل و OTP.
• خطای چندخطی، Helper text و متن Button بلند.
• Desktop/Mobile، Zoom و Font fallback.
• Keyboard، Screen reader و ترتیب Focus در RTL.

Content guideline داخل سیستم طراحی

نام Component کافی نیست. Label، Error، Empty، Confirmation، تاریخ، مبلغ و لحن باید الگو داشته باشند. پیام «خطایی رخ داد» Recovery نمی‌دهد؛ قرارداد باید بگوید چه شد، کاربر چه کند و اگر حل نشد چه مسیری دارد. برای جلوگیری از فشار و فریب در CTA/Consent، راهنمای طراحی اخلاقی و دارک‌پترن مرز تصمیم است.

Design-to-code parity را قابل‌سنجش کنید

هم‌نام بودن Component در Figma و Code تضمین Parity نیست. Anatomy، Variant، State، Token reference و Version باید قابل نگاشت باشد. Drift report می‌تواند Design instance نامعتبر، Prop حذف‌شده، Token Hardcode و Package قدیمی را نشان دهد.

معماری Package و چند Framework

ساخت هم‌زمان React، Vue، Angular، Web Component، iOS و Android از روز اول اغلب Scope را می‌ترکاند. تصمیم بگیرید چه چیز مشترک و چه چیز Platform-native است:

• Token و Principle می‌توانند Platform-agnostic باشند.
• Behavior contract مشترک است، اما API و Implementation لزوماً نه.
• Headless primitive می‌تواند Logic/A11y را جدا کند، ولی هزینه دارد.
• Web Component همه تفاوت‌های Framework/SSR/Form را خودکار حل نمی‌کند.
• Package کوچک و Tree-shakeable بهتر از Bundle یکپارچه اجباری است.

Governance: چه کسی تصمیم می‌گیرد؟

برای هر تصمیم RACI بنویسید: Token owner، Component maintainer، Accessibility reviewer، Content owner، Release manager و Product sponsor. Governance نباید جلسه‌ای برای تأیید Pixel باشد؛ باید مسیر استاندارد، Fast path برای Bug، RFC برای تغییر بزرگ و SLA برای Review داشته باشد.

چه Contribution پذیرفته شود؟

معیار مشارکت GOV.UK Design System بر Useful و Unique بودن، Evidence استفاده و آزمون در Browser، فناوری کمکی و Device تأکید می‌کند. برای سازمان خود Gate مشابه بسازید:

1. نیاز چند مصرف‌کننده و نبود راه‌حل موجود اثبات شود.
2. Owner و هزینه نگهداری مشخص باشد.
3. Design، Content، Code، Docs و Test با هم تحویل شوند.
4. Accessibility، RTL، Responsive و Browser matrix بگذرد.
5. Migration و Support plan داشته باشد.

Lifecycle کامپوننت را شفاف کنید

Status باید در Design library، Documentation، Package و Changelog یکسان باشد. Component بدون Owner یا مصرف قابل‌اثبات، Candidate نگهداری ابدی نیست.

Versioning و تغییر شکسته

Semantic Versioning 2.0.0 Major/Minor/Patch را بر اساس سازگاری Public API تعریف می‌کند. در Design System، Public API فقط Prop نیست؛ DOM/Semantics، Token name، Visual contract، CSS selector، Behavior و Accessibility expectation نیز ممکن است Consumer را بشکند.

Deprecation مهربان

ابتدا جایگزین، دلیل و Deadline بدهید؛ Alias/Warning سازگار بسازید؛ Codemod و Migration guide منتشر کنید؛ مصرف را Telemetry یا Static analysis بسنجید؛ سپس در Major حذف کنید. «در Changelog نوشتیم» برنامه مهاجرت نیست.

Pipeline کیفیت و Release

Package یک‌بار Build، امضا و در محیط‌ها Promote شود؛ Changelog و Artifact قابل‌ردیابی بماند. الگوی Provenance، Canary و Rollback در راهنمای CI/CD امن آمده است.

Documentation باید تصمیم و Failure را توضیح دهد

صفحه هر Component حداقل Purpose، When to use/not use، Anatomy، API، State/Variant، Content، Accessibility، RTL/i18n، Responsive، Examples، Test، Version، Owner، Changelog و Migration را دارد. فقط Happy path و Copy code کافی نیست.

Adoption با اجبار ایجاد نمی‌شود

تیم محصول وقتی مهاجرت می‌کند که سیستم مسئله‌اش را حل کند، Integration کم‌هزینه باشد و Support واقعی بگیرد. ممنوع‌کردن هر UI محلی بدون Escape hatch، Shadow component و Fork پنهان می‌سازد.

مسیر Adoption

1. یک Journey پرهزینه و یک تیم شریک انتخاب کنید.
2. Componentهای هسته را در Feature واقعی Pilot کنید.
3. Gap و Local need را به Backlog سیستم برگردانید.
4. Template، CLI/Codemod و آموزش کوتاه بدهید.
5. Adoption و Defect را بسنجید، نه تعداد Install را.
6. پس از اثبات، Policy «reuse before create» اجرا کنید.

Escape hatch و Extension کنترل‌شده

سه سطح روشن کنید: Composition مجاز، Token override محدود و Fork ممنوع/نیازمند RFC. Consumer باید بتواند Layout یا Content محصول را بسازد، اما Semantics و Accessibility Component را نشکند. هر Escape باید دلیل و Expiry داشته باشد تا Debt نامرئی نشود.

ابزار را با Capability انتخاب کنید

Figma، Storybook، Zeroheight یا هر Vendor دیگر «استاندارد همیشگی» نیست. یک Pilot با Export/Import، دسترسی تیم ایرانی، هزینه ارزی، Offline/Backup، API، Lock-in و Exit انجام دهید. مستندات و Tokenهای اصلی را در قالب قابل‌بازیابی نگه دارید.

AI در سیستم طراحی

ابزار AI می‌تواند Component/Story/Test پیشنهاد دهد یا Code را با Tokenها تولید کند، اما باید فقط از Registry و API نسخه معتبر مصرف کند. Prompt آزاد که Hex، DOM و Pattern تازه اختراع می‌کند Drift را سریع‌تر می‌سازد. خروجی AI همان Review، Accessibility، Security، RTL و License gate را می‌گذراند و تصمیم تولیدشده Trace دارد.

ROI سیستم طراحی را چگونه بسنجیم؟

ادعای «۳۰ تا ۵۰ درصد سریع‌تر» بدون Baseline و روش، Business case نیست. ارزش را در چهار بُعد اندازه بگیرید:

منفعت تحقق‌یافته =
زمان تکرار حذف‌شده × هزینه ظرفیت قابل‌استفاده
+ هزینه Defect/Remediation اجتناب‌شده
منهای ساخت، نگهداری، مهاجرت و Tooling

قبل از Pilot Baseline بگیرید و تیم/Feature مشابه یا روند تاریخی را برای خلاف‌واقع نگه دارید. چارچوب کامل Contribution margin، Incrementality، Payback و NPV در راهنمای محاسبه ROI تجربه کاربری آمده است.

KPIهایی که رفتار بد نسازند

تعداد Component هدف بدی است و سیستم را باد می‌کند. Coverage بدون Quality نیز تیم را به Import صوری هل می‌دهد. Scorecard متوازن بسازید: Adoption معتبر، رضایت Consumer، Lead time، Defect، Accessibility، Migration latency، Support load و هزینه نگهداری.

Research مداوم با مصرف‌کننده

تیم Design System باید با طراح و توسعه‌دهنده مصاحبه، Task observation و Support-ticket review انجام دهد. Roadmap بر تعداد درخواست رأی‌خورده تنها بنا نشود؛ Frequency، Severity، Reuse potential و Strategic fit را ترکیب کنید. روش تصمیم داده‌آگاه در راهنمای UX داده‌آگاه مرجع مکمل است.

برنامه اجرایی ۹۰روزه

اشتباه‌های رایج

• شروع با ساخت همه Componentها به‌جای یک Journey واقعی.
• یکسان‌گرفتن Figma library، Component library و Design System.
• استفاده مستقیم Primitive در Component و شکست Theme.
• ساخت Token برای هر Pixel بدون Semantic purpose.
• مستندسازی فقط ظاهر Default و حذف Error/Loading/RTL.
• تکیه کامل بر تست خودکار Accessibility.
• اعلام SemVer بدون تعریف Public contract واقعی.
• حذف Prop/Token بدون Deprecation، Codemod و Migration.
• اندازه‌گیری ارزش با تعداد Component یا Download.
• Governance بدون Owner، بودجه، SLA و مسیر مشارکت.
• اجبار مصرف بدون Support و Escape hatch.
• وابستگی Vendor بدون Export، Backup و Exit.

چک‌لیست Production-ready

• Product brief، Scope، Consumer و Sponsor مشخص‌اند.
• Audit طراحی، کد، Usage، Behavior، A11y و RTL انجام شده است.
• Tokenهای Primitive→Semantic→Component Version و Validate می‌شوند.
• Design و Code از Release/Contract قابل‌ردیابی پیروی می‌کنند.
• هر Component Anatomy/API/State/Content/A11y/RTL/Test دارد.
• Governance، RACI، Contribution و SLA روشن‌اند.
• Lifecycle از Exploratory تا Retired نمایش داده می‌شود.
• SemVer، Deprecation، Migration و Rollback آزموده‌اند.
• CI شامل Interaction، Visual، A11y، RTL و Performance است.
• Adoption، Drift، Defect، Lead time و هزینه نگهداری سنجیده می‌شوند.
• Tooling برای دسترسی ایران، Export، Backup و Exit بررسی شده است.

پرسش‌های متداول

تفاوت سیستم طراحی با UI Kit چیست؟

UI Kit مجموعه Assetهای طراحی است. سیستم طراحی علاوه بر Asset، Token، Component کدنویسی‌شده، Behavior، Accessibility، Pattern، Documentation، Versioning، Governance و فرایند مشارکت/مهاجرت دارد. UI Kit می‌تواند بخشی از سیستم باشد.

آیا تیم کوچک به Design System نیاز دارد؟

نه همیشه. اگر یک محصول ساده و تکرار کم دارید، Style guide و چند Component تمیز کافی است. وقتی چند تیم/پلتفرم، تکرار، Accessibility debt یا هزینه تغییر زیاد شد، Minimum viable design system را روی یک Journey پرتکرار Pilot کنید.

Design Token چیست؟

Token یک تصمیم طراحی نام‌دار با Value و Type است که میان ابزار و پلتفرم قابل‌اشتراک است. معماری سه‌لایه مقدار Primitive را به نقش Semantic و نیاز Component وصل می‌کند؛ مثلاً Blue-۶۰۰ → Action-primary → Button-background.

چگونه Design System را برای فارسی و RTL بسازیم؟

از CSS logical properties، Tokenهای start/end، فونت و Line-height آزموده، Storyهای BiDi و Label بلند، Formatter عدد/ارز و قواعد Mirror آیکون استفاده کنید. Keyboard، Focus و Screen reader را در RTL واقعی تست کنید؛ Flip خودکار همه اجزا کافی نیست.

موفقیت سیستم طراحی را با چه KPI بسنجیم؟

Adoption معتبر، زمان ساخت Pattern تکراری، UI/A11y defect، Design-code drift، Migration latency، رضایت Consumer، Support load و هزینه نگهداری را کنار هم ببینید. تعداد Component یا Download به‌تنهایی Outcome نیست و ROI باید هزینه ساخت/مهاجرت را کسر کند.

جمع‌بندی: سیستم طراحی، قرارداد تغییر است

ارزش سیستم طراحی در Palette زیبا یا تعداد Component نیست؛ در این است که یک تصمیم درست را بتوان با کیفیت ثابت، دسترس‌پذیر و قابل‌ردیابی در چند محصول تکرار و سپس بدون آشوب تغییر داد. Token سه‌لایه، Contract کامپوننت و Pipeline کیفیت ستون فنی آن‌اند؛ Governance، Support و Migration ستون عملیاتی.

کوچک شروع کنید: یک Journey، چند Component و یک تیم شریک. وقتی Adoption و Outcome واقعی را دیدید، Scope را گسترش دهید. سیستمی که مصرف‌کننده‌اش را می‌شناسد و هزینه تغییر را مدیریت می‌کند، دارایی سازمان است؛ سیستمی که فقط مستندات دارد، پروژه‌ای نیمه‌تمام.