Konsistensi UI di aplikasi React dengan design token dan aturan

Mengapa layar React yang dihasilkan sering terlihat tidak konsisten

Ketidakkonsistenan UI biasanya muncul di detail kecil yang terasa aneh saat Anda mengklik ke sana kemari. Satu halaman punya padding lapang, halaman lain terasa sesak. Heading loncat ukuran, tombol berubah bentuk dan warna, dan input yang sama berperilaku berbeda tergantung layarnya.

Sebagian besar waktu, penyimpangan datang dari beberapa dasar:

• Spacing: padding, gap, dan ritme seksi berbeda-beda
• Tipografi: ukuran font, bobot, dan line height tidak stabil
• Komponen: tombol, card, border, dan bayangan berubah sedikit
• Form: timing validasi, penempatan error, dan state disabled berbeda

Ini umum terjadi ketika layar dihasilkan dari prompt terpisah. Setiap prompt pada dasarnya adalah awal yang baru, jadi model mengisi keputusan yang hilang dengan menebak. Bahkan “gunakan styling modern” masih meninggalkan ratusan pilihan kecil: gap 8px vs 12px, teks body 14px vs 16px, kapan menampilkan error, seperti apa tombol primary.

Anda bisa membersihkan dua atau tiga halaman secara manual, tetapi itu tidak skalabel. Anda akan terus mengejar tweak CSS satu-per-satu, menyalin style antar file, dan memperbaiki ulang form. Aturannya ada di kepala Anda, bukan di proyek.

Bayangkan menghasilkan layar login hari ini dan layar profil besok. Jika satu hanya menampilkan error saat submit tapi yang lain menampilkan error saat blur, pengguna akan menyadarinya. Jika tinggi tombol primary berubah antar layar, aplikasi terasa seperti dijahit bersama.

Konsistensi menjadi default ketika setiap layar mengikuti sistem bersama yang sama: design token (spacing, tipografi, warna) ditambah sekumpulan kecil aturan komponen dan form.

Design tokens dalam bahasa sehari-hari

Design token adalah nilai bernama sederhana yang Anda gunakan kembali di seluruh UI. Daripada meminta “padding nyaman” di setiap layar, Anda menggunakan token seperti space-4. Daripada “sedikit membulat,” Anda menggunakan radius-md. Nama itu tetap stabil meskipun Anda nanti mengubah apa yang dipetakan.

Token adalah kumpulan keputusan yang Anda inginkan setiap layar bagikan. Mereka menghilangkan selera dan tebakan, dan itulah yang menyebabkan drift ketika Anda menghasilkan atau membuat halaman baru.

Token tipikal mencakup spacing, tipografi, warna, bentuk, dan sedikit elevasi. Manfaatnya praktis: header selalu menggunakan ukuran yang sama, card selalu memiliki padding yang sama, dan tombol primary mempertahankan warna serta radius yang konsisten.

Apa yang sebaiknya ditoken-kan vs yang fleksibel?

Token-kan hal-hal yang memengaruhi nuansa keseluruhan produk: skala spacing, ukuran font dan line height, warna inti (teks, latar, primary, danger, border), dan beberapa nilai radius border.

Biarkan pilihan yang dipicu konten tetap fleksibel, seperti panjang copy, ikon mana yang digunakan, atau apakah sebuah seksi butuh dua atau tiga card.

Saat Anda menghasilkan layar (termasuk dengan alat seperti Koder.ai), memberikan set token kecil diawal mengurangi jumlah tebakan dan membuat output terasa lebih konsisten.

Pilih set token yang kecil tapi lengkap

Set token hanyalah menu singkat nilai yang diizinkan. Semakin kecil semakin baik karena menyisakan ruang lebih sedikit untuk pilihan acak, tetapi tetap harus mencakup dasar yang membuat layar terasa off.

Mulai dari spacing. Pilih satu skala dan gunakan di mana-mana untuk padding, gap, dan layout. Set seperti 4, 8, 12, 16, 24, 32 menutup sebagian besar kebutuhan UI. Jika desain memerlukan 10px atau 18px, bulatkan ke token terdekat daripada memperkenalkan angka baru.

Selanjutnya definisikan default tipografi agar heading dan teks body tidak bergerak. Anda tidak membutuhkan sistem tipografi besar. Yang Anda butuhkan adalah langkah yang jelas dan bisa diulang.

Set kompak yang tetap berguna tanpa menjadi bengkak:

• Spacing: 4, 8, 12, 16, 24, 32
• Tipografi: satu ukuran body, dua ukuran heading, satu line height untuk body, satu untuk heading
• Warna: text-primary, text-muted, bg, surface, border, accent
• Radius: dua nilai (mis. 4 dan 12)
• Elevasi: none, small, medium (maksimal tiga level)

Aksesibilitas juga harus masuk ke sistem. Definisikan gaya outline fokus (warna, ketebalan, offset) sehingga pengguna keyboard mendapatkan state fokus yang konsisten. Tetapkan minimum tap target (mis. 44x44) untuk mobile. Batasi warna teks ke set kecil yang terpercaya agar kontras tetap dapat diprediksi.

Jika tombol kadang terlihat sesak, seringkali karena satu layar menggunakan padding 10 dan yang lain 12. Dengan token, Anda bisa mengatakan: “Tombol menggunakan paddingY=8, paddingX=16, radius=12, token outline fokus, tinggi minimum 44.” Setelah angka-angka itu tetap, generator berhenti mengimprovisasi.

Aturan komponen yang menjaga setiap layar selaras

Token menetapkan angka. Aturan komponen menetapkan kebiasaan.

Pilih sekumpulan kecil komponen inti dan perlakukan mereka sebagai satu-satunya blok bangunan untuk layar. Buat mereka sederhana dan dapat digunakan ulang: Button, Input, Select, Checkbox, Card. Anda bisa menambah TextArea dan Modal, tapi mereka harus mengikuti sistem yang sama (label, spasi, state).

Selanjutnya, batasi varian dan definisikan kapan varian diizinkan. Misalnya: Button punya primary, secondary, dan danger. Primary untuk aksi utama pada layar (biasanya satu). Secondary untuk batal atau aksi prioritas rendah. Danger hanya untuk aksi destruktif seperti hapus. Jika varian tidak bisa dibenarkan, default ke secondary.

Aturan spacing mencegah drift halus. Definisikan default di dalam komponen: padding Button, tinggi Input, gap label-ke-field, gap standar antar field bertumpuk. Tambahkan beberapa aturan layout juga: Card punya padding internal tetap dan spasi header/body yang konsisten; Modal menggunakan langkah lebar yang sama dan penjajaran footer yang konsisten.

Terakhir, buat state tidak bisa ditawar karena di sinilah UI sering mulai terlihat acak:

• Loading: nonaktifkan kontrol, tampilkan spinner, jaga lebar stabil
• Disabled: kontras dikurangi, tapi jangan hilangkan gaya hover/fokus sepenuhnya
• Empty states: pesan singkat plus satu aksi jelas
• Validasi: error muncul di bawah field dan tidak menyebabkan pergeseran tata letak besar

Saat Anda menghasilkan layar yang banyak form seperti “Create project,” aturan ini mencegah ukuran tombol campur aduk, posisi label bergeser, atau card “spesial” yang muncul hanya di satu halaman.

Aturan perilaku form: detail yang biasanya menyimpang

Bahkan dengan visual yang stabil, banyak keluhan “ini terasa aneh” datang dari perilaku form. Jika setiap layar menangani label, error, dan fokus berbeda, pengguna merasakannya sebagai ketidakkonsistenan.

Pilih satu pola form dan gunakan di mana-mana: label, penanda optional/required, helper text, lalu teks error. Jaga kata-kata konsisten juga (mis. label dengan sentence case, helper text singkat, dan pesan error yang dimulai dengan kata kerja).

Aturan yang mencegah sebagian besar drift:

• Label selalu di atas field (bukan placeholder), penanda required di label
• Helper text selalu di bawah field, ukuran dan warna sama, jangan dipakai untuk error
• Timing validasi: tampilkan error setelah blur atau submit, kosongkan saat berubah
• Penempatan error: satu baris error langsung di bawah field, sejajar dengan helper text
• Perilaku fokus: urutan Tab mengikuti layout visual; Enter hanya submit pada field terakhir atau saat tombol primary fokus

Kunci sizing dan layout agar layar tidak “mengembang” berbeda. Definisikan satu tinggi input, satu tinggi tombol, dan lebar field default. Di desktop, ratakan field ke grid konsisten dan tumpuk label di atas input. Di mobile, buat field full width dan hindari form dua kolom kecuali benar-benar perlu.

Contoh sederhana: layar “Create project” mungkin punya Name, Region, dan Description. Meskipun Region adalah select, perlakukan sama seperti field lain: tinggi sama, posisi label sama, satu baris error sama. Jika pengguna submit dengan Name kosong, fokus pindah ke Name, error muncul di bawahnya, dan layout tetap stabil.

Jika Anda menghasilkan layar di Koder.ai, masukkan aturan form ini ke prompt Anda sekali dan gunakan kembali di seluruh fitur sehingga setiap form baru berperilaku sama tanpa pembersihan berulang.

Cara mengekspresikan token dan aturan di prompt Anda

Perlakukan prompt Anda seperti kontrak UI kecil. Buat singkat, spesifik, dan bisa digunakan ulang sehingga setiap layar baru mengikuti spacing, tipografi, komponen, dan perilaku yang sama.

Polanya praktis: tempel spesifikasi UI yang ringkas di bagian atas permintaan Anda, lalu jelaskan layar dengan bahasa sehari-hari.

Template prompt ringkas

UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)

Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast

Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16

Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below

Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles

If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens

Setelah spesifikasi, tambahkan beberapa pemeriksaan penerimaan yang menangkap drift lebih awal:

• “Gunakan hanya token di atas; jangan pakai style inline.”
• “Semua form harus menggunakan FormRow dan menampilkan error dengan cara yang sama.”
• “Jika Anda harus menambahkan komponen, dasarkan pada Card plus tipografi yang ada.”

Jika Anda menggunakan generator berbasis chat, jaga spesifikasi ini stabil di seluruh permintaan. Mengubahnya setiap kali akan merusak tujuan.

Alur kerja yang menjaga layar konsisten

Tulis kontrak UI sebelum menghasilkan apa pun: set token kecil (spacing, type, warna, radius, shadows) plus inventaris komponen pendek (Button, Input, Select, Card, Modal, Table, Toast). Jika token atau komponen hilang, model akan menciptakan satu dan UI Anda akan drift.

Lalu buat satu layar referensi yang menguji aturan. Halaman berat-form adalah uji stress yang baik karena mencakup header, helper text, error validasi, tombol primary dan secondary, dan toast sukses. Perlakukan layar itu sebagai baseline.

Dari sana, bangun layar baru dengan menyusun apa yang sudah Anda definisikan. Jangan minta “styling baru.” Minta Card yang sama, skala spacing yang sama, langkah tipografi yang sama, dan pola field yang sama.

Alur kerja sederhana:

• Konfirmasi token dan aturan komponen, lalu bekukan untuk fitur
• Hasilkan satu layar referensi dan sesuaikan spesifikasi sampai terasa tepat
• Bangun layar baru dengan menggunakan kembali komponen, bukan merestyl
• Review untuk konsistensi, lalu ubah aturan (token/komponen), bukan piksel individu
• Simpan spesifikasi sebagai snippet yang bisa digunakan ulang untuk fitur berikutnya

Jika layar “Search users” berakhir dengan spacing lebih rapat daripada referensi, jangan tweak margin manual. Perbarui token spacing atau aturan padding Card sekali, lalu hasilkan ulang.

Jika Anda bekerja di Koder.ai, snapshot dan rollback bisa membantu: kunci baseline, bereksperimen dengan aman, dan cepat kembalikan jika sebuah perubahan mulai memperkenalkan drift.

Kesalahan umum yang harus dihindari

Cara tercepat kehilangan konsistensi adalah memperlakukan token dan aturan seperti saran. Pengecualian kecil menumpuk di layar baru.

Satu jebakan umum adalah mengubah skala spacing di tengah proyek. Layar awal menggunakan 8, 16, 24. Layar baru memperkenalkan 10 dan 18 “karena terlihat benar.” Sekarang drift diizinkan, dan layar lama tak pernah diperbarui.

Sumber drift lain adalah membiarkan generator menciptakan gaya komponen baru. Jika Anda tidak mengatakan “hanya varian tombol ini yang ada,” ia mungkin membuat radius baru atau padding input berbeda di satu layar.

State juga sering terlewat. Loading, empty, dan error state sering mengubah spacing dan perilaku. Jika Anda menambahkannya di akhir, biasanya pola yang terburu-buru tidak cocok dengan sisanya.

Juga waspadai jenis spesifisitas yang salah: “buat modern dengan soft shadows” itu kabur, sementara aturan perilaku seperti “error tampil di bawah field,” “tombol disabled tetap punya style fokus,” dan “Enter submit hanya di field terakhir” itu konkret dan bisa diulang.

Jika Anda ingin guardrail ringan untuk ditempel ke prompt, buat singkat:

• Gunakan skala spacing dan token tipografi yang sama dengan layar yang ada; jangan buat nilai baru
• Gunakan hanya komponen dan varian yang disetujui
• Sertakan loading, empty, dan error state menggunakan token yang sama
• Spesifikkan perilaku (validasi, urutan fokus, submit, disabled) sesama jelas seperti visual

Daftar periksa cepat untuk konsistensi sebelum Anda menerima layar

Sebelum Anda merge layar yang dihasilkan, lakukan scan dua menit.

Mulai dengan spacing. Cari nilai acak seperti 13px atau margin one-off yang ditambahkan “biar pas.” Jika Anda memakai token, setiap gap harus berasal dari set yang disetujui, termasuk gutter, padding card, dan spacing antar field form.

Lalu periksa tipografi terhadap skala. Heading harus turun ukuran secara dapat diprediksi. Teks body tidak boleh berganti ukuran antar seksi serupa. Line height juga penting, terutama pada layar yang padat seperti halaman pengaturan.

Pindai tombol berikut. Varian dan ukuran harus mengikuti aturan Anda: primary untuk aksi utama, secondary untuk aksi kurang penting, danger hanya untuk yang benar-benar menghapus. Tinggi tombol, posisi ikon, dan gaya label harus cocok.

Untuk form, konsistensi kebanyakan tentang struktur. Label tetap pada satu tempat, indikator required mengikuti satu aturan, helper text dan error tidak saling bersaing, dan error muncul di lokasi yang konsisten.

Daftar pemeriksaan singkat:

• Spacing hanya memakai nilai token (tidak ada angka acak)
• Tipografi cocok dengan skala (termasuk line height)
• Tombol mengikuti varian dan ukuran yang sama
• Form memakai satu pola untuk label, helper text, dan error
• State ada: hover, focus, disabled, loading, empty

Terakhir, lakukan cek cepat di mobile. Perkecil lebar dan konfirmasi layout beradaptasi tanpa menciptakan ukuran font atau spacing baru.

Contoh: menghasilkan fitur React kecil tanpa drift style

Bayangkan alur onboarding sederhana: tiga layar (Profile, Preferences, Confirm), plus halaman Settings nanti. Anda ingin setiap layar terasa dibuat oleh desainer yang sama, meskipun dihasilkan dalam sesi terpisah.

Sebelum menghasilkan apa pun, berikan set token kecil dan beberapa aturan komponen:

TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12

COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts

Sekarang hasilkan “Profile” dan “Preferences” secara terpisah. Karena kedua layar harus menggunakan Page, Card, Field, dan Button row sesuai definisi, mereka memiliki margin, spasi label, dan posisi tombol yang sama. Langkah Confirm tetap muat, meskipun memiliki lebih banyak teks baca.

Perilaku form adalah tempat drift sering menyusup, jadi definisikan sekali dan gunakan lagi: submit dinonaktifkan sampai valid, error inline hanya setelah blur atau submit, Enter hanya submit di langkah terakhir, dan tombol Back tidak pernah menghapus nilai yang sudah dimasukkan.

Saat Anda butuh potongan UI baru, jangan biarkan model mengimprovisasi. Tambahkan satu aturan, lalu hasilkan ulang dengan intent reuse:

• ProgressStepper: height=32, spacing=md, current step bold, completed steps clickable

Langkah selanjutnya: buat konsistensi menjadi default

Ubah token dan aturan menjadi spesifikasi yang dapat digunakan ulang yang benar-benar Anda gunakan. Jika terlalu panjang untuk ditempel, itu tidak akan diikuti.

Spesifikasi praktis biasanya mencakup: tabel token Anda (spacing, type, radii, warna), set aturan komponen singkat (button, input, card, heading), aturan perilaku form (timing validasi, error, disabled/loading), default layout (padding halaman, max width, spacing seksi), dan daftar singkat “jangan lakukan ini” (margin acak, ukuran font ad-hoc).

Lalu buat satu kebiasaan: perbarui spesifikasi dulu, bukan piksel individu.

Jika Anda menggunakan Koder.ai (koder.ai), planning mode adalah tempat yang baik untuk mengulang dan mengonfirmasi spesifikasi sebelum menghasilkan UI. Saat ingin mencoba alternatif, snapshots dan rollback membantu Anda bereksperimen tanpa kehilangan baseline yang stabil.