Blog
Blog

· design · llm · frontend

Anti Slop Slop Club: Refero Styles

Kamu pasti pernah lihat web seperti ini: hero dengan gradient ungu ke biru, headline “Supercharge your workflow”, tiga kartu fitur dengan ikon di dalam kotak rounded-2xl, font Inter, dan emoji di setiap heading. Kombinasi itu bisa saja cocok. Namun, tanpa alasan yang terkait dengan produk, hasilnya mudah tertukar dengan halaman lain.

Itulah AI slop versi web: UI yang terlihat rapi tetapi memakai pola umum tanpa alasan yang terkait dengan produk. Tulisan ini merangkum cara saya menghindarinya, dengan Refero Styles sebagai titik awal.

Kenapa hasil AI terlihat sama semua

Ketika prompt hanya berbunyi “buatkan landing page SaaS yang modern”, model harus menebak hampir semua keputusan desain. Ia cenderung mengisi kekosongan itu dengan pola yang sering muncul: hero besar, gradient, dan tiga kartu fitur. Hasilnya bisa rapi, tetapi belum tentu cocok dengan produkmu.

Prompt yang lebih jelas membantu, tetapi bukan jaminan. Kualitas referensi, komponen yang tersedia, dan cara kita meninjau hasil juga menentukan apakah halaman itu terasa punya arah dan human-taste.

Refero Styles: selera dalam format yang bisa dibaca AI

Refero Styles menyediakan lebih dari 2.000 referensi gaya dari situs produk nyata. Setiap referensi memuat warna, tipografi, spacing, komponen, dan file DESIGN.md yang bisa langsung dipakai di Cursor, Claude Code, Codex, v0, atau Lovable.

Yang menarik justru deskripsinya. Vercel digambarkan sebagai “typeset terminal on white paper”, Cursor sebagai “warm parchment atelier”, Linear sebagai “midnight precision instrument”. Kedengarannya puitis, tapi kalimat seperti ini memberi arah yang jauh lebih jelas ke model daripada “clean and modern”.

Workflow yang saya pakai

1. Pilih berdasarkan karakter, bukan popularitas. Jangan langsung ambil style yang sedang trending. Mulai dari pertanyaan: produk ini harus terasa seperti apa? Tenang dan editorial? Padat seperti dashboard trading? Hangat dan personal? Lalu cari dengan kata kunci suasana, misalnya “editorial magazine”, “hairline grid rules”, atau “dense marketplace”.

2. Taruh DESIGN.md di repo. Simpan di root proyek dan rujuk dari AGENTS.md atau aturan editor yang kamu pakai. Dengan begitu, arahan desain mudah ditemukan saat agent mulai bekerja.

<!-- AGENTS.md -->
## Design
Ikuti `DESIGN.md` saat membuat UI. Pakai token yang tersedia untuk warna,
radius, shadow, dan font. Jika kebutuhan baru belum tercakup, jelaskan
alasannya dan perbarui token sebelum menggunakannya berulang kali.

3. Adaptasi, jangan fotokopi. Ambil sistemnya, bukan identitasnya. Skala tipografi, ritme spacing, cara memakai border, dan kepadatan informasi adalah hal yang layak ditiru. Warna brand, logo, dan ilustrasi khas milik orang lain tidak. Ganti warna aksen dan font display dengan milikmu sendiri.

4. Terjemahkan ke token. Pindahkan keputusan yang berulang, seperti warna, font, dan radius, ke token agar mudah dipakai dan diperiksa. Di Tailwind v4, kamu bisa mendefinisikannya lewat @theme:

@theme {
  --font-display: "Instrument Serif", serif;
  --font-sans: "Geist", sans-serif;

  --color-paper: oklch(0.98 0.01 85);
  --color-ink: oklch(0.22 0.02 60);
  --color-accent: oklch(0.62 0.17 40);
  --color-rule: oklch(0.88 0.01 85);

  --radius-card: 4px;
}

Saat review, cari nilai yang menyimpang dari sistem. Nilai khusus masih bisa masuk akal untuk satu kebutuhan tertentu, tetapi sebaiknya punya alasan yang jelas, bukan muncul karena agent memilih default.

5. Bangun satu bagian dulu. Minta agent membuat hero atau bagian lain yang paling mewakili arah visualnya. Lihat hasil render, koreksi, lalu lanjutkan. Dengan begitu, keputusan yang kurang tepat tidak telanjur menyebar ke semua bagian halaman.

Tips memilih komponen UI

Design system memberi arah visual. Library komponen bisa menyediakan struktur dan perilaku interaktif. Keduanya perlu dipilih berdasarkan kebutuhan produk, bukan karena tampilan demo sebuah library sedang populer.

shadcn/ui itu titik awal, bukan hasil akhir

shadcn/ui menyalin kode komponen ke proyekmu, sehingga kamu bisa mengubahnya sesuai kebutuhan. Jangan berhenti pada tampilan contoh. Periksa apakah tipografi, radius, border, jarak, dan state interaksinya sudah mengikuti sistem desainmu. Ubah yang memang perlu, bukan sekadar mengganti semua nilai agar terlihat berbeda.

Pisahkan perilaku dari gaya

Tombol atau kartu sederhana sering cukup dibuat dengan HTML dan CSS. Untuk dialog, popover, combobox, dan menu, pertimbangkan primitive headless seperti Radix, Base UI, atau React Aria. Library tersebut menangani banyak detail navigasi keyboard, pengelolaan fokus, dan ARIA, sementara gaya visual tetap kamu tentukan. Tetap uji hasil akhirnya: label, indikator fokus, kontras, dan perilaku saat dibuka atau ditutup tidak otomatis benar hanya karena memakai primitive yang aksesibel.

Satu bahasa visual di semua komponen

Kamu bisa memakai lebih dari satu library jika masing-masing mengisi kebutuhan yang berbeda. Yang perlu dijaga adalah hasil akhirnya: tombol, menu, kartu, dan animasi memakai token, state, serta ritme gerak yang selaras. Jika setiap komponen masih membawa gaya bawaan library asalnya, halaman akan terasa seperti kolase.

Komponen “wow” dipakai secukupnya

Library seperti Magic UI atau Aceternity bisa memberi ide untuk interaksi yang menonjol. Pilih efek yang membantu pembaca memahami produk atau menandai momen penting. Jika spotlight, beam, dan teks berkilau muncul di banyak tempat, semuanya berebut perhatian dan konten utama justru tenggelam.

Ikon: satu set, satu ketebalan

Pilih satu set ikon dengan ketebalan garis yang selaras dengan tipografi. Gunakan ikon ketika ia membantu orang mengenali fungsi atau membedakan informasi; kartu fitur tidak selalu membutuhkannya.

Checklist sebelum menambah dependency

Sebelum memasang library baru, jawab pertanyaan berikut:

  • Kebutuhan: Masalah apa yang diselesaikan? Apakah komponen yang sudah ada atau elemen HTML bawaan browser cukup?
  • Kesesuaian: Bisakah tampilan dan perilakunya mengikuti token serta pola interaksi proyek tanpa banyak penimpaan CSS atau solusi sementara?
  • Aksesibilitas: Sudahkah kamu mencoba navigasi keyboard, indikator fokus, label untuk pembaca layar, dan perilaku saat komponen dibuka atau ditutup?
  • Biaya: Setelah dipasang, berapa besar tambahan JavaScript dan CSS yang dikirim ke pengguna? Periksa hasil build, bukan hanya ukuran paket di npm.
  • Pemeliharaan: Apakah library masih diperbarui, kompatibel dengan stack proyek, dan lisensinya sesuai untuk penggunaanmu?

Jika masih ragu, coba satu komponen terlebih dahulu. Lihat hasil render, uji interaksinya, dan ukur dampaknya sebelum memakai library itu di seluruh halaman.

Prinsip: selalu spesifik

Bagian yang tidak kamu jelaskan akan diputuskan oleh model. Semakin penting keputusannya bagi identitas produk, semakin jelas arahan yang perlu kamu beri.

Bandingkan dua prompt ini

Buatkan halaman pricing yang modern dan clean.

Buatkan halaman pricing dengan tiga tier mengikuti DESIGN.md. Layout tabel, bukan kartu. Gunakan nama paket, harga, dan fitur yang saya lampirkan; jangan mengarang isinya. Heading pakai font-display 48px, body 16px dengan line-height 1.6. Pemisah antar baris pakai garis 1px --color-rule, tanpa shadow. Tier tengah ditandai dengan border atas --color-accent setebal 2px, bukan badge “Most Popular”. Lebar maksimum 960px. Di layar sempit, tabel dapat digulir mendatar tanpa memotong harga atau tombol. Pastikan tombol bisa dicapai dengan keyboard dan indikator fokus terlihat. Tanpa gradient, emoji, atau glassmorphism.

Prompt kedua perlu disertai data paket yang sebenarnya dan ditinjau setelah dirender. Namun, keputusan penting tentang konten, tata letak, dan perilaku sudah lebih jelas.

Detail yang sering menentukan hasil

  • Ukuran dan batasan yang penting. “Lega” itu subjektif. Sebutkan ukuran, rentang, atau contoh dari DESIGN.md ketika jarak dan kepadatan menentukan hasil.
  • Pola yang perlu dihindari. Sebutkan larangan yang memang relevan, misalnya tidak memakai gradient jika gaya produk sengaja datar.
  • Konten asli. Lorem ipsum menghasilkan layout lorem ipsum. Panjang judul dan jumlah item yang sebenarnya menentukan bentuk layout.
  • State yang dibutuhkan. Sebutkan hover, focus, loading, kosong, atau error sesuai fungsi komponen; jangan mengarang state untuk elemen statis.
  • Referensi visual. Screenshot dari Refero atau produk yang kamu kagumi bisa memperjelas arah. Jelaskan bagian yang ingin diambil agar model tidak menyalin keseluruhan tampilannya.

Prinsip pendukung

Konsistensi lebih penting daripada kreativitas. Satu sistem yang dipakai disiplin terasa lebih “didesain” daripada sepuluh ide bagus yang saling bertabrakan.

Menahan diri itu fitur. Setiap dekorasi harus bisa menjawab “ini ada untuk apa?”. Kalau jawabannya “biar tidak sepi”, hapus.

Review hasil render. Buka di mobile, zoom ke 200%, dan coba navigasi pakai keyboard. Kode yang terlihat rapi belum tentu menghasilkan halaman yang mudah dibaca dan digunakan.

Pertimbangkan pemilihan model

Ini bagian yang paling sering dilupakan: model yang berbeda menghasilkan desain yang berbeda, bahkan dengan prompt dan DESIGN.md yang sama. Setiap model punya “selera bawaan” dari data dan proses training-nya. Ada yang cenderung menambah dekorasi, ada yang patuh pada token tapi hasilnya kaku, ada yang kuat membaca screenshot, ada yang mulai melupakan aturan setelah sesi panjang.

Saya sengaja tidak membuat peringkat, karena model berganti setiap beberapa bulan dan selera bawaannya ikut berubah. Yang lebih berguna adalah cara mengujinya.

Uji dengan prompt yang sama

Ambil satu prompt spesifik dan satu DESIGN.md, lalu jalankan di dua atau tiga model. Bandingkan hasil render dan kodenya dengan kriteria yang sama:

  • Kepatuhan pada token. Berapa banyak warna, radius, atau spacing di luar sistem yang muncul?
  • Kecenderungan dekorasi. Apakah gradient, shadow, dan ikon muncul padahal tidak diminta?
  • Kemampuan visual. Kalau diberi screenshot, seberapa dekat hasilnya?
  • Daya tahan konteks. Setelah beberapa iterasi, apakah model masih mengikuti batasan yang sudah ditetapkan?
  • Kualitas kode. Apakah strukturnya semantik dan aksesibel, atau tumpukan div?

Bagi peran antar model

Tidak harus satu model untuk semuanya. Model reasoning yang lebih berat cocok untuk merencanakan struktur halaman, hierarki informasi, dan sistem token. Model yang lebih cepat cocok untuk iterasi kecil seperti mengganti spacing atau menambah state. Model dengan kemampuan vision yang kuat cocok untuk membandingkan hasil render dengan referensi.

Evaluasi ulang saat model berganti

Model yang kemarin paling patuh bisa jadi lebih suka dekorasi di versi berikutnya. Simpan prompt uji kamu, dan jalankan lagi setiap kali ganti model default.

Checklist anti slop

  • Referensi dipilih berdasarkan karakter produk, bukan tren.
  • DESIGN.md ada di repo dan dirujuk dari rule agent.
  • Keputusan visual yang berulang memakai token; pengecualian punya alasan.
  • Komponen yang dipakai sesuai kebutuhan dan tampil konsisten dengan sistem desain.
  • Prompt menyebut konten asli, batasan penting, dan state yang dibutuhkan.
  • Efek visual mendukung konten, bukan berebut perhatian dengannya.
  • Saat memilih atau mengganti model, hasilnya dibandingkan dengan prompt yang sama.
  • Hasil direview manual di mobile dan dengan keyboard.

UI yang punya karakter lahir dari keputusan yang jelas, konten yang nyata, dan hasil render yang terus ditinjau.