Belajar UX Designer - UX untuk AI Products
Merancang pengalaman untuk produk berbasis AI — UX chatbot/LLM, pola streaming, error handling AI, dan evaluasi kualitas — dengan praktik mendesain fitur AI ringkasan status untuk JagaKota.
#Pendahuluan
Setelah di episode 21-23 kita merancang agen, percakapan, dan dorongan perilaku, kini kita melihat satu hal yang menyatukan semuanya: produk yang benar-benar berisi AI. Tidak semua fitur AI itu chatbot — AI bisa meringkas, mengklasifikasi (episode 20), mencari, dan menyusun antarmuka (episode 21). Tantangan UX-nya unik: keluaran tidak selalu bisa diprediksi, bisa salah dengan percaya diri, dan butuh waktu.
Mengapa penting? Karena UX produk AI bukan UX biasa yang diberi AI — ia disiplin baru dengan pola sendiri: streaming, hallways of error, dan evaluasi yang tidak berhenti di "apakah tombolnya bisa diklik".
#Pola UX Khas Produk AI
#1. Chat/Agent Interface
Kombinasi pola dari episode 21 dan 22: tempat pengguna berinteraksi dengan model bahasa (LLM). Aturan praktisnya: bukan layar kosong dengan input — berikan contoh pertanyaan, capabilities, dan batasan di awal.
#2. Streaming: Tampilkan Proses, Bukan Kesunyian
LLM butuh detik untuk menjawab. Jangan tampilkan layar berputar kosong — tampilkan streaming hasil token demi token (atau setidaknya indikator "sedang menulis…"). Streaming menjaga prinsip visibility of system status (episode 8) sekaligus mengecilkan kesan lambat.
[ Sedang merangkum 5 laporan terbaru… ]
→ "Laporan #4831 (Banjir, Kel. Melati) menunggu verifikasi lapangan…
" ← token muncul bertahap, bukan menunggu selesai#3. Error Handling AI: Kejujuran Itu Desain
Model salah menjawab dengan sangat yakin (halusinasi). UX-nya:
- Sertakan sumber: ringkasan AI menampilkan "Berdasarkan laporan #4831-4835" yang bisa diklik.
- Beri keterbatasan: "Ringkasan otomatis dapat keliru — periksa detailnya."
- Tawarkan ulang: tombol "Coba ringkas ulang" lebih baik daripada mengutuk layar.
- Fallback jelas: saat model gagal, tampilkan pesan jujur + data mentah yang masih bisa dipakai.
#4. Guardrails: Membatasi Wilayah AI
Fitur AI paling aman adalah yang wilayahnya sempit. Untuk JagaKota, perbedaan cakupan menentukan tingkat risiko:
| Cakupan | Contoh | Risiko | Desain |
|---|---|---|---|
| Sempit, data sendiri | Ringkas laporan milik pengguna | Rendah | Label + sumber cukup |
| Sedang, data publik | Ringkas status per wilayah | Sedang | Wajib verifikasi manusia |
| Luas, input bebas | Menjawab semua pertanyaan warga | Tinggi | Batasi, guardrails, eskalasi |
Semakin luas cakupan, semakin banyak lapisan keamanan (content filter, human review) yang dibutuhkan.
Warning
Aturan paling penting: jangan pernah menutupi kegagalan AI dengan UI yang percaya diri. Produk yang menyajikan halusinasi sebagai fakta menghancurkan kepercayaan — terutama untuk layanan publik seperti JagaKota di mana keputusan berdampak nyata. Saat ragu, tampilkan sumber, beri label, dan undang verifikasi manusia.
#Evaluasi Kualitas UX AI
Produk AI butuh evaluasi berlapis — tidak cukup hanya usability:
| Lapisan | Pertanyaan | Metode |
|---|---|---|
| Quality | Apakah jawabannya benar dan relevan? | Human eval, golden set |
| Safety | Apakah ada konten berbahaya? | Red team, guardrails |
| UX | Apakah pengguna paham kapan harus percaya? | Usability test (episode 12) |
| Business | Apakah fitur menaikkan metrik kunci? | Eksperimen (episode 14) |
Untuk JagaKota, contoh golden set: 50 pertanyaan warga yang khas ("berapa lama laporan diproses?", "bagaimana status laporan saya?") dengan jawaban referensi. Setiap perubahan prompt dievaluasi terhadap set ini — penurunan akurasi = jangan ship.
#Mendesain Fitur AI JagaKota
Praktik episode ini — rancang Ringkasan Laporan AI:
Input : 5 laporan terbaru pengguna (data yang sudah ada).
Output : 2-3 kalimat ringkasan + 1 saran tindakan.
Label : "Ringkasan otomatis" di header.
Sumber : setiap klaim bisa diklik ke laporan asli.
Fail : jika model error, tampilkan daftar laporan mentah.
Eval : golden set 50 skenario, akurasi >= 90% untuk ship.Perhatikan keputusan desainnya: AI diberi wilayah sempit (ringkas laporan yang sudah ada) — bukan wilayah luas (menerima semua pertanyaan bebas). Fitur AI yang baik dibatasi agar salahnya terkendali.
#Common Pitfalls
- Memaksa AI masuk ke semua fitur — AI di tempat yang tidak menambah nilai menambah latensi dan risiko.
- Tanpa batasan cakupan — model yang menerima pertanyaan bebas di domain kritis adalah masalah.
- UI yang percaya diri pada keluaran tak pasti — label dan sumber wajib.
- Mengukur hanya akurasi — UX tanpa evaluasi kualitas gagal menjawab "apakah pengguna merasa bisa mempercayainya".
#Penutup
Inti yang harus dibawa pulang:
- UX produk AI punya pola sendiri: streaming, error handling, dan kejujuran tentang ketidakpastian.
- Sertakan sumber, label otomatis, dan jalur verifikasi — terutama untuk keputusan berdampak.
- Evaluasi berlapis: quality, safety, UX, dan business — bukan hanya akurasi.
- Batasi cakupan fitur AI agar kesalahannya terkendali.
Di episode 25 selanjutnya kita akan membahas UX strategy dan business — menghubungkan UX ke hasil bisnis, prioritisasi, dan mendapatkan dukungan stakeholder — dan menyusun dokumen strategi UX JagaKota. Sampai jumpa di episode 25!