Atomic Design — مبانی، اتمها، مولکولها و ارگانیسمها در UI
توضیح میدهیم Atomic Design چیست — متدولوژی طراحی رابط کاربری که توسط برد فراست در سال ۲۰۱۳ ارائه شده و از استعاره اتمها، مولکولها و ارگانیسمها برای ساخت سلسلهمراتب کامپوننتهای UI استفاده میکند. برخلاف رویکرد صفحهمحور که در آن رابط کاربری صفحه به صفحه طراحی میشود، Atomic Design رابط کاربری را به کوچکترین عناصر قابل استفاده مجدد (اتمها) تقسیم کرده و ساختارهای پیچیدهتری از آنها میسازد. به گفته برد فراست (۲۰۱۶)، این متدولوژی در سیستمهای طراحی ۶۷٪ از شرکتهای بزرگ از جمله IBM، Airbnb و Google استفاده میشود.
نکات اصلی
- Atomic Design — متدولوژی تقسیم کامپوننتهای UI به پنج سطح: اتمها، مولکولها، ارگانیسمها، الگوها و صفحات.
- اتمها — عناصر پایه HTML (دکمه، فیلد ورودی، برچسب)؛ مولکولها — ترکیب اتمها (فیلد ورودی با برچسب)؛ ارگانیسمها — بلوکهای پیچیده (فرم ورود).
- متدولوژی توسط برد فراست در سال ۲۰۱۳ ارائه و در کتاب «Atomic Design» (۲۰۱۶) شرح داده شده است.
- Atomic Design اساس سیستمهای طراحی مدرن را تشکیل میدهد: Material Design، Carbon (IBM)، Lightning (Salesforce).
- در توسعه موبایل، Atomic Design با فریمورکهای کامپوننتی — Jetpack Compose و SwiftUI — ادغام میشود که در آن کامپوننتهای سفارشی به طور طبیعی اتمها و مولکولها را توصیف میکنند.
Atomic Design چیست؟
Atomic Design — متدولوژی ایجاد سیستمهای رابط کاربری سلسلهمراتبی که در آن هر عنصر UI به یکی از پنج سطح تعلق دارد: اتمها (عناصر پایه)، مولکولها (ترکیب اتمها)، ارگانیسمها (بلوکهای پیچیده)، الگوها (چارچوبهای صفحات) و صفحات (صفحات مشخص با داده). این تشبیه از شیمی گرفته شده است: اتمها در مولکولها، مولکولها در ارگانیسمها، ارگانیسمها در الگوها ترکیب میشوند و الگوها با محتوا پر شده و به صفحات تبدیل میشوند.
این متدولوژی توسط طراح وب برد فراست در سال ۲۰۱۳ به عنوان پاسخی به مشکل «تفکر صفحهای» ارائه شد — زمانی که هر صفحه جدید بدون در نظر گرفتن کامپوننتهای موجود از صفر طراحی میشود. در کتاب «Atomic Design» (۲۰۱۶) فراست پیادهسازی این متدولوژی در پروژههای شرکتهای بزرگ IBM، GE و Starbucks را شرح میدهد. به گفته Nielsen Norman Group (۲۰۲۲)، Atomic Design زمان طراحی صفحات جدید را به دلیل استفاده مجدد از کامپوننتهای آماده ۳۰–۵۰٪ کاهش میدهد.
Atomic Design — بیشتر یک فلسفه سازماندهی UI است تا یک فناوری. این متدولوژی به فریمورک خاصی وابسته نیست و هم در وب (React, Vue) و هم در توسعه موبایل (Jetpack Compose, SwiftUI) قابل کاربرد است. در IT Sectr ما از Atomic Design برای ساخت سیستمهای طراحی مشتریان استفاده میکنیم: کامپوننتهای اتمی را در مرحله طراحی جدا کرده و به کامپوننتهای کد Compose/SwiftUI منتقل میکنیم.
پنج سطح: اتمها، مولکولها، ارگانیسمها، الگوها، صفحات
هر سطح از Atomic Design وظیفه خود را حل کرده و حوزه مسئولیت مشخصی دارد. اتمها — کوچکترین بلوکهای سازنده رابط کاربری که بدون از دست دادن معنا نمیتوان بیشتر تقسیم کرد: دکمه، فیلد متنی، آیکون، برچسب، چکباکس. اتمها حاوی منطق تجاری نیستند و به زمینه وابسته نیستند. آنها ویژگیهای بصری پایه را تعیین میکنند: رنگ، اندازه، فاصلهها، تایپوگرافی.
مولکولها — ترکیب دو یا چند اتم که واحدهای عملکردی ساده را تشکیل میدهند. فیلد ورودی با برچسب و پیام خطا — مولکول. کارت محصول با تصویر، نام و قیمت — مولکول. مولکولها میتوانند منطق پایه داشته باشند (نمایش/مخفی کردن خطا)، اما حاوی فرآیندهای تجاری نیستند. مولکولها اولین سطحی هستند که کامپوننتها بین صفحات مختلف قابل استفاده مجدد میشوند.
ارگانیسمها — بلوکهای پیچیده رابط کاربری متشکل از مولکولها و اتمها که عملکرد خاصی از برنامه را پیادهسازی میکنند. فرم ورود (فیلد ایمیل، فیلد رمز عبور، دکمه ارسال، لینک «رمز عبور را فراموش کردهام») — ارگانیسم. هدر با لوگو، جستجو و ناوبری — ارگانیسم. ارگانیسمها میتوانند حاوی منطق تجاری بوده و به API دسترسی داشته باشند، اما فقط در چارچوب عملکرد خود.
الگوها — چارچوبهای صفحات که موقعیت ارگانیسمها را روی صفحه بدون محتوای مشخص تعیین میکنند. الگو شبکه، ستونها و مناطق محتوا را مشخص میکند — وایرفریم در سطح کد. الگوها حاوی داده نیستند، فقط placeholders. آنها امکان ارزیابی ساختار صفحه قبل از پر شدن با محتوا را فراهم میکنند.
صفحات — صفحات مشخص برنامه که در آن الگو با دادههای واقعی پر شده است. در این سطح بررسی میشود که کامپوننتها با محتوای واقعی چگونه به نظر میرسند (رشتههای طولانی، عدم وجود داده، خطاها). صفحات تنها سطحی هستند که کاربر نهایی میبیند. تغییرات در سطح صفحات نباید روی اتمها، مولکولها و ارگانیسمها تأثیر بگذارد — اگر کامپوننتی نیاز به تغییر دارد، تغییر در سطح آن اعمال میشود و صفحه به طور خودکار آن را دریافت میکند.
مزایا و محدودیتهای Atomic Design
مزایا Atomic Design در مقیاسپذیری رابطهای کاربری آشکار میشود. کتابخانه واحد کامپوننتها سازگاری بصری را تضمین میکند: دکمه در همه صفحات یکسان به نظر میرسد زیرا همان اتم است. به گفته برد فراست (۲۰۱۶)، شرکتهایی که Atomic Design را پیادهسازی کردهاند، زمان توسعه صفحات جدید را به دلیل استفاده مجدد از مولکولها و ارگانیسمهای آماده ۳۰–۵۰٪ کاهش میدهند.
| ویژگی | Atomic Design | رویکرد صفحهای |
|---|---|---|
| استفاده مجدد از کامپوننتها | زیاد (اتمها، مولکولها، ارگانیسمها) | کم (هر صفحه از صفر) |
| سازگاری بصری | تضمین شده | کنترل دستی |
| سرعت ایجاد صفحه جدید | زیاد (مونتاژ از بلوکهای آماده) | کم (طراحی + کدنویسی از صفر) |
| پیچیدگی پیادهسازی | زیاد (نیاز به کاتالوگ کامپوننت) | کم (مدل آشنا) |
| قابلیت تست | زیاد (هر اتم جدا شده) | یکپارچه (کل صفحه یکباره) |
محدودیتها — Atomic Design نحوه مدیریت وضعیت برنامه را توصیف نمیکند. این متدولوژی فقط به سؤال «چگونه کامپوننتهای UI را سازماندهی کنیم» پاسخ میدهد، اما به منطق تجاری، مسیریابی و کار با داده نمیپردازد. محدودیت دوم — دشواری تعیین مرزها: مولکول کجا تمام میشود و ارگانیسم کجا آغاز میشود؟ در عمل مرزها مبهم هستند و تیمهای مختلف ممکن است یک کامپوننت را متفاوت طبقهبندی کنند. توصیه میشود قوانین را در توکنهای طراحی و کاتالوگ کامپوننت (Storybook, Jetpack Compose Preview) ثابت کنید.
محدودیت سوم — انتزاع بیش از حد برای پروژههای کوچک. اگر برنامه از ۵ صفحه تشکیل شده باشد، ایجاد سلسلهمراتب اتمها و مولکولها کار اضافی است. Atomic Design زمانی سودآور میشود که تعداد صفحات از ۲۰ بیشتر باشد و کامپوننتها در صفحات مختلف استفاده مجدد شوند.
Atomic Design در مقابل Feature-Sliced Design
Atomic Design و Feature-Sliced Design (FSD) وظایف متفاوتی را حل میکنند و میتوانند با هم استفاده شوند. Atomic Design متدولوژی سازماندهی کامپوننتهای UI است، FSD — متدولوژی سازماندهی لایههای تجاری و کل برنامه. Atomic Design به سؤال «چگونه UI را به بخشهای قابل استفاده مجدد تقسیم کنیم» پاسخ میدهد، FSD — «چگونه کد را حول ویژگیهای تجاری سازماندهی کنیم». آنها رقیب نیستند: میتوان ساختار FSD با لایههای features و entities داشت و در داخل هر لایه از Atomic Design برای سازماندهی کامپوننتهای UI استفاده کرد.
| معیار | Atomic Design | Feature-Sliced Design |
|---|---|---|
| حوزه | کامپوننتهای UI | معماری برنامه |
| واحد گروهبندی | استعاره شیمیایی (اتم → مولکول → ارگانیسم) | ویژگی تجاری (برش) |
| وابستگیها | از اتمها به صفحات (از پایین به بالا) | از app به shared (از بالا به پایین) |
| کار با داده | توصیف نشده | از طریق بخشهای model + api |
| مقیاسپذیری | افقی (کامپوننتهای بیشتر) | عمودی (ویژگیهای بیشتر) |
ترکیب معمول: FSD ساختار ماژولار برنامه (لایهها، برشها) را تعریف میکند، Atomic Design — ساختار داخلی کامپوننتهای UI درون هر برش. به عنوان مثال، برش feature.auth شامل مولکولها (LoginForm, PasswordInput) و ارگانیسمها (AuthPage) است که طبق قوانین Atomic Design ساخته شدهاند. لایه shared شامل اتمها (Button, Input, Label) است که در همه ویژگیها قابل استفاده مجدد هستند.
Atomic Design در برنامههای موبایل: Compose و SwiftUI
Jetpack Compose و SwiftUI به طور طبیعی از سلسلهمراتب Atomic Design از طریق ترکیب کامپوننتها پشتیبانی میکنند. اتمها در Compose — توابع پایه @Composable: AppButton, AppTextField, AppCheckbox. هر تابع پارامترهای سفارشیسازی (رنگ، اندازه، وضعیت) را دریافت میکند و حاوی منطق تجاری نیست. اتمها در لایه shared تعریف و به عنوان UI-kit صادر میشوند.
مولکولها — توابع @Composable که چند اتم را ترکیب میکنند: LabeledTextField (برچسب + فیلد ورودی + پیام خطا)، ProductCard (تصویر + نام + قیمت). مولکولها میتوانند وضعیت پایه داشته باشند (اعتبارسنجی فیلد)، اما به API یا ViewModel دسترسی ندارند. آنها در ارگانیسمهای مختلف قابل استفاده مجدد هستند.
ارگانیسمها — توابع @Composable در سطح ویژگی: LoginForm (LabeledTextField برای ایمیل + LabeledTextField برای رمز عبور + AppButton ارسال + لینک بازیابی). ارگانیسمها از طریق توابع Intent با ViewModel کار میکنند و میتوانند منطق تجاری داشته باشند. در SwiftUI سلسلهمراتب مشابه از طریق @ViewBuilder و ساختارهای View سفارشی ساخته میشود.
در SwiftUI اتم — ساختار View سفارشی AppButton، مولکول — فیلد ورودی با برچسب روی HStack، ارگانیسم — فرم ورود. چنین ساختاری امکان استفاده مجدد از کامپوننتها را در همه صفحات فراهم میکند — تغییر یک اتم (رنگ دکمه) به طور خودکار در همه صفحات اعمال میشود. ترکیب Atomic Design با سیستم طراحی سازگاری رابط کاربری را بدون کنترل دستی هر صفحه تضمین میکند.
سوالات متداول
آیا باید دقیقاً از پنج سطح Atomic Design پیروی کرد؟
پنج سطح یک توصیه است، نه قانون. بسیاری از سیستمهای طراحی (Material Design, IBM Carbon) از ۳ یا ۴ سطح استفاده میکنند: کامپوننتهای پایه، کامپوننتهای ترکیبی و الگوها. قانون اصلی — هر کامپوننت به یک سطح تعلق دارد و میتواند در سطوح بعدی استفاده مجدد شود. اگر میبینید سطوح «مولکول» و «ارگانیسم» در پروژه شما تفاوتی ندارند — آنها را ترکیب کنید. اتمها و صفحات تنها سطوح اجباری هستند.
چگونه کامپوننتهای Atomic Design را تست کنیم؟
اتمها به صورت بصری تست میشوند (تستهای SnapShot, Compose Preview) — بررسی میشود که دکمه با خصوصیات مشخص شده به درستی نمایش داده میشود. مولکولها به عنوان ترکیبی از اتمها تست میشوند — وضعیت بررسی میشود (خطا، موفقیت، غیرفعال). ارگانیسمها نیاز به تستهای یکپارچه دارند — تعامل با ViewModel بررسی میشود (ارسال فرم، بارگذاری داده). در IT Sectr ما از Compose Test برای اندروید و XCTest برای iOS استفاده میکنیم؛ برای تست بصری — Paparazzi (اندروید) و SnapshotTesting (iOS).
آیا میتوان از Atomic Design بدون سیستم طراحی استفاده کرد؟
میتوان، اما کارایی کاهش مییابد. بدون سیستم طراحی و توکنهای طراحی، اتمها سبک یکسانی ندارند — هر توسعهدهنده اتمهای خود را با رنگها و فاصلههای دلخواه ایجاد میکند که منجر به ناهماهنگی بصری میشود. Atomic Design و سیستم طراحی — مفاهیم مکمل: Atomic Design سلسلهمراتب را تعیین میکند، سیستم طراحی — زبان بصری را. توصیه میشود آنها را با هم پیادهسازی کنید: ابتدا توکنهای طراحی (رنگها، تایپوگرافی، فاصلهها)، سپس اتمها، بعد مولکولها و ارگانیسمها.
چگونه با «منطقه اتمی» (اتمهای زیاد) مقابله کنیم؟
«منطقه اتمی» — وضعیتی که تعداد اتمها از حد معقول فراتر میرود (۱۰۰+) و پیدا کردن کامپوننت مورد نظر بیشتر از نوشتن از صفر زمان میبرد. راه حل — هممکانی اتمها بر اساس ویژگی: اتمی که فقط توسط یک ویژگی استفاده میشود را داخل آن ویژگی نگه دارید، نه در shared. در shared فقط اتمهای جهانی (Button, Text, Input) قرار میگیرند. به گفته برد فراست، هممکانی تعداد shared-اتمها را بدون از دست دادن استفاده مجدد ۶۰–۷۰٪ کاهش میدهد.
Atomic Design فقط برای UI است یا برای کد هم هست؟
Atomic Design در اصل — متدولوژی طراحی رابط کاربری (design) است، اما در عمل مدرن برای سازماندهی کد (code) نیز استفاده میشود. در ابزارهای طراحی (Figma, Sketch) اتمها کامپوننتهای کتابخانه هستند؛ در کد — توابع و کلاسها. متدولوژی بین design و code تمایز قائل نمیشود — اتم چه در طرح و چه در پیادهسازی یکسان است. در IT Sectr ما از supernova.io برای همگامسازی اتمهای طراحی و کد استفاده میکنیم که از diverging بین طرح و رابط کاربری نهایی جلوگیری میکند.
خلاصه
- Atomic Design — متدولوژی سازماندهی سلسلهمراتبی کامپوننتهای UI با استفاده از استعاره اتمها، مولکولها، ارگانیسمها، الگوها و صفحات.
- اتمها — عناصر پایه (دکمه، فیلد ورودی)؛ مولکولها — ترکیب آنها (فیلد با برچسب)؛ ارگانیسمها — بلوکهای پیچیده (فرم جستجو).
- الگوها چارچوب را تعیین میکنند، صفحات — پر شدن مشخص با داده.
- Atomic Design وضعیت و منطق تجاری را مدیریت نمیکند — فقط مسئول سازماندهی لایه UI است.
- در توسعه موبایل، اتمها به طور طبیعی با توابع @Composable (اندروید) و ساختارهای View (iOS) توصیف میشوند.
- Atomic Design با FSD به خوبی ترکیب میشود: FSD معماری را تعیین میکند، Atomic Design — سازماندهی UI درون برشها.
- مزایای اصلی — استفاده مجدد از کامپوننتها، سازگاری بصری، سرعت ایجاد صفحات جدید.
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید