Claude Design Sebelum Coding: Cara Merapikan UI SaaS Tanpa Terjebak Feature Bloat

Banyak project vibecoding gagal bukan karena AI-nya tidak bisa menulis code. Masalahnya muncul lebih awal: semua fitur ingin dimasukkan, flow belum jelas, lalu coding dimulai sebelum produknya benar-benar kebayang.

Dashboard ada. Chat ada. AI ada. CRM ada. Automation juga ikut masuk.

Secara teknis kelihatan lengkap. Begitu dipakai, user malah bingung harus mulai dari mana.

Di titik ini Claude lebih berguna sebagai partner design dan product thinking, bukan sekadar mesin pembuat code. Kita bisa memakainya untuk mengubah ide yang masih berantakan menjadi mockup, user flow, struktur landing page, dashboard, dan prototype yang lebih mudah dibahas sebelum waktu habis di development.

Claude Design itu apa?

Claude Design bukan nama untuk desain final yang langsung siap dilempar ke production. Cara pakainya lebih masuk akal sebagai jembatan antara planning dan build.

Ide yang awalnya cuma ada di kepala dibuat kelihatan dulu. Setelah itu kita bisa mengecek:

• user masuk dari mana;
• tindakan utama yang harus dilakukan;
• informasi apa yang perlu muncul lebih dulu;
• fitur mana yang masuk versi pertama;
• bagian mana yang masih terlalu ramai;
• state penting seperti loading, error, empty state, dan hasil akhir.

Output awalnya boleh berupa struktur layar, wireframe, mockup, prototype, atau code front-end sederhana. Nilai utamanya bukan pada "sekali prompt langsung cantik", tetapi pada proses review yang jadi lebih cepat dan konkret.

Kenapa desain perlu dibuat sebelum coding?

Kesalahan UI yang ditemukan saat masih berupa mockup jauh lebih murah daripada kesalahan flow yang baru terasa setelah backend, database, dan integrasi selesai dibuat.

Bayangkan sebuah SaaS AI dengan fungsi utama mengubah foto. Versi awal sebenarnya hanya butuh alur pendek:

1. user memahami hasil yang akan didapat;
2. user mengunggah foto;
3. user memilih gaya;
4. sistem memproses;
5. user melihat atau mengunduh hasil.

Kalau planning belum beres, tim mudah menambahkan dashboard kompleks, referral, banyak menu, analytics, history, marketplace, dan setting lanjutan sebelum alur utamanya terbukti dipakai.

Claude bisa membantu membuat beberapa versi flow lalu membandingkannya. Bukan untuk mengambil keputusan produk sendirian, tetapi supaya founder, developer, dan designer punya objek yang sama untuk dibahas.

Mindset ini nyambung dengan cara kami memandang acceptance criteria menggunakan EARS Pattern. Requirement yang bisa diuji akan menghasilkan instruksi yang lebih tajam daripada prompt seperti "buat dashboard modern".

Masalah terbesar bukan estetika, tapi hierarchy

UI yang terlihat "AI banget" biasanya bukan cuma soal warna gradient atau card yang terlalu banyak. Akar masalahnya sering ada pada hierarchy.

User tidak tahu mana headline utama, tombol pertama, status proses, atau langkah berikutnya. Semua elemen diberi bobot visual yang hampir sama.

Sebelum meminta Claude merapikan tampilan, tentukan empat hal:

1. Satu tujuan per layar

Dashboard tidak harus memamerkan seluruh kemampuan produk. Kalau tujuan layar pertama adalah membuat project baru, tombol tersebut harus paling mudah ditemukan.

2. Satu primary action

Dua atau tiga tombol boleh ada, tetapi hanya satu yang menjadi jalur utama. Tombol lain harus terlihat sebagai secondary action.

3. Urutan informasi

Susun informasi berdasarkan keputusan user, bukan berdasarkan struktur database. User biasanya ingin tahu apa yang bisa dilakukan, apa input yang diperlukan, berapa lama prosesnya, dan apa hasilnya.

4. State yang nyata

Mockup happy path saja belum cukup. Minta Claude menunjukkan empty state, loading, error, limit habis, dan hasil berhasil. Di sinilah banyak prototype terlihat bagus tetapi rapuh saat dipakai.

Cara memberi brief ke Claude agar hasil UI tidak generic

Prompt yang terlalu pendek membuat Claude mengisi kekosongan dengan pola dashboard umum. Hasilnya memang rapi, tetapi sering terasa sama dengan ribuan template SaaS lain.

Brief yang lebih usable setidaknya menjelaskan:

• siapa user-nya;
• masalah utama yang ingin diselesaikan;
• tindakan utama pada layar;
• data atau konten yang tersedia;
• komponen yang wajib ada;
• komponen yang tidak boleh masuk;
• referensi visual;
• constraint mobile dan desktop;
• acceptance criteria.

Contoh brief yang lemah:

Buat dashboard SaaS AI yang modern dan premium.

Contoh yang lebih jelas:

Rancang dashboard pertama untuk SaaS AI pengolah foto.
User utamanya pemilik studio kecil yang tidak teknis.
Primary action: upload foto dan mulai project baru.
Tampilkan sisa kredit, tiga project terakhir, dan status proses.
Jangan tambahkan analytics, team management, referral, atau menu marketplace.
Buat versi desktop dan mobile.
Sertakan empty state, processing state, error upload, dan result state.
Gunakan hierarchy yang jelas dan satu primary CTA per layar.

Prompt kedua tidak menjamin hasil final sempurna. Tapi ruang tebakannya jauh lebih kecil.

Kalau ingin melihat pola instruksi yang lebih terstruktur untuk pekerjaan agent, baca juga Agentic, Tapi Deterministic: Workflow AI Agent yang Bisa Diaudit. Prinsipnya sama: AI boleh fleksibel, tetapi scope, batas, dan kondisi selesai harus jelas.

Workflow praktis dari ide sampai prototype

Berikut alur yang lebih waras untuk project kecil sampai menengah.

Langkah 1: tulis problem dan user

Jangan mulai dari daftar fitur. Tulis siapa user-nya, apa yang sedang mereka coba selesaikan, dan kenapa cara sekarang terasa lambat atau membingungkan.

Langkah 2: tentukan core flow

Pilih satu perjalanan terpenting. Untuk MVP, prioritaskan flow yang membuktikan manfaat produk. Fitur pendukung bisa menyusul setelah flow utama terasa enak.

Langkah 3: minta beberapa opsi struktur

Gunakan Claude untuk membuat dua atau tiga versi hierarchy. Bandingkan jumlah langkah, kejelasan CTA, beban informasi, dan risiko user tersesat.

Langkah 4: pilih satu arah, lalu kritik

Jangan terus meminta variasi tanpa keputusan. Pilih satu, lalu minta Claude mengkritiknya dari sisi user baru, mobile, accessibility, empty state, dan error recovery.

Langkah 5: ubah menjadi prototype

Setelah flow disetujui, baru turunkan ke mockup yang lebih detail atau code prototype. Jangan sambungkan semua backend lebih dulu. Tes dulu apakah orang paham produk tanpa penjelasan panjang.

Langkah 6: tulis acceptance criteria

Contohnya:

When user membuka dashboard tanpa project, sistem menampilkan empty state dan tombol Buat Project.
When user mengunggah file yang tidak didukung, sistem menolak file dan menjelaskan format yang diterima.
While proses berjalan, sistem menampilkan status yang bisa dipahami tanpa refresh manual.

Langkah 7: baru masuk development

Setelah layar, flow, state, dan batas MVP jelas, coding agent punya context yang lebih baik. Iterasi tetap akan terjadi, tetapi tidak dimulai dari kegelapan.

Studi kasus kelas: membangun KotakFoto.id

Kelas Jago Claude Design memakai KotakFoto.id sebagai studi kasus. Produknya adalah SaaS AI yang mengubah foto biasa menjadi konsep album atau prewedding dengan arah visual yang lebih editorial.

Yang dibedah bukan hanya cara membuat layar terlihat bagus. Peserta melihat bagaimana ide produk dipecah menjadi value proposition, flow upload, pilihan gaya, sistem kredit, halaman hasil, dan tampilan yang layak dipakai untuk demo serta validasi market.

Materinya mencakup mindset desain SaaS, prompting untuk UI, struktur landing page, dashboard dan user flow, design improvement, sampai proses dari ide ke prototype. Targetnya builder, founder, freelancer, developer, creator, dan pemula yang ingin membuat produk AI lebih jelas tanpa harus menjadi UI/UX designer profesional lebih dulu.

Siapa yang paling cocok belajar ini?

Kelas seperti ini masuk akal kalau Anda berada di salah satu kondisi berikut:

• produk sudah bisa jalan tetapi tampilannya masih sulit dijelaskan;
• sering membuat prototype, tetapi flow-nya berubah terus saat coding;
• ingin menawarkan jasa web, automation, atau AI dengan presentasi yang lebih meyakinkan;
• punya ide SaaS dan butuh bentuk visual sebelum membangun backend;
• sering memakai AI coding tools, tetapi belum punya proses review UI yang rapi.

Kalau masalah utama Anda ada pada backend kompleks, scaling, atau arsitektur distributed system, kelas UI design tentu bukan jawaban lengkap. Fokusnya adalah membuat ide produk lebih terbaca, flow lebih pendek, dan prototype lebih siap diuji.

Untuk proses coding yang lebih besar dan melibatkan banyak agent, artikel Claude Code Workflows: Cara Pakai Dynamic Workflows yang Benar membahas orchestration, verification, stop condition, dan cost boundary. Jangan dicampur: Claude Design membantu merapikan bentuk dan flow produk, sedangkan dynamic workflow membantu mengatur pekerjaan engineering yang lebih luas.

Cara ikut Kelas Jago Claude Design

Kalau Anda ingin belajar prosesnya dari nol dengan studi kasus nyata, buka halaman kelas melalui link berikut:

Lihat detail dan daftar Kelas Jago Claude Design

Link tersebut menggunakan kode referral Rama Digital dan membawa Anda ke halaman resmi kelas. Baca materi, format kelas, jadwal, dan ketentuannya sebelum mendaftar.

Kesimpulan operasional

Jangan mulai coding saat value proposition, core flow, dan primary action masih kabur.

Pakai Claude untuk membuat ide terlihat lebih cepat. Kritik hasilnya. Buang fitur yang belum perlu. Uji apakah orang memahami produknya tanpa presentasi panjang. Setelah itu baru coding.

Kalau di mockup saja user masih bingung, versi production biasanya tidak akan menyelamatkannya.