Menjelaskan apa itu Atomic Design — metodologi desain antarmuka yang diusulkan oleh Brad Frost pada tahun 2013, yang meminjam metafora atom, molekul, dan organisme untuk membangun hierarki komponen UI. Tidak seperti pendekatan berbasis halaman, di mana antarmuka dirancang per layar, Atomic Design membagi UI menjadi elemen terkecil yang dapat digunakan kembali (atom) dan menyusunnya menjadi struktur yang lebih kompleks. Menurut Brad Frost (2016), metodologi ini digunakan dalam sistem desain 67% perusahaan besar, termasuk IBM, Airbnb, dan Google.
Poin Utama
Atomic Design — metodologi pembuatan sistem antarmuka hierarkis, di mana setiap elemen UI termasuk ke dalam salah satu dari lima tingkat: atom (elemen dasar), molekul (kombinasi atom), organisme (blok kompleks), template (kerangka halaman), dan halaman (layar konkret dengan data). Analogi ini dipinjam dari kimia: atom bergabung menjadi molekul, molekul menjadi organisme, organisme menjadi template, template diisi dengan konten dan menjadi halaman.
Metodologi ini diusulkan oleh desainer web Brad Frost pada tahun 2013 sebagai jawaban atas masalah "pemikiran berbasis halaman" — ketika setiap layar baru dirancang dari awal, tanpa mempertimbangkan komponen yang sudah ada. Dalam buku "Atomic Design" (2016), Frost menjelaskan implementasi metodologi dalam proyek perusahaan besar: IBM, GE, Starbucks. Menurut Nielsen Norman Group (2022), Atomic Design mengurangi waktu desain layar baru sebesar 30–50% melalui penggunaan kembali komponen yang sudah jadi.
Atomic Design — bukan sekedar teknologi, melainkan filosofi organisasi UI. Ia tidak terikat pada kerangka kerja tertentu dan dapat diterapkan baik di web (React, Vue) maupun dalam pengembangan seluler (Jetpack Compose, SwiftUI). Di IT Sectr, kami menggunakan Atomic Design untuk membangun sistem desain klien: kami mengidentifikasi komponen atom pada tahap desain dan mentransfernya ke komponen kode Compose/SwiftUI.
Setiap tingkat Atomic Design menyelesaikan tugasnya sendiri dan memiliki area tanggung jawab yang ketat. Atom — blok bangunan terkecil dari antarmuka, yang tidak dapat dipecah lebih lanjut tanpa kehilangan makna: tombol, kolom teks, ikon, label, kotak centang. Atom tidak mengandung logika bisnis dan tidak bergantung pada konteks. Mereka menentukan karakteristik visual dasar: warna, ukuran, jarak, tipografi.
Molekul — kombinasi dari dua atau lebih atom, membentuk unit fungsional sederhana. Kolom input dengan label dan pesan kesalahan — molekul. Kartu produk dengan gambar, nama, dan harga — molekul. Molekul dapat berisi logika dasar (tampilkan/sembunyikan kesalahan), tetapi tidak mengandung proses bisnis. Molekul adalah tingkat pertama di mana komponen menjadi dapat digunakan kembali di berbagai layar.
Organisme — blok antarmuka kompleks, terdiri dari molekul dan atom, yang mengimplementasikan fungsi tertentu dari aplikasi. Formulir login (kolom email, kolom kata sandi, tombol kirim, tautan "lupa kata sandi") — organisme. Header dengan logo, pencarian, dan navigasi — organisme. Organisme dapat berisi logika bisnis dan mengakses API, tetapi hanya dalam kerangka fungsinya.
Template — kerangka halaman yang menentukan penempatan organisme di layar tanpa konten konkret. Template mendefinisikan grid, kolom, zona konten — wireframe pada tingkat kode. Template tidak berisi data, hanya placeholder. Mereka memungkinkan evaluasi struktur halaman sebelum diisi dengan konten.
Halaman — layar konkret aplikasi, di mana template diisi dengan data nyata. Pada tingkat ini, diperiksa bagaimana komponen terlihat dengan konten nyata (string panjang, tidak adanya data, kesalahan). Halaman adalah satu-satunya tingkat yang dilihat oleh pengguna akhir. Perubahan pada tingkat halaman tidak boleh mempengaruhi atom, molekul, dan organisme — jika komponen perlu diubah, perubahan dilakukan pada tingkatnya, dan halaman akan mengambilnya secara otomatis.
Keuntungan Atomic Design terlihat saat menskalakan antarmuka. Pustaka komponen yang seragam menjamin konsistensi visual: tombol terlihat sama di semua layar karena itu adalah atom yang sama. Menurut Brad Frost (2016), perusahaan yang menerapkan Atomic Design mengurangi waktu pengembangan layar baru sebesar 30–50% melalui penggunaan kembali molekul dan organisme yang sudah jadi.
| Karakteristik | Atomic Design | Pendekatan berbasis halaman |
|---|---|---|
| Penggunaan kembali komponen | Tinggi (atom, molekul, organisme) | Rendah (setiap layar dari awal) |
| Konsistensi visual | Dijamin | Kontrol manual |
| Kecepatan pembuatan layar baru | Tinggi (perakitan dari blok jadi) | Rendah (desain + pengkodean dari awal) |
| Kompleksitas implementasi | Tinggi (perlu katalog komponen) | Rendah (model yang dikenal) |
| Kemampuan pengujian | Tinggi (setiap atom terisolasi) | Integrasi (seluruh layar sekaligus) |
Keterbatasan — Atomic Design tidak menjelaskan cara mengelola status aplikasi. Metodologi ini hanya menjawab pertanyaan "bagaimana mengatur komponen UI", tetapi tidak menyentuh logika bisnis, routing, atau penanganan data. Keterbatasan kedua — kesulitan menentukan batas: di mana molekul berakhir dan organisme dimulai? Dalam praktiknya, batas-batasnya kabur, dan tim yang berbeda dapat mengklasifikasikan komponen yang sama secara berbeda. Disarankan untuk menetapkan aturan dalam token desain dan katalog komponen (Storybook, Jetpack Compose Preview).
Keterbatasan ketiga — abstraksi berlebihan untuk proyek kecil. Jika aplikasi terdiri dari 5 layar, membuat hierarki atom dan molekul adalah pekerjaan yang sia-sia. Atomic Design menjadi menguntungkan ketika jumlah layar melebihi 20 dan komponen digunakan kembali di halaman yang berbeda.
Atomic Design dan Feature-Sliced Design (FSD) menyelesaikan tugas yang berbeda dan dapat digunakan bersama. Atomic Design adalah metodologi pengorganisasian komponen UI, FSD — metodologi pengorganisasian lapisan bisnis dan seluruh aplikasi. Atomic Design menjawab pertanyaan "bagaimana membagi UI menjadi bagian yang dapat digunakan kembali", FSD — "bagaimana mengatur kode di sekitar fitur bisnis". Mereka tidak bersaing: seseorang dapat memiliki struktur FSD dengan lapisan features dan entities, dan di dalam setiap lapisan menggunakan Atomic Design untuk mengatur komponen UI.
| Kriteria | Atomic Design | Feature-Sliced Design |
|---|---|---|
| Bidang | Komponen UI | Arsitektur aplikasi |
| Unit pengelompokan | Metafora kimia (atom → molekul → organisme) | Fitur bisnis (iris) |
| Ketergantungan | Dari atom ke halaman (bawah ke atas) | Dari app ke shared (atas ke bawah) |
| Penanganan data | Tidak dijelaskan | Melalui segmen model + api |
| Penskalaan | Horizontal (lebih banyak komponen) | Vertikal (lebih banyak fitur) |
Kombinasi tipikal: FSD mendefinisikan struktur modular aplikasi (lapisan, irisan), Atomic Design — struktur internal komponen UI di dalam setiap irisan. Misalnya, iris feature.auth berisi molekul (LoginForm, PasswordInput) dan organisme (AuthPage), yang disusun sesuai aturan Atomic Design. Lapisan shared berisi atom (Button, Input, Label), yang dapat digunakan kembali di semua fitur.
Jetpack Compose dan SwiftUI secara alami mendukung hierarki Atomic Design melalui komposisi komponen. Atom di Compose — fungsi @Composable dasar: AppButton, AppTextField, AppCheckbox. Setiap fungsi menerima parameter kustomisasi (warna, ukuran, status) dan tidak mengandung logika bisnis. Atom didefinisikan di lapisan shared dan diekspor sebagai UI-kit.
Molekul — fungsi @Composable yang menggabungkan beberapa atom: LabeledTextField (label + kolom input + pesan kesalahan), ProductCard (gambar + nama + harga). Molekul dapat berisi status dasar (validitas kolom), tetapi tidak mengakses API atau ViewModel. Mereka digunakan kembali di berbagai organisme.
Organisme — fungsi @Composable di tingkat fitur: LoginForm (LabeledTextField untuk email + LabeledTextField untuk kata sandi + AppButton kirim + tautan pemulihan). Organisme bekerja dengan ViewModel melalui fungsi Intent dan dapat berisi logika bisnis. Di SwiftUI, hierarki serupa dibangun melalui @ViewBuilder dan struktur View kustom.
Di SwiftUI, atom — struktur View kustom AppButton, molekul — kolom input dengan label di HStack, organisme — formulir login. Struktur semacam itu memungkinkan penggunaan kembali komponen di semua layar — perubahan atom (warna tombol) secara otomatis diterapkan ke semua layar. Kombinasi Atomic Design dengan sistem desain menjamin konsistensi antarmuka tanpa kontrol manual setiap layar.
Pertanyaan yang Sering Diajukan
Lima tingkat adalah rekomendasi, bukan hukum. Banyak sistem desain (Material Design, IBM Carbon) menggunakan 3 atau 4 tingkat: komponen dasar, komponen gabungan, dan template. Aturan utama — setiap komponen termasuk ke dalam satu tingkat dan dapat digunakan kembali di tingkat berikutnya. Jika Anda melihat tingkat "molekul" dan "organisme" dalam proyek Anda tidak berbeda — gabungkan saja. Atom dan halaman adalah satu-satunya tingkat yang wajib.
Atom diuji secara visual (tes SnapShot, Compose Preview) — diperiksa apakah tombol dengan properti yang ditentukan dirender dengan benar. Molekul diuji sebagai kombinasi atom — diperiksa statusnya (kesalahan, sukses, dinonaktifkan). Organisme memerlukan tes integrasi — diperiksa interaksi dengan ViewModel (pengiriman formulir, pemuatan data). Di IT Sectr, kami menggunakan Compose Test untuk Android dan XCTest untuk iOS; untuk pengujian visual — Paparazzi (Android) dan SnapshotTesting (iOS).
Bisa, tetapi efektivitasnya berkurang. Tanpa sistem desain dan token desain, atom tidak memiliki gaya yang seragam — setiap pengembang membuat atom mereka sendiri dengan warna dan jarak yang sembarangan, yang menyebabkan ketidakkonsistenan visual. Atomic Design dan sistem desain — konsep yang saling melengkapi: Atomic Design menentukan hierarki, sistem desain — bahasa visual. Disarankan untuk menerapkannya bersama: pertama token desain (warna, tipografi, jarak), kemudian atom, lalu molekul dan organisme.
"Zona atom" — situasi di mana jumlah atom melebihi batas wajar (100+), dan menemukan komponen yang diperlukan memakan waktu lebih lama daripada menulisnya dari awal. Solusinya — kolokasi atom berdasarkan fitur: atom yang hanya digunakan oleh satu fitur disimpan di dalam fitur tersebut, bukan di shared. Di shared hanya ditempatkan atom global (Button, Text, Input). Menurut Brad Frost, kolokasi mengurangi jumlah atom shared sebesar 60–70% tanpa kehilangan penggunaan kembali.
Atomic Design awalnya adalah metodologi desain antarmuka (design), tetapi dalam praktik modern juga digunakan untuk mengatur kode (code). Di alat desain (Figma, Sketch), atom adalah komponen perpustakaan; di kode — fungsi dan kelas. Metodologi tidak membedakan antara design dan code — atom sama baik dalam mockup maupun implementasi. Di IT Sectr, kami menggunakan supernova.io untuk sinkronisasi atom desain dan atom kode, yang menghilangkan perbedaan antara mockup dan antarmuka akhir.
Kesimpulan
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga