Tips menulis permintaan
SingkatnyaSebutkan untuk siapa aplikasinya, apa yang dilakukan orang di dalamnya, dan apa yang harus terjadi selanjutnya. Jelaskan seluruh aplikasi di permintaan pertama, lalu minta satu perubahan setiap kali. Gunakan Rencana saat Anda belum yakin, Percakapan untuk bertanya tanpa mengubah apa pun, dan mode edit atau Cuplikan untuk menunjuk yang Anda maksud. Jika ada yang rusak, sebutkan apa yang Anda lakukan, apa yang Anda harapkan, dan apa yang terjadi — lalu gunakan Versi untuk kembali.
MonstarX membangun apa yang Anda minta, jadi cara Anda meminta itu penting. Anda tidak perlu kata-kata khusus atau istilah teknis — bahasa sehari-hari justru paling baik. Tips berikut membantu Anda mendapatkan yang Anda inginkan dengan lebih sedikit permintaan, yang juga berarti lebih hemat kuota penggunaan paket Anda.
Seperti apa permintaan yang baik?
Section titled “Seperti apa permintaan yang baik?”Permintaan yang baik menjawab tiga pertanyaan, dengan kata-kata Anda sendiri:
- Untuk siapa? “Anggota studio yoga saya”, “tim dukungan kami”, “orang tua yang memesan guru les”.
- Apa yang mereka lakukan di dalamnya? “Melihat jadwal kelas minggu ini dan memesan tempat”, “mencari pesanan dan mengembalikan dana”.
- Apa yang harus terjadi selanjutnya? “Kirim email konfirmasi”, “tampilkan reservasi di halaman Reservasi saya”.
Tambahkan apa pun yang benar-benar penting bagi Anda — nama, tampilan, aturan (“setiap kelas menampung 12 orang”), hal yang tidak boleh dilakukan — dan lewati yang tidak penting. MonstarX mengisi kekosongan dengan pilihan yang masuk akal, dan Anda bisa mengubahnya nanti.
Permintaan yang lemah dan yang lebih baik
Section titled “Permintaan yang lemah dan yang lebih baik”| Lemah | Lebih baik | Mengapa lebih baik |
|---|---|---|
| “Aplikasi reservasi” | “Situs reservasi untuk studio yoga saya: jadwal kelas mingguan, batas tempat untuk setiap kelas, fitur masuk untuk anggota, dan email konfirmasi saat seseorang memesan.” | Menyebutkan untuk siapa, apa yang dilakukan orang, dan apa yang terjadi sesudahnya. |
| “Buat tampilannya lebih bagus” | “Gunakan palet hijau lembut dan krem, font serif untuk judul, dan jarak lebih lega di antara baris jadwal.” | Menyebutkan perubahannya, jadi tidak ada yang perlu ditebak. |
| “Perbaiki bug-nya” | “Di halaman Pesan, kelas yang sudah penuh masih bisa saya pesan. Seharusnya muncul ‘Kelas penuh’ dan tombol Masuk daftar tunggu.” | Menyebutkan di mana, apa yang terjadi, dan apa yang seharusnya terjadi. |
| “Tambahkan pembayaran, ulasan, blog, peta, dan newsletter” | “Tambahkan bagian Ulasan di halaman setiap guru: anggota bisa memberi rating 1–5 bintang dan komentar.” (lalu permintaan berikutnya) | Satu fitur setiap kali lebih mudah diperiksa dan lebih mudah dibatalkan. |
| “Ubah tombolnya” | Klik tombol itu di mode Edit lalu tulis: “Ubah tulisannya menjadi ‘Kelas pertama gratis’.” | Menunjuk langsung menghilangkan keraguan soal tombol mana yang dimaksud. |
| “Buat seperti Airbnb” | “Tampilkan kelas sebagai kartu dengan foto besar di atas, jam dan nama guru di bawahnya, serta tombol Pesan di setiap kartu.” — dan lampirkan tangkapan layar. | Menjelaskan (dan menunjukkan) bagian yang Anda suka, bukan seluruh produk lain. |
Sebaiknya minta seluruh aplikasi atau satu fitur setiap kali?
Section titled “Sebaiknya minta seluruh aplikasi atau satu fitur setiap kali?”Keduanya, di saat yang berbeda:
- Permintaan pertama boleh menjelaskan seluruh aplikasi. MonstarX mengubahnya menjadi rencana fitur — daftar periksa yang dikerjakan satu fitur demi satu fitur — jadi permintaan pertama dengan lima atau enam fitur tidak masalah. Lihat Rencana fitur.
- Setelah itu, minta satu perubahan atau satu fitur per permintaan. Setiap proses membangun menyimpan versinya sendiri, jadi jika ada yang salah, Anda bisa membatalkan yang itu saja. Perubahannya juga lebih mudah diperiksa.
Punya beberapa hal sekaligus? Kirim satu per satu: selagi MonstarX membangun, permintaan baru di mode Bangun menunggu di antrean dan mulai dengan sendirinya. Lihat Antrean permintaan.
Kapan sebaiknya memakai mode Rencana?
Section titled “Kapan sebaiknya memakai mode Rencana?”MonstarX punya tiga mode, di atas kotak prompt di setiap proyek: Bangun mengubah aplikasi, Rencana bertanya dulu lalu membangun, dan Percakapan menjawab tanpa mengubah apa pun. Untuk aplikasi baru, sakelar Rencanakan dulu di halaman Proyek berfungsi sama seperti Rencana.
Gunakan Rencana saat Anda belum yakin, atau saat sebuah fitur bisa dibuat dengan beberapa cara yang sama-sama masuk akal. MonstarX mengajukan beberapa pertanyaan, satu per satu, masing-masing dengan saran jawaban yang tinggal dipilih — siapa penggunanya, apa namanya, seperti apa tampilannya — lalu membangun setelah Anda menjawab.
Prosesnya sedikit lebih lama, tetapi menghemat permintaan yang biasanya habis untuk “bukan begitu maksudnya”. Lihat Rencanakan dulu.
Bagaimana cara bertanya tanpa mengubah apa pun?
Section titled “Bagaimana cara bertanya tanpa mengubah apa pun?”Beralihlah ke mode Percakapan. MonstarX bisa membaca kode, melihat data, membuka halaman, dan membaca log untuk menjawab Anda, tetapi tidak pernah mengubah aplikasi. Mode ini tepat untuk:
- “Kenapa jadwal menampilkan kelas minggu lalu?”
- “Apa yang dibutuhkan untuk menambahkan pembayaran?”
- “Halaman mana saja yang bisa dilihat orang tanpa masuk?”
Jika jawabannya mengusulkan perubahan yang Anda suka, klik Bangun ini di bawahnya: MonstarX beralih ke mode Bangun dan mengerjakannya. Pertanyaan di mode Percakapan langsung dijawab, bahkan saat proses membangun sedang berjalan. Lihat Mode.
Bagaimana cara menunjukkan maksud saya kepada MonstarX?
Section titled “Bagaimana cara menunjukkan maksud saya kepada MonstarX?”Kata-kata tidak selalu jalan tercepat. Tunjukkan saja:
-
Mode edit — klik Edit di atas pratinjau, klik elemen atau tandai area, lalu sebutkan apa yang perlu diubah di sana. Anda bisa menandai hingga 20 perubahan dan mengirim semuanya sekaligus. Lihat Mode edit.
-
Cuplikan — klik Cuplikan, seret kotak di sekitar bagian mana pun di halaman, dan gambar bagian itu masuk ke pesan Anda beserta halaman asalnya. Cocok untuk “ini kelihatan salah” atau “samakan ini dengan itu”. Lihat Cuplikan.
-
Lampirkan gambar — tangkapan layar aplikasi yang Anda suka, sketsa, mockup, atau logo Anda. Lihat Lampirkan file.
-
Lampirkan dokumen — RFP, spesifikasi, catatan rapat, atau spreadsheet berisi data Anda. MonstarX membacanya dan membangun berdasarkan isinya. Lihat Bangun dari dokumen dan Bangun dari spreadsheet.
Apa yang harus saya lakukan saat ada masalah?
Section titled “Apa yang harus saya lakukan saat ada masalah?”-
Jelaskan apa yang Anda lihat secara tepat. Sebutkan halamannya, apa yang Anda lakukan, apa yang Anda harapkan, dan apa yang terjadi. Salin pesan kesalahan apa adanya, kata demi kata.
-
Tunjukkan. Gunakan Cuplikan pada bagian yang rusak, atau lampirkan tangkapan layar.
-
Tanyakan dulu sebelum memperbaiki, jika Anda ragu. Di mode Percakapan, tanyakan “Kenapa kelas yang sudah penuh masih bisa dipesan?” MonstarX memeriksanya dan menjelaskan, lalu Bangun ini memperbaikinya.
-
Jika sebuah perubahan malah memperburuk keadaan, kembali. Buka Versi dan Pulihkan versi sebelumnya, lalu minta lagi dengan detail yang lebih lengkap. Data aplikasi Anda tidak terpengaruh. Lihat Versi.
Jika perbaikan yang sama terus gagal, coba dari sudut lain: pecah menjadi langkah-langkah yang lebih kecil, jelaskan aturannya alih-alih gejalanya, atau ganti pemilih model dari Otomatis ke model yang lebih kuat untuk permintaan itu saja. Lihat Pilih model dan Pemecahan masalah.
Tips lainnya
Section titled “Tips lainnya”- Gunakan sebutan yang dipakai pelanggan Anda. “Kelas”, “anggota”, “matras” — MonstarX memakai kata-kata Anda di aplikasi.
- Sebutkan apa yang harus tetap sama. “Ganti warna header, tetapi biarkan logo dan menu seperti sekarang.”
- Sebutkan jumlah dan besarannya. “12 tempat per kelas”, “harga dalam rupiah”, “tampilkan 20 per halaman”.
- Minta kontennya juga. “Tulis halaman Tentang Kami untuk studio lingkungan yang ramah” menghasilkan teks sungguhan, bukan teks pengisi.
- Uji sebagai pengguna sungguhan. Masuk dengan Akun demo yang diberikan MonstarX dan coba aplikasinya seperti pelanggan Anda nanti — lalu sampaikan kepada MonstarX apa yang terasa janggal.
- Jangan pernah menempelkan kata sandi atau kunci API di percakapan. Saat aplikasi membutuhkan kunci sebuah layanan, MonstarX menampilkan kartu untuk menambahkannya dengan aman, atau tambahkan sendiri di Backend → Rahasia. Lihat Rahasia.
- Bahasa apa pun bisa. Tulis dalam bahasa yang paling nyaman bagi Anda, dan minta aplikasi dalam bahasa apa pun yang dipakai pelanggan Anda.
Pertanyaan umum
Section titled “Pertanyaan umum”Seberapa panjang sebuah permintaan boleh ditulis?
Hingga 100.000 karakter, dan hingga 10 file lampiran. Sebagian besar permintaan yang baik hanya satu sampai lima kalimat.
Apakah saya perlu memakai istilah teknis?
Tidak. Bahasa sehari-hari justru paling baik. Sebutkan apa yang harus bisa dilakukan orang, dan MonstarX memilih cara membangunnya.
MonstarX melakukan sesuatu yang tidak saya minta. Lalu bagaimana?
Pulihkan versi sebelumnya dari Versi, lalu minta lagi dan sebutkan apa yang tidak boleh berubah. Anda juga bisa bertanya di mode Percakapan mengapa MonstarX memilih cara itu.
Mana yang lebih baik: satu permintaan panjang atau beberapa yang pendek?
Untuk aplikasi baru, satu permintaan yang menjelaskan seluruh aplikasi tidak masalah — MonstarX merencanakannya sebagai daftar periksa. Untuk perubahan, beberapa permintaan pendek lebih baik: setiap proses membangun menjadi versinya sendiri, mudah diperiksa dan mudah dibatalkan.
Bisakah saya menulis permintaan dalam bahasa lain?
Bisa. Tulis dalam bahasa apa pun, dan minta aplikasi dalam bahasa yang dipakai pelanggan Anda. MonstarX sendiri bisa ditampilkan dalam 16 bahasa, dari bahasa Inggris dan Jepang hingga Arab dan Hausa — lihat Bahasa.