Desain produk tanpa Figma berfungsi jika suatu produk sudah memiliki sistem desain yang matang. Alur kerja desain produk AI saya menggunakan tiga keterampilan agen: ui-design menjelajahi sembilan arah, ui-implement mengubah arah yang dipilih menjadi produk, dan ui-walkthrough meninjau setiap status melalui Agent Browser bawaan. Saya masih membuat keputusan; agen menangani produksi dan pemeriksaan berulang.
Sebagian besar fitur produk tidak dimulai dari halaman kosong. Setelah suatu produk sudah ada selama beberapa waktu, keputusan desain dasarnya sudah ada dalam kode. Tombol, masukan, kartu, navigasi, spasi, warna, penyalinan, status hover, dan perilaku seluler semuanya telah ditentukan. Membangun kembali bagian-bagian tersebut di Figma sering kali berarti menyeret komponen yang sama ke kanvas lain sebelum membangunnya kembali di dalam produk.
Perancang masih membuat keputusan produk. Agen menghilangkan sebagian besar perakitan dan pemeriksaan berulang. Ini berhasil karena Zero sudah memiliki sistem desain yang cukup matang.
1. Mulai desain produk tanpa Figma dengan sistem desain
Bekerja tanpa Figma tidak berarti bekerja tanpa aturan desain. Hal ini memerlukan aturan yang lebih jelas.
Untuk Zero, agen dapat memeriksa:
- Komponen yang ada untuk tombol, input, dropdown, kartu, dialog, dan navigasi
- Jarak, tipografi, warna, batas, dan jari-jari sudut yang ditetapkan
- Status hover, dipilih, dinonaktifkan, kosong, dan seluler yang ada
- Salin konvensi seperti kapitalisasi kalimat dan label pendek yang dapat dilihat pengguna
- Layar nyata yang menunjukkan bagaimana potongan-potongan ini digabungkan
Referensi ini menjawab pertanyaan desain biasa. Masukan baru akan terlihat seperti masukan yang sudah dikirimkan. Kartu baru harus menggunakan permukaan dan radius yang sama dengan kartu terdekat yang sudah ada. Tombol ikon harus memiliki umpan balik hover yang sama dengan tombol ikon lainnya.
Ini memberi agen batasan. Ia dapat mengeksplorasi struktur suatu fitur tanpa menciptakan bahasa visual baru untuk setiap layar.
Figma masih berguna saat tim membuat merek baru, sistem komponen baru, atau interaksi yang tidak memiliki referensi produk dekat. Namun begitu sistemnya matang, produk yang sedang berjalan dapat menjadi permukaan desain utama. Ini adalah versi skala fitur dari alur kerja desain sebagai kode yang kami gunakan untuk membangun kembali Zero.
2. Gunakan ui-design untuk menjelajahi sembilan arah desain produk
Setiap fitur masih perlu eksplorasi. Saya tidak ingin agen mengambil kalimat pertama saya dan segera mengubahnya menjadi kode.
Saya mulai dengan ui-design. Saya memberi agen layar saat ini, masalah pengguna, tujuan, dan batasan utama. Agen membaca pola produk yang ada dan mengembalikan satu arah yang direkomendasikan ditambah sembilan alternatif.
Dalam bahasa sederhananya, keterampilan menangkap layar saat ini, menciptakan satu arah yang direkomendasikan, mengeksplorasi sembilan alternatif berbeda, menyajikan pengorbanan, dan menunggu pilihan manusia.
Pemikiran desain di dalam instruksi ini
Instruksi ini bukan sekedar daftar aturan visual. Ini mengubah proses normal seorang desainer menjadi urutan yang berulang:
- Pahami sebelum melamar. Tangkap layar saat ini dan baca produk di sekitarnya sebelum melakukan apa pun.
- Berpikir dalam sistem. Perlakukan komponen yang ada, halaman template, pola interaksi, dan aturan penyalinan sebagai bahan awal.
- Mencegah penemuan kembali. AI cenderung menciptakan pola baru ketika petunjuknya tidak jelas. Instruksi memerintahkannya untuk menemukan komponen atau halaman terdekat yang dikirimkan dan menggunakannya kembali alih-alih memperkirakan dari memori.
- Jelajahi sebelum memilih. Jangkar After memberikan satu arah yang masuk akal. Kesembilan varian tersebut membuka keputusan berbeda tentang tata letak, hierarki, kepadatan, titik masuk, dan pengungkapan.
- Pisahkan eksplorasi dari komitmen. Agen berhenti setelah memberikan opsi. Manusia membandingkan pengorbanan dan memilih sebelum kode dimulai.
- Tinjau seluruh pengalaman. Salin, arahkan masukan, status, perilaku seluler, dan konsistensi visual adalah bagian dari desain, bukan pembersihan setelah penerapan.
Itulah sistem pemikiran yang saya inginkan dari keterampilan: memahami produk yang ada, mengeksplorasi di dalamnya, dan kemudian membuat pilihan yang jelas.
Berikut adalah instruksi asli lengkap, yang direproduksi kata demi kata dari alur kerja langsung:
Instruksi asli lengkap untuk ui-design
# vm0 / Zero Aturan Desain UI
## Alur kerja — visual dulu, kode nanti
**Jangan langsung ke kode.** Saat keterampilan ini dipanggil, hasil pertama selalu berupa serangkaian maket yang dirender untuk dilihat Ming. Implementasi hanya terjadi setelah arah dipilih.
### Langkah 1 — Tangkap "sebelum"
- Jika layar sudah ada, render statusnya saat ini sebagai gambar **sebelum** (screenshot aplikasi yang sedang berjalan, atau render komponen yang ada sebagai pratinjau statis).
- Jika permintaannya adalah untuk layar baru, "sebelum" adalah layar terdekat yang ada atau keadaan kosong — buatlah hal ini secara eksplisit dalam keterangan.
### Langkah 2 — Buat satu jangkar "setelah".
- Satu mockup yang mewakili interpretasi tebakan terbaik Anda atas permintaan tersebut, sepenuhnya mematuhi setiap aturan di bawah ini (komponen, kapitalisasi kalimat, input/dropdown detail agen, jari-jari kartu komposer obrolan, tombol tambahkan jadwal, iconButton melayang, permukaan abu-abu-50).
- Pasangkan dengan **sebelum** secara berdampingan. Beri label dengan jelas: `Before` / `After`.
### Langkah 3 — Hasilkan 9 eksplorasi varian
Setelah pasangan sebelum/sesudah, buat **9 varian mockup berbeda** untuk layar yang sama. Setiap varian harus mengeksplorasi sumbu desain yang sangat berbeda — bukan 9 perubahan warna. Tutupi spread seperti:
1. Tata letak — kolom tunggal vs. split / sidebar / grid
2. Kepadatan — kompak vs. luas
3. Hierarki — elemen mana yang memimpin secara visual
4. Perawatan permukaan — bagian datar vs. dikelompokkan kartu vs. terbagi
5. Titik masuk — aksi sebaris vs. CTA khusus vs. pahlawan keadaan kosong
6. Salin pembingkaian — instruktif vs. minimal vs. percakapan
7. Pengungkapan - segala sesuatu yang terlihat vs. pengungkapan / akordeon progresif
8. Komposisi - berdasarkan konten vs. berdasarkan kontrol
9. Arah yang sengaja tidak konvensional / "wild card" yang patut dilihat sekali
Setiap varian harus tetap menghormati hal-hal yang tidak dapat dinegosiasikan (huruf besar/kecil, komponen penggunaan kembali, gaya input/dropdown detail agen, jari-jari komposer obrolan, tombol tambahkan jadwal, iconButton hover, abu-abu-50 netral). Varian mengeksplorasi *tata letak dan penekanan*, bukan "bagaimana jika kita mengabaikan sistem desain".
### Langkah 4 — Presentasikan, lalu tunggu
- Tampilkan semua gambar ke Ming dalam satu pesan: pasangan `Before / After` terlebih dahulu, kemudian 9 varian bernomor 1–9 dengan keterangan satu baris yang masing-masing menggambarkan sumbu yang sedang dieksplorasi.
- Tanyakan arah mana (atau campuran mana) yang harus dikejar.
- Jangan memulai implementasi sampai Ming menentukan arah.
### Merender gambar
- Jalur pilihan: buat pratinjau HTML/React statis yang menggunakan token Tailwind asli dari `turbo/apps/platform`, tangkapan layarnya, dan unggah melalui `okou web upload-file`.
- Untuk eksplorasi cepat: keterampilan `v0` dapat menghasilkan maket varian dari sebuah perintah — tetapi perintah tersebut harus secara eksplisit menyebutkan aturan di bawah ini (huruf kalimat, masukan detail agen, radius komposer obrolan, dll.) sehingga v0 tidak menghasilkan UI SaaS generik.
- Jika pembuatan gambar tidak tersedia untuk sesi tersebut, kembalilah ke ASCII / wireframe tekstual yang diberi label jelas untuk semua 11 frame (sebelum, sesudah, 9 varian) dan sebutkan hal ini — jangan pernah melewatkan langkah visual secara diam-diam.
---
# Aturan Desain
Ini adalah konvensi desain yang tidak dapat dinegosiasikan untuk setiap UI baru yang dikirimkan dalam platform vm0 (`turbo/apps/platform`). Terapkan sebelum menulis komponen, dan audit PR yang ada terhadap komponen tersebut selama peninjauan.
## Prinsip inti
1. **Gunakan kembali, jangan menemukan kembali.** Selalu periksa primitif yang ada di `turbo/apps/platform/src/components/` dan pola tingkat tampilan di bawah `src/views/` sebelum memperkenalkan komponen baru. Jika interaksi serupa sudah dikirimkan dalam detail agen, jadwal, atau pembuat obrolan, salin pola tersebut daripada merancang pola paralel.
2. **Cocok dengan bahasa desain Zero.** Permukaan lembut, abu-abu netral, jari-jari lebar, tepi halus, tanpa bayangan tajam. Garis dasar visualnya adalah "tenang, berpendirian keras, sedikit editorial" — tidak pernah menjadi standar SaaS.
3. **Bicaralah dari kursi pengguna.** Salinan harus menjelaskan apa yang *mereka* akan lakukan atau lihat, bukan apa yang sedang dilakukan sistem. Singkat saja — biasanya satu kalimat, maksimal dua.
## Pola referensi (salin langsung)
| Elemen | Sumber referensi | Mengapa |
|---------------------|---------------------------------------------------|-----|
| Masukan teks/area teks | Masukan halaman detail agen (`src/views/agent-detail/`) | Padding, batas, status fokus, perlakuan placeholder yang ditetapkan |
| Tarik-turun / pilih | Dropdown halaman detail agen | Gaya pemicu yang ditetapkan, radius menu, item hover, penempatan tanda centang |
| Jari-jari kartu/panel | Kartu komposer obrolan (cari komponen `composer`) | Menetapkan radius kartu kanonik dan gaya permukaan di seluruh aplikasi |
| Tombol halaman utama | Tombol "Tambahkan jadwal" pada halaman jadwal | Primer netral-gelap digunakan di mana pun *di luar* modals |
| Tombol utama modal | Warna utama merek (hanya di dalam dialog/popover) | Modal mempertahankan warna utama merek; halaman tidak |
| Tombol khusus ikon | IconButton yang ada dengan latar belakang hover | Setiap ikon yang dapat diklik harus memiliki status hover yang terlihat |
Jika ragu, buka komponen referensi di basis kode, baca props dan nama kelasnya, lalu cerminkan. Jangan memperkirakan dari ingatan.
## Pedoman copy
- **Ungkapan perspektif pengguna.** "Hubungkan kotak masuk Anda" mengalahkan "Koneksi kotak masuk diperlukan". "Belum ada agen" mengalahkan "Daftar agen kosong".
- **Singkatnya dibandingkan kelengkapan.** Kalimat pendek mengungguli kalimat lengkap. Pangkas pengisi ("sederhana", "tolong", "untuk").
- **Kapitalisasi kalimat untuk semuanya.** Label, judul, tombol, item menu, kolom tabel — semua kapitalisasi kalimat ("Penyedia model", "kunci API", "Tambahkan jadwal"). Jangan Pernah Judul Kasus. Jangan pernah `uppercase` melalui CSS pada header bagian. Jika Anda menemukan label Judul atau huruf kapital semua, perbaiki.
- **Tidak ada label "dekoratif" dengan huruf kapital** di atas kolom atau bagian — terbaca sesuai format y dan diberi tanggal. Gunakan label biasa atau lewati label jika kolomnya sudah jelas.
- **Tidak ada tanda baca tambahan** pada label atau tombol mandiri. Titik untuk body copy dan teks pembantu.
- Saat mengganti nama string, ambil basis kode untuk string lama dan uji string tersebut — label direferensikan dalam pengujian dan terjemahan.
## Komponen dan struktur
- Selalu buat halaman dari komponen yang ada (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitif, dll.). Komponen baru adalah pilihan terakhir dan memerlukan alasan.
- Cari tata letak/templat yang ada (halaman pengaturan, halaman daftar, halaman detail) dan warisi perancahnya. Jangan turunkan ulang struktur halaman.
- Saat menambahkan ke halaman gaya pengaturan, cocokkan jarak bagian, perlakuan pembagi, dan lebar baris formulir yang digunakan oleh bagian tetangga.
## Tombol
- **Halaman utama** (CTA utama pada suatu halaman) → cocokkan dengan tombol "Tambahkan jadwal" pada halaman jadwal. Ini adalah dialog luar aplikasi utama yang netral gelap/padat.
- **Modal primer** (tombol konfirmasi di dalam dialog/popover) → menggunakan warna primer merek. Halaman tidak.
- **Tombol sekunder / hantu** → gunakan kembali varian yang ada; jangan menciptakan yang baru.
- **Tombol ikon** → harus memiliki latar belakang hover (biasanya `hover:bg-gray-50` atau token hover IconButton yang sudah ada). Jangan pernah mengirimkan ikon tanpa hover sebagai target klik.
- Semua tombol harus mengikuti token ketinggian yang ada — jangan memperkenalkan ukuran satu kali saja.
## Input
- Cerminkan input detail agen: bantalan yang sama, batas yang sama, cincin fokus yang sama (atau kekurangannya — periksa referensi sebelum menambahkan cincin fokus), warna placeholder yang sama.
- Multi-baris: gunakan pola textarea detail agen (baris tumbuh otomatis atau tetap seperti dalam referensi).
- Jangan beri tanda titik dua di akhir label bidang.
- Teks pembantu di bawah masukan, dalam warna abu-abu teredam, satu baris.
## Dropdown / pilih
- Cerminkan dropdown detail agen: tampilan pemicu yang sama, radius menu yang sama, padding item yang sama, status hover/pilihan yang sama.
- Menu tidak boleh lebih lebar dari pemicunya kecuali jika konten memintanya.
- Hindari submenu bertumpuk kecuali dropdown yang ada sudah menggunakannya.
## Kartu dan permukaan
- Jari-jari kartu dan gaya permukaan cocok dengan kartu pembuat obrolan. Jangan memperkenalkan radius yang lebih kecil atau lebih besar tanpa alasan.
- Batasnya tidak kentara (garis rambut tunggal pada tanda batas yang ada). Tidak ada drop shadow kecuali penulis obrolan menggunakannya.
- Permukaan netral pada isian seluler / abu-abu muda (latar belakang pil aktif, isian wadah ikon, dll.) → `bg-gray-50`. `gray-100` dan `gray-200` berulang kali disebut terlalu gelap — dimulai dari `gray-50`.
## Fokus dan interaksi
- Jangan tambahkan bayangan kotak atau kerangka `:focus-visible` khusus ke elemen navigasi/pemasaran — gunakan kembali pergeseran warna hover. (Pengekangan yang sama umumnya berlaku di dalam platform kecuali komponen referensi memiliki cincin fokus yang eksplisit.)
- Setiap elemen interaktif (tombol, tombol ikon, baris, tautan) memerlukan status hover yang terlihat. Uji dengan mengarahkan kursor ke masing-masing sebelum mempertimbangkan desain yang sudah selesai.
- Status yang dinonaktifkan menggunakan token nonaktif yang ada; jangan menggulung warna yang pudar dengan tangan.
## Tinjau daftar periksa
Sebelum menyatakan UI siap, pelajari:
1. Apakah saya menggunakan kembali komponen yang sudah ada dibandingkan membuat yang baru?
2. Apakah saya cocok dengan templat/tata letak halaman yang ada?
3. Apakah masukan secara visual identik dengan masukan detail agen?
4. Apakah dropdown secara visual identik dengan dropdown detail agen?
5. Apakah kartu cocok dengan radius dan permukaan pembuat obrolan?
6. Apakah setiap kalimat label bersifat kasus? Adakah Judul Kasus yang tersisa atau huruf kapital semua?
7. Apakah salinannya pendek dan ditulis dari kursi pengguna?
8. Apakah halaman utama merupakan tombol bergaya "Tambahkan jadwal"? Apakah merek utama hanya digunakan di dalam modals?
9. Apakah setiap tombol ikon memiliki latar belakang hover?
10. Apakah saya mengarahkan kursor ke setiap elemen interaktif untuk mengonfirmasi masukan?
Jika ada jawaban “tidak”, perbaiki sebelum membuka PR.
## Ketika ragu
- Buka komponen referensi, baca sumbernya, dan salin strukturnya.
- Jika dua komponen referensi tidak setuju, pilih komponen yang baru dikirimkan (periksa git log).
- Jika desain tersebut benar-benar membutuhkan primitif baru, sampaikan hal tersebut kepada Ming sebelum membuatnya — kumpulan karya desain ulang menjadi bagian dari satu PR dengan dia sebagai peninjau.
Sembilan opsi tidak harus berupa sembilan desain jadi. Tugas mereka adalah memberi saya jangkauan yang cukup untuk melihat masalah secara berbeda dan bergerak ke arah yang benar. Jika sebuah konsep berada di luar produk saat ini, prototipe React yang berdiri sendiri masih dapat membantu. Untuk fitur ini, saya tetap berada di dalam sistem produk sebenarnya.
Contoh nyata: navigasi Zero
Zero awalnya memiliki satu sidebar 300 piksel yang berisi tujuan produk, agen yang disematkan, dan rangkaian obrolan. Ia melakukan tiga pekerjaan sekaligus. Saya ingin memisahkan pekerjaan tersebut tanpa mengubah area percakapan.
Ringkasan produk untuk eksplorasi ini adalah:
/ui-designPutar ulang fase desain untuk navigasi tiga wilayah Zero dari basis sejarah sebenarnya. Pisahkan tujuan produk, agen, dan percakapan ke dalam wilayah yang lebih jelas tanpa mengubah area percakapan. Gunakan token, ikon, dan komponen Zero asli. Menghasilkan Sebelum yang sesuai sumber, satu Setelah yang kuat, dan sembilan varian yang benar-benar berbeda. Jangan mengedit kode produk atau menampilkan mockup sebagai bukti browser.
Eksplorasi pertama terlalu hati-hati. Beberapa opsi mengubah lebar dan gaya pemilihan, namun tetap tampak seperti sidebar yang sama. Saya menolak set tersebut dan meminta agen untuk membuat perbedaan terlihat pada tingkat arsitektur informasi.
Putaran kedua menghasilkan sembilan arah yang benar-benar berbeda. Saya mengelompokkannya ke dalam tabel 3×3 agar mudah dibandingkan tanpa membuat artikel menjadi strip gambar yang panjang. Setiap thumbnail terbuka di penampil gambar blog.
| 1. Navigasi teratas | 2. Laci yang dapat dilipat | 3. Utas pertama |
|---|---|---|
 |  |  |
| Pindahkan tujuan di atas percakapan | Sembunyikan tujuan sampai diperlukan | Jadikan percakapan sebagai objek navigasi utama |
| 4. Agen terlebih dahulu | 5. Percakapan dulu | 6. Peluncur perintah |
 |  |  |
| Pilih agen sebelum threadnya | Letakkan agen yang disematkan di atas percakapan aktif | Buka tujuan dari menu yang dapat dicari |
| 7. Rel yang dapat diperluas | 8. Entri dasbor | 9. Dermaga bawah |
 |  |  |
| Perluas rel sempit hanya jika diperlukan | Mulai dari pekerjaan terkini | Pindahkan tujuan ke bawah |
Saya tidak memilih salah satu bingkai ini persis seperti yang digambar. Saya menggunakannya untuk memutuskan apa yang harus tetap ada dan apa yang harus diubah. Arah terakhir menggunakan jalur tujuan yang sempit, jalur obrolan terpisah, lima agen yang terlihat disematkan, dan area percakapan yang ada.
Keluaran penting dari ui-design bukanlah gambarnya saja. Itu adalah catatan keputusan singkat:
- Pertahankan jalur tujuan 68 piksel dan jalur obrolan 300 piksel
- Tampilkan lima slot agen yang disematkan
- Jaga agar pilihan tetap tenang tetapi mudah dibaca
- Tampilkan panduan penyusunan ulang hanya sambil menyeret
- Pertahankan percakapan dan laci ponsel yang ada tidak berubah
Itu sudah cukup untuk memulai implementasi.
3. Gunakan ui-implement untuk mengubah desain yang dipilih menjadi kode
Setelah saya memilih arah dan menghubungkan basis kode produk, agen langsung bekerja dalam kode. Saya tidak menggambar ulang frame yang dipilih di Figma terlebih dahulu.
Secara sederhana, ui-implement melewatkan eksplorasi karena arahnya sudah dipilih. Ia menemukan komponen dan struktur halaman terdekat, membangunnya, mengaudit hasilnya, dan memverifikasi fitur di browser.
Apa yang dilindungi oleh instruksi ini
- Arah yang dipilih tidak boleh didesain ulang selama implementasi.
- Agen harus memulai dengan halaman komponen dan templat terdekat yang sudah ada.
- Penggunaan kembali akan memenangkan komponen baru kecuali produk tersebut memiliki celah yang nyata.
- Audit mandiri dan pemeriksaan browser menemukan salinan, status, dan interaksi yang tidak konsisten.
- Jika keputusan produk masih belum terselesaikan, pekerjaan akan dikembalikan ke
ui-design.
Beginilah cara sistem desain tetap aktif selama implementasi. Ini bukan dokumen yang dibaca agen sekali saja. Ini membentuk komponen mana yang dipilihnya dan bagaimana ia memeriksa pengalaman akhir.
Berikut adalah instruksi asli lengkap, yang direproduksi kata demi kata dari alur kerja langsung:
Instruksi asli lengkap untuk ui-implement
# vm0 / Zero Aturan Implementasi UI
## Alur Kerja — terapkan secara langsung
Saat keterampilan ini dipanggil, **lewati fase mockup dan eksplorasi varian**. Segera mulai terapkan di `turbo/apps/platform`, terapkan setiap aturan desain di bawah.
### Langkah 1 — Temukan komponen referensi
Sebelum menulis baris, buka komponen referensi yang akan Anda cerminkan:
- Masukan / area teks → masukan `src/views/agent-detail/`
- Tarik-turun / pilih → tarik-turun `src/views/agent-detail/`
- Jari-jari kartu/panel → kartu komposer obrolan
- Tombol utama halaman → tombol "Tambahkan jadwal" pada halaman jadwal
- Tombol hanya ikon → `IconButton` yang ada dengan latar belakang hover
Baca alat peraga dan nama kelasnya. Cerminkan mereka — jangan memperkirakan dari ingatan.
### Langkah 2 — Temukan templat halaman terdekat yang ada
Buka halaman terdekat yang ada dengan bentuk yang sama (pengaturan, daftar, detail) dan warisi perancahnya: spasi bagian, perlakuan pembagi, lebar baris formulir. Jangan turunkan ulang struktur halaman.
### Langkah 3 — Bangun, lalu audit mandiri
Implementasikan layar dengan primitif yang ada dari `turbo/apps/platform/src/components/`. Jika Anda merasa sudah selesai, ikuti **Daftar Periksa Tinjauan** di bagian bawah keterampilan ini sebelum melaporkannya kembali. Perbaiki setiap jawaban “tidak” sebelum menyatakan pekerjaan selesai.
### Langkah 4 — Verifikasi di browser
Untuk pekerjaan UI apa pun, mulai server pengembang dan gunakan fitur tersebut di browser sebelum melaporkan tugas telah selesai. Arahkan kursor ke setiap elemen interaktif, uji jalur emas dan kasus tepi, dan perhatikan regresi di layar yang berdekatan. Periksa pengetikan dan uji verifikasi kode, bukan kebenaran fitur — jika Anda tidak dapat membuka browser, sampaikan secara eksplisit.
### Kapan harus kembali ke ui-design
Jika permintaan bersifat terbuka ("rancang halaman pengaturan untuk X") tanpa arah yang dipilih, hentikan dan jalankan keterampilan `ui-design` sebagai gantinya — varian sebelum/sesudah + 9 ada untuk kasus tersebut. `ui-implement` adalah ketika arahnya sudah ditentukan.
---
# Aturan Desain
Ini adalah konvensi desain yang tidak dapat dinegosiasikan untuk setiap UI baru yang dikirimkan dalam platform vm0 (`turbo/apps/platform`). Terapkan saat membangun, dan audit perbedaan Anda sendiri sebelum membuka PR.
## Prinsip inti
1. **Gunakan kembali, jangan menemukan kembali.** Selalu periksa primitif yang ada di `turbo/apps/platform/src/components/` dan pola tingkat tampilan di bawah `src/views/` sebelum memperkenalkan komponen baru. Jika interaksi serupa sudah dikirimkan dalam detail agen, jadwal, atau pembuat obrolan, salin pola tersebut daripada merancang pola paralel.
2. **Cocok dengan bahasa desain Zero.** Permukaan lembut, abu-abu netral, jari-jari lebar, tepi halus, tanpa bayangan tajam. Garis dasar visualnya adalah "tenang, berpendirian keras, sedikit editorial" — tidak pernah menjadi standar SaaS.
3. **Bicaralah dari kursi pengguna.** Salinan harus menjelaskan apa yang *mereka* akan lakukan atau lihat, bukan apa yang sedang dilakukan sistem. Singkat saja — biasanya satu kalimat, maksimal dua.
## Pola referensi (salin langsung)
| Elemen | Sumber referensi | Mengapa |
|---------------------|---------------------------------------------------|-----|
| Masukan teks/area teks | Masukan halaman detail agen (`src/views/agent-detail/`) | Padding, batas, status fokus, perlakuan placeholder yang ditetapkan |
| Tarik-turun / pilih | Dropdown halaman detail agen | Gaya pemicu yang ditetapkan, radius menu, item hover, penempatan tanda centang |
| Jari-jari kartu/panel | Kartu komposer obrolan (cari komponen `composer`) | Menetapkan radius kartu kanonik dan gaya permukaan di seluruh aplikasi |
| Tombol halaman utama | Tombol "Tambahkan jadwal" pada halaman jadwal | Primer netral-gelap digunakan di mana pun *di luar* modals |
| Tombol utama modal | Warna utama merek (hanya di dalam dialog/popover) | Modal mempertahankan warna utama merek; halaman tidak |
| Tombol khusus ikon | IconButton yang ada dengan latar belakang hover | Setiap ikon yang dapat diklik harus memiliki status hover yang terlihat |
Jika ragu, buka komponen referensi di basis kode, baca props dan nama kelasnya, lalu cerminkan. Jangan memperkirakan dari ingatan.
## Pedoman copy
- **Ungkapan perspektif pengguna.** "Hubungkan kotak masuk Anda" mengalahkan "Koneksi kotak masuk diperlukan". "Belum ada agen" mengalahkan "Daftar agen kosong".
- **Singkatnya dibandingkan kelengkapan.** Kalimat pendek mengungguli kalimat lengkap. Pangkas pengisi ("sederhana", "tolong", "untuk").
- **Kapitalisasi kalimat untuk semuanya.** Label, judul, tombol, item menu, kolom tabel — semua kapitalisasi kalimat ("Penyedia model", "kunci API", "Tambahkan jadwal"). Jangan Pernah Judul Kasus. Jangan pernah `uppercase` melalui CSS pada header bagian. Jika Anda menemukan label Judul atau huruf kapital semua, perbaiki.
- **Tidak ada label "dekoratif" dengan huruf kapital** di atas kolom atau bagian — terbaca sesuai format y dan diberi tanggal. Gunakan label biasa atau lewati label jika kolomnya sudah jelas.
- **Tidak ada tanda baca tambahan** pada label atau tombol mandiri. Titik untuk body copy dan teks pembantu.
- Saat mengganti nama string, ambil basis kode untuk string lama dan uji string tersebut — label direferensikan dalam pengujian dan terjemahan.
## Komponen dan struktur
- Selalu buat halaman dari komponen yang ada (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitif, dll.). Komponen baru adalah pilihan terakhir dan memerlukan alasan.
- Cari tata letak/templat yang ada (halaman pengaturan, halaman daftar, halaman detail) dan warisi perancahnya. Jangan turunkan ulang struktur halaman.
- Saat menambahkan ke halaman gaya pengaturan, cocokkan jarak bagian, perlakuan pembagi, dan lebar baris formulir yang digunakan oleh bagian tetangga.
## Tombol
- **Halaman utama** (CTA utama pada suatu halaman) → cocokkan dengan tombol "Tambahkan jadwal" pada halaman jadwal. Ini adalah dialog luar aplikasi utama yang netral gelap/padat.
- **Modal primer** (tombol konfirmasi di dalam dialog/popover) → menggunakan warna primer merek. Halaman tidak.
- **Tombol sekunder / hantu** → gunakan kembali varian yang ada; jangan menciptakan yang baru.
- **Tombol ikon** → harus memiliki latar belakang hover (biasanya `hover:bg-gray-50` atau token hover IconButton yang sudah ada). Jangan pernah mengirimkan ikon tanpa hover sebagai target klik.
- Semua tombol harus mengikuti token ketinggian yang ada — jangan memperkenalkan ukuran satu kali saja.
## Input
- Cerminkan input detail agen: bantalan yang sama, batas yang sama, cincin fokus yang sama (atau kekurangannya — periksa referensi sebelum menambahkan cincin fokus), warna placeholder yang sama.
- Multi-baris: gunakan pola textarea detail agen (baris tumbuh otomatis atau tetap seperti dalam referensi).
- Jangan beri tanda titik dua di akhir label bidang.
- Teks pembantu di bawah masukan, dalam warna abu-abu teredam, satu baris.
## Dropdown / pilih
- Cerminkan dropdown detail agen: tampilan pemicu yang sama, radius menu yang sama, padding item yang sama, status hover/pilihan yang sama.
- Menu tidak boleh lebih lebar dari pemicunya kecuali jika konten memintanya.
- Hindari submenu bertumpuk kecuali dropdown yang ada sudah menggunakannya.
## Kartu dan permukaan
- Jari-jari kartu dan gaya permukaan cocok dengan kartu pembuat obrolan. Jangan memperkenalkan radius yang lebih kecil atau lebih besar tanpa alasan.
- Batasnya tidak kentara (garis rambut tunggal pada tanda batas yang ada). Tidak ada drop shadow kecuali penulis obrolan menggunakannya.
- Permukaan netral pada isian seluler / abu-abu muda (latar belakang pil aktif, isian wadah ikon, dll.) → `bg-gray-50`. `gray-100` dan `gray-200` berulang kali disebut terlalu gelap — dimulai dari `gray-50`.
## Fokus dan interaksi
- Jangan tambahkan bayangan atau kerangka kotak `:focus-visible` khusus ke elemen navigasi/pemasaran — gunakan kembali pergeseran warna hover. (Pengekangan yang sama umumnya berlaku di dalam platform kecuali komponen referensi memiliki cincin fokus yang eksplisit.)
- Setiap elemen interaktif (tombol, tombol ikon, baris, tautan) memerlukan status hover yang terlihat. Uji dengan mengarahkan kursor ke masing-masing sebelum mempertimbangkan desain yang sudah selesai.
- Status yang dinonaktifkan menggunakan token nonaktif yang ada; jangan menggulung warna yang pudar dengan tangan.
## Tinjau daftar periksa
Sebelum menyatakan UI siap, pelajari:
1. Apakah saya menggunakan kembali komponen yang sudah ada dibandingkan membuat yang baru?
2. Apakah saya cocok dengan templat/tata letak halaman yang ada?
3. Apakah masukan secara visual identik dengan masukan detail agen?
4. Apakah dropdown secara visual identik dengan dropdown detail agen?
5. Apakah kartu cocok dengan radius dan permukaan pembuat obrolan?
6. Apakah setiap kalimat label bersifat kasus? Adakah Judul Kasus yang tersisa atau huruf kapital semua?
7. Apakah salinannya pendek dan ditulis dari kursi pengguna?
8. Apakah halaman utama merupakan tombol bergaya "Tambahkan jadwal"? Apakah merek utama hanya digunakan di dalam modals?
9. Apakah setiap tombol ikon memiliki latar belakang hover?
10. Apakah saya mengarahkan setiap elemen interaktif di browser untuk mengonfirmasi masukan?
Jika ada jawaban “tidak”, perbaiki sebelum membuka PR.
## Ketika ragu
- Buka komponen referensi, baca sumbernya, dan salin strukturnya.
- Jika dua komponen referensi tidak setuju, pilih komponen yang baru dikirimkan (periksa git log).
- Jika desain tersebut benar-benar membutuhkan primitif baru, sampaikan hal tersebut kepada Ming sebelum membuatnya — kumpulan karya desain ulang menjadi bagian dari satu PR dengan dia sebagai peninjau.
Ini adalah perintah penerapan khusus fitur:
/ui-implementMulai dari revisi
04d642bb. Tambahkan pemisahan desktop default-off dengan rel tujuan 68 piksel, rel obrolan 300 piksel, dan percakapan yang tidak diubah. Pertahankan sidebar 300px yang lama saat tombol dalam keadaan mati dan pada perangkat seluler. Render lima slot yang disematkan, pertahankan urutan yang ditentukan pengguna, dan tampilkan kemampuan pemesanan ulang hanya selama drag aktif. Jangan memeriksa fitur historis atau penyempurnaan selanjutnya hingga patch independen, pengujian, dan bukti browser dibekukan.
Untuk fitur navigasi, saya meminta agen untuk tetap menggunakan sidebar lama saat fitur nonaktif, menampilkan tata letak tiga bagian baru saat aktif, mempertahankan laci seluler yang ada, dan mengizinkan orang untuk menyusun ulang agen yang disematkan.
Selama implementasi, agen menemukan satu masalah penting. Produk lama mengingat agen mana yang disematkan, tetapi tidak mengingat pesanannya. Interaksi tarik mungkin terlihat benar dan kemudian disetel ulang setelah penyegaran.
Jadi agen melakukan lebih dari sekedar menarik keadaan drag. Itu membuat pesanan baru tetap ada, menyegarkan halaman, dan memeriksa apakah pesanan tetap ada. Hal ini juga menegaskan bahwa pengaturan ulang hanya muncul selama drag dan menghilang setelahnya.
Pengiriman implementasi menunjukkan dua status desktop yang perlu saya tinjau. Saya menunjukkannya dengan lebar penuh sehingga antarmuka tetap dapat dibaca. Perilaku seluler muncul kemudian dalam penelusuran sebagai tangkapan telepon dengan kepadatan tinggi.
Status istirahat desktop
Pemesanan ulang aktif
Pada titik ini saya memiliki fitur yang berfungsi, bukan file desain lainnya. Namun penerapannya masih belum berakhir. Saya perlu melihat apa yang sebenarnya berjalan di pratinjau yang diterapkan.
4. Gunakan ui-walkthrough untuk mengulas produk sebenarnya
Penelusuran produk dulunya membosankan. Saya akan membuka pratinjau yang diterapkan, menyiapkan akun yang tepat, mengaktifkan dan menonaktifkan fitur, mengeklik setiap kontrol, mengubah ukuran browser, mengambil tangkapan layar, dan mencoba mengingat status yang diwakili oleh setiap gambar.
Agen tersebut memiliki Agent Browser bawaan, jadi saya dapat menyerahkan pekerjaan itu padanya.
Alur kerja memiliki dua langkah utama:
- Buat daftar skenario terlebih dahulu. Agen mengubah klaim desain dan implementasi menjadi daftar periksa.
- Jalankan daftar periksa dan lampirkan bukti. Ia menjalankan setiap skenario dalam pratinjau yang diterapkan dan menampilkan PASS, FAIL, atau BLOCKED dengan tangkapan layar untuk setiap keadaan yang bermakna.
Apa yang diubah oleh instruksi ini tentang ulasan
- Agen mencantumkan skenario sebelum mulai mengklik.
- Ia menggunakan komponen yang diterapkan secara nyata melalui Agent Browser bawaannya.
- Ini menangkap satu tangkapan layar untuk setiap keadaan yang bermakna.
- Ini menandai setiap pos pemeriksaan PASS, FAIL, atau BLOCKED.
- Ia tidak pernah menyembunyikan keadaan yang tidak tersedia di balik bukti tiruan.
Ini mengubah klik manual menjadi paket ulasan yang terorganisir. Saya dapat melihat perilaku yang diinginkan, hasil, dan buktinya bersama-sama.
Instruksi lengkapnya ada di bawah. Saya telah menerjemahkan nama ketergantungan internal menjadi "Agent Browser bawaan" untuk kejelasan bagi pembaca; logika alur kerja tidak berubah.
Instruksi asli lengkap untuk ui-walkthrough
# Panduan UI
QA visual menyeluruh dari fitur front-end vm0/Zero dalam pratinjau per-PR sebenarnya. Alur kerja ini menentukan apa yang harus diverifikasi dan bagaimana melaporkan hasilnya; itu tidak mendefinisikan perkakas operasi UI.
## Ketergantungan yang diperlukan: Agent Browser bawaan
Gunakan Agent Browser bawaan sebagai satu-satunya sumber kebenaran untuk setiap interaksi UI, termasuk:
- Menemukan dan membuka pratinjau per-PR.
- Penanganan perlindungan pratinjau dan pengaturan sesi.
- Pendaftaran, OTP, orientasi, checkout pengujian Stripe, dan mengakses aplikasi langsung.
- Mengaktifkan peralihan fitur.
- Menavigasi, berinteraksi dengan kontrol, menyediakan data pengujian atau tiruan, mengambil tangkapan layar, mengunggah artefak, pemecahan masalah, dan pembersihan.
Baca dan ikuti instruksi bawaan Agent Browser sebelum mengambil tindakan UI apa pun. Jangan menduplikasi perintah khusus runtime, pengaturan mesin, mekanisme pemilih, skrip konteks halaman, manajemen sesi, atau metode pembersihan proses dalam alur kerja ini. Jika Agent Browser bawaan berubah, instruksi saat ini akan diutamakan.
## Kapan harus digunakan
- Telusuri UI permintaan tarik vm0 dalam pratinjau yang diterapkan.
- Verifikasi fitur dalam aplikasi yang memerlukan autentikasi, orientasi, penagihan, peralihan fitur, atau rangkaian obrolan sebenarnya.
- Tangkap tangkapan layar yang sesuai atau video panduan singkat tentang fitur yang berfungsi di aplikasi langsung.
## Alur kerja penelusuran
### 1. Menetapkan sasaran dan ruang lingkup
- Identifikasi PR, komitmen utama, perubahan perilaku yang terlihat pengguna, dan pratinjau yang diharapkan.
- Konfirmasikan bahwa pratinjau yang diterapkan sesuai dengan kepala PR sebelum pengujian.
- Baca perbedaan dan deskripsi PR untuk mendapatkan jalur kritis dan keadaan yang menunjukkan perubahan.
- Jangan memperbaiki kode, menyelesaikan konflik, atau mengubah perilaku produk selama penelusuran kecuali pengguna secara terpisah meminta penerapan.
### 2. Jangkau fitur tersebut
Gunakan Agent Browser bawaan untuk masuk ke pratinjau dan mencapai status fitur langsung. Ikuti aturan saat ini untuk autentikasi, orientasi, penagihan, peralihan fitur, dan bypass hanya pratinjau.
Jika bypass digunakan, ungkapkan dalam laporan akhir. Jangan pernah menggunakan bypass orientasi saat orientasi itu sendiri sedang diuji.
### 3. Tentukan matriks keadaan visual
Sebelum berinteraksi, buat daftar kumpulan status terkecil yang membuktikan bahwa fitur tersebut berfungsi. Sertakan item yang berlaku:
- Keadaan awal/default.
- Status terbuka, arahkan kursor, fokus, dipilih, diperluas, atau aktif.
- Status yang kosong dan berpenduduk.
- Status diaktifkan dan dinonaktifkan.
- Status sukses, validasi, pemuatan, dan kesalahan.
- Penempatan, tabrakan, flip, kliping, dan perilaku responsif.
- Pengiriman atau tindakan hilir ketika fitur bersifat interaktif.
Lebih suka melakukan perubahan perilaku yang sebenarnya daripada tes asap umum.
### 4. Jalankan komponen aktif
Gunakan Agent Browser bawaan untuk semua teknik interaksi dan data uji.
Konten tiruan atau yang disuntikkan hanya dapat digunakan untuk menempatkan komponen aplikasi nyata ke dalam keadaan visual deterministik. Komponen, gaya, dan interaksi yang dinilai harus tetap merupakan implementasi langsung dari pratinjau PR.
Untuk setiap status yang diolok-olok:
- Catat konten atau prasyarat mana yang diejek.
- Bedakan konten tiruan dari perilaku aplikasi nyata.
- Jangan pernah menyiratkan bahwa teks atau data tiruan berasal dari model atau sumber produksi.
- Lakukan kontrol nyata dan pengkabelan hilir di mana pun lingkungan memungkinkan.
### 5. Tangkap bukti
Gunakan Agent Browser bawaan untuk menangkap dan mengunggah bukti untuk pos pemeriksaan utama. Setiap gambar harus membuktikan satu keadaan yang bermakna, bukan mengulangi pandangan yang sama.
Jika pengguna meminta video, buatlah panduan singkat dengan teks dari pos pemeriksaan terverifikasi. Teks harus mengidentifikasi tindakan pengguna dan hasil yang diharapkan tanpa mengaburkan UI.
### 6. Menyampaikan dan melaporkan
Laporan:
- Tautan PR, URL pratinjau yang tepat, dan uji komit jika tersedia.
- Alur pengguna yang tepat diterapkan.
- Uji akun saat akun dibuat.
- `PASS`, `FAIL`, atau `BLOCKED` untuk setiap pos pemeriksaan.
- Tautan tangkapan layar dan tautan video opsional dengan deskripsi singkat.
- Sakelar fitur, bypass, data tiruan, dan pengaturan khusus pengujian lainnya yang digunakan.
- Pemeriksaan yang gagal, pemblokir lingkungan, atau kesenjangan verifikasi.
Jangan mengklaim bahwa fitur tersebut telah diverifikasi kecuali alur pratinjau langsung telah dilakukan dan bukti telah diambil. Jika pratinjau tidak tersedia, laporkan `BLOCKED` dengan bukti penerapan daripada mengganti replika lokal atau statis.
Ini adalah panduan panduan khusus fitur:
/ui-walkthroughGunakan pratinjau yang diterapkan melalui Agent Browser bawaan sebagai satu-satunya kebenaran browser. Buktikan sidebar fitur-off, pemisahan 68px dan 300px, urutan tujuan, status hover, lima slot yang disematkan, pegangan hanya tarik, penyusunan ulang yang bertahan, pemilihan utas, pengguliran, dan laci iPhone lengkap. Kembalikan PASS, FAIL, atau BLOCKED untuk setiap pos pemeriksaan. Jangan ganti keadaan yang tidak dapat dijangkau dengan replika.
Untuk fitur ini, agen mengatur panduan seputar pertanyaan-pertanyaan berikut:
- Apakah sidebar lama masih berfungsi saat fitur dinonaktifkan?
- Apakah struktur desktop baru muncul saat aktif?
- Apakah arahkan kursor dan status yang dipilih terlihat tetapi senyap?
- Apakah lima agen yang disematkan dapat dibaca?
- Apakah kontrol penyusunan ulang tetap tersembunyi hingga drag dimulai?
- Apakah tatanan baru ini dapat bertahan dalam penyegaran?
- Bisakah saya memilih dan menelusuri thread asli?
- Apakah laci seluler yang ada masih berfungsi?
- Apakah semua tujuan navigasi ada dan dalam urutan yang benar?
Agen kemudian membuka pratinjau yang diterapkan sebagai pengguna baru, menyelesaikan orientasi, mengaktifkan fitur, dan mengerjakan daftar. Ini menguji status istirahat, status hover, status drag, perilaku penyegaran, pemilihan utas, pengguliran, dan tata letak telepon.
Hasilnya 11 PASS, 1 FAIL.
Kegagalan itu bermanfaat. Tata letak dan interaksinya berhasil, tetapi pratinjau yang diterapkan hanya menunjukkan enam tujuan produk. Activity dan Insights hilang, dan pesanan tidak sesuai dengan desain yang dipilih.
| Skenario | Hasil |
|---|---|
| Sidebar lama dengan fitur nonaktif | PASS |
| Tata letak desktop tiga bagian baru | PASS |
| Arahkan kursor dan status yang dipilih | PASS |
| Lima agen yang disematkan | PASS |
| Panduan penyusunan ulang hanya tarik | PASS |
| Pesanan disimpan setelah penyegaran | PASS |
| Pemilihan dan pengguliran utas | PASS |
| Laci seluler yang ada | PASS |
| Isi dan urutan tujuan | FAIL |
Pengiriman terakhir adalah kumpulan tangkapan layar yang terorganisir, bukan folder gambar tanpa label. Tangkapan desktop berukuran 1440 × 900 piksel dan tangkapan ponsel berukuran 1170 × 2532 piksel. Mereka muncul satu per satu di bawah sehingga antarmuka tetap dapat dibaca; klik gambar mana pun untuk memperbesarnya tanpa meninggalkan artikel.
Fitur nonaktif
Fitur diaktifkan
Tata letak desktop
Tujuan melayang
Arahkan agen yang disematkan
Tarikan aktif
Pesanan tersimpan
Laci ponsel
Ini memungkinkan saya meninjau fitur secara terstruktur. Saya dapat melihat skenario yang diinginkan, hasil penerapan aktual, dan bukti bersama-sama. Jika ada yang gagal, saya tahu persis ke mana pekerjaan itu harus dikembalikan.
Bagaimana sebuah tim mengadopsi alur kerja desain produk AI ini
Proses lengkapnya singkat. Rekan tim dapat menyimpan setiap tahapan sebagai berbagi alur kerja Zero alih-alih membangun kembali proses dari memori.
| Panggung | Masukan | Keluaran |
|---|---|---|
ui-design | Layar saat ini, masalah, tujuan, dan kendala | Satu arah yang direkomendasikan, sembilan alternatif, dan catatan desain yang dipilih |
ui-implement | Catatan desain yang dipilih | Perubahan kode yang dapat ditinjau dan tangkapan layar dari status utama |
ui-walkthrough | Fitur yang diterapkan dan perilaku yang diharapkan | Daftar skenario terorganisir dengan tangkapan layar PASS, FAIL, atau BLOCKED |
Rekan satu tim tidak perlu meniru selera desain saya. Mereka perlu memberikan konteks yang baik, menggunakan sistem produk bersama, membuat pilihan eksplisit setelah eksplorasi, dan meninjau bukti browser. Tiga titik pemeriksaan manusia yang sama—masalah, arah, dan penerimaan—juga membentuk cara kita mengelola agen AI seperti sebuah tim.
Alur kerja ini tidak menghilangkan praktik desain atau pemikiran desain. Hal ini menggerakkan mereka ke bagian-bagian yang paling penting bagi mereka: mendefinisikan masalah, menetapkan batasan, membandingkan arah, memilih pengorbanan, dan menilai produk yang sedang berjalan.
Ketika sistem komponen sudah matang, saya tidak perlu lagi membangun kembali setiap fitur sebagai blok yang dapat diseret di Figma. Saya dapat bekerja dengan agen secara langsung dalam produk, sementara sistem desain menjaga konsistensi keluaran dan penelusuran menjaga hasilnya tetap jujur.
Pertanyaan yang sering diajukan
Bagaimana Anda membangun alur kerja desain produk AI?
Mulailah dengan sistem produk yang ada, bukan perintah kosong. Pisahkan pekerjaan menjadi eksplorasi, implementasi, dan review. Biarkan agen menghasilkan opsi dan melakukan pemeriksaan berulang, namun tetap bertanggung jawab pada perancang produk atas masalahnya, arah yang dipilih, dan penerimaan akhir.
Bisakah desainer produk bekerja tanpa Figma?
Ya, bila produk sudah memiliki komponen, templat halaman, dan pola interaksi yang stabil. Figma tetap berguna untuk bahasa visual baru atau interaksi yang asing. Intinya bukan untuk melarang Figma; hal ini untuk menghindari membangun kembali keputusan produk yang diketahui pada kanvas kedua.
Apakah AI menggantikan desainer produk?
Tidak dalam alur kerja ini. Agen menyusun opsi, mengedit kode, dan memeriksa skenario. Perancang masih membingkai masalah, menetapkan batasan, membandingkan pengorbanan, memilih arah, dan memutuskan apakah produk yang sedang berjalan cukup baik untuk dikirimkan.
