Di dunia nyata, arahan proyek sering kali berawal dari satu kalimat visi yang abstrak. Kunci keberhasilan seorang Product Engineer adalah kemampuannya membedah visi besar menjadi spesifikasi bertahap yang dieksekusi dengan terukur. 👼 In production, project requirements often start from a single abstract vision. The hallmark of an effective Product Engineer is breaking that broad vision down into disciplined, iterative milestones. 👼
Ada jurang besar antara tahu "apa yang mau dibuat" dan tahu "cara membuatnya". Jembatan di atas jurang itu namanya: memperjelas kebutuhan (requirements). Kalau kamu langsung bilang ke AI "bikinin aplikasi kas kelas", hasilnya bakal umum dan membosankan. Tapi kalau kamu jelasin dulu fitur-fiturnya, hasilnya langsung on-point. 🎯 There's a huge gap between knowing "what to build" and knowing "how to build it". The bridge over that gap is called: clarifying requirements. If you just tell AI "make me a class treasury app", the result will be generic and boring. But if you first explain the features, the result is instantly on-point. 🎯
1. Perjelas kebutuhan — dari samar jadi konkret 📋
2. Validasi satu halaman — bikin halaman inti dulu 🎯
3. Kembangkan multi-halaman — tambah halaman lain 📄
4. Poles & uji — bikin enak dilihat & dipakai 1. Clarify needs — from vague to concrete 📋
2. Validate one page — build the core page first 🎯
3. Expand to multi-page — add the other pages 📄
4. Polish & test — make it look & feel great
Ingat contoh Si Ming dari Pelajaran 4? Kalimat konsepnya: "Untuk bendahara kelas yang sering salah catat uang kas, aplikasi KasKu membantu mencatat pemasukan & pengeluaran otomatis di HP." Sekarang kita bongkar jadi fitur konkret: Remember Ming from Lesson 4? His concept sentence: "For class treasurers who keep mis-recording treasury money, the KasKu app helps log income & expenses automatically on the phone." Now we break it into concrete features:
Aku mau bikin aplikasi bernama KasKu untuk bendahara kelas. Konsepnya: "Untuk bendahara kelas yang sering salah catat uang kas, aplikasi ini membantu mencatat pemasukan & pengeluaran dengan mudah." Pengguna utamanya: pengguna umum / pemilik bisnis (non-teknis). Situasi pakai: narik kas tiap Jumat, bayar jajan kegiatan kelas, laporan ke wali kelas tiap bulan. Bantu aku: 1. Daftar fitur yang wajib ada (prioritas tinggi) 2. Daftar fitur pelengkap (prioritas rendah) 3. Saran halaman-halaman aplikasinya (misal: beranda, catatan, laporan) 4. Apa yang TIDAK perlu dibuat di versi pertamaI want to build an app called KasKu for class treasurers. The concept: "For class treasurers who keep mis-recording treasury money, this app helps log income & expenses easily." Main users: beginner students serving as treasurer (not programmers). Usage situations: weekly collection on Fridays, paying for class events, monthly report to the homeroom teacher. Help me: 1. Must-have features (high priority) 2. Nice-to-have features (low priority) 3. Suggested app pages (e.g. home, records, report) 4. What NOT to build in the first version
AI bakal kasih daftar fitur yang rapi. Tugasmu: pilih maksimal 5 fitur inti untuk versi pertama. Lebih dari itu = resep utama buat gagal total dan nggak selesai-selesai. 🍲💥 Percayalah, bahkan programmer profesional sering terjebak bikin terlalu banyak fitur (disebut feature creep — fitur yang merayap kayak zombie 🧟). AI will give you a clean feature list. Your job: pick at most 5 core features for version one. More than that = the main recipe for failure and never finishing. 🍲💥 Trust us, even professional programmers often fall into building too many features (called feature creep — features creeping in like zombies 🧟).
Jangan minta 5 halaman sekaligus! Mulai dari halaman paling penting (biasanya halaman utama yang melakukan aksi inti). Untuk KasKu: halaman catat pemasukan/pengeluaran. Don't ask for 5 pages at once! Start with the most important page (usually the home page doing the core action). For KasKu: the record income/expense page.
Buatkan halaman web "Catat Transaksi" untuk aplikasi KasKu: - Form input: jenis (masuk/keluar), jumlah uang, keterangan, tanggal - Tombol "Catat" yang menambahkan transaksi ke daftar di bawahnya - Daftar transaksi terbaru (5 terakhir) dengan warna beda untuk pemasukan (hijau) dan pengeluaran (merah) - Saldo total di bagian atas, besar dan jelas - Data tersimpan di localStorage browser (jelaskan cara kerjanya) - Desain mobile-first, tombol besar-besar, warna ceria - Semua teks dalam Bahasa IndonesiaBuild the "Record Transaction" web page for the KasKu app: - Input form: type (income/expense), amount, note, date - A "Record" button that adds the transaction to the list below - A list of the latest 5 transactions with different colors for income (green) and expense (red) - Total balance at the top, big and clear - Data saved in the browser's localStorage (explain how it works) - Mobile-first design, big buttons, cheerful colors - All text in English
Jalankan, tes semua tombolnya, perbaiki yang aneh. Jangan lanjut sebelum halaman ini jalan! Fondasi yang rapuh = rumah yang roboh. 🏚️ Run it, test every button, fix what's off. Don't move on until this page works! A shaky foundation = a collapsed house. 🏚️
Setelah halaman inti jalan, minta AI menambahkan halaman lain satu per satu (ingat: satu permintaan besar = satu bencana; satu permintaan kecil = satu kemenangan 🏆): Once the core page works, ask AI to add other pages one at a time (remember: one huge request = one disaster; one small request = one win 🏆):
Perhatikan: kamu baru aja belajar arsitektur aplikasi tanpa sadar! Halaman-halaman = bagian-bagian aplikasi. localStorage = tempat nyimpen data (versi mini dari database!). Grafik = visualisasi data (pelajaran matematika terpakai juga ternyata 📈😄). Di Level 2, kita bakal bikin versi "dewasa"-nya dengan database sungguhan. Notice: you just learned app architecture without realizing it! Pages = app sections. localStorage = where data lives (a mini version of a database!). Charts = data visualization (math class pays off after all 📈😄). In Level 2, we'll build the "grown-up" version with a real database.
Prototipe yang udah jalan tapi jelek itu kayak kue enak yang penyok — rasanya oke tapi orang males nyoba. 🎂 Waktu poles: A working but ugly prototype is like a delicious but squished cake — tastes fine but nobody wants to try it. 🎂 Time to polish:
Bangun prototipe dari ide pemenangmu sendiri di Pelajaran 4 (boleh juga pakai contoh KasKu kalau butuh panduan). Target akhir pelajaran ini: Build a prototype from your own winning idea in Lesson 4 (you may use the KasKu example if you need guidance). End-of-lesson target:
Kalau mentok di tengah jalan, itu bagian dari pelajaran. Balik ke loop: tanya AI → coba → lapor hasil. Kamu udah punya senjatanya. ⚔️ If you get stuck midway, that's part of the lesson. Back to the loop: ask AI → try → report the result. You already have the weapon. ⚔️
Prototipe itu kayak mie instan sebelum dikasih bumbu: bentuknya udah bener, tinggal disempurnakan. 🍜
Dan kamu baru aja masak mie pertamamu sendiri. Di pelajaran berikutnya, kita kasih bumbu rahasianya: kekuatan AI di dalam produkmu, lalu kita sajikan ke dunia. 🌍 A prototype is like instant noodles before the seasoning: the shape is right, just needs perfecting. 🍜
And you just cooked your first batch yourself. Next lesson, we add the secret seasoning: AI powers inside your product, then we serve it to the world. 🌍