Mendesain untuk agen otonom menghadirkan rasa frustrasi yang unik. Kami menyerahkan tugas kompleks kepada AI, ia menghilang selama 30 detik (atau 30 menit), dan kemudian kembali dengan hasilnya. Kami menatap layar. Apakah itu berhasil? Apakah itu berhalusinasi? Apakah mereka memeriksa database kepatuhan atau melewatkan langkah itu? Kita biasanya merespons kecemasan ini dengan salah satu dari dua ekstrem. Kita akan menjaga sistem tetap menjadi Black Box, menyembunyikan semuanya untuk menjaga kesederhanaan, atau kita panik dan menyediakan Data Dump, mengalirkan setiap baris log dan panggilan API ke pengguna. Tidak ada pendekatan yang secara langsung menjawab kebutuhan untuk memberikan tingkat transparansi yang ideal kepada pengguna. Kotak Hitam membuat pengguna merasa tidak berdaya. Data Dump menciptakan kebutaan notifikasi, sehingga merusak efisiensi yang dijanjikan agen. Pengguna mengabaikan arus informasi yang terus-menerus sampai ada yang rusak, dan pada saat itulah mereka tidak memiliki konteks untuk memperbaikinya. Kita membutuhkan cara yang terorganisir untuk menemukan keseimbangan. Dalam artikel saya sebelumnya, “Merancang Untuk Agentic AI”, kami melihat elemen antarmuka yang membangun kepercayaan, seperti menunjukkan tindakan yang dimaksudkan AI sebelumnya (Intent Previews) dan memberi pengguna kendali atas seberapa banyak yang dilakukan AI sendiri (Autonomy Dial). Namun mengetahui elemen mana yang akan digunakan hanyalah sebagian dari tantangannya. Pertanyaan tersulit bagi desainer adalah mengetahui kapan menggunakannya. Bagaimana Anda mengetahui momen tertentu dalam alur kerja 30 detik yang memerlukan Pratinjau Intent dan momen mana yang dapat ditangani dengan entri log sederhana? Artikel ini memberikan metode untuk menjawab pertanyaan itu. Kita akan menjalani Audit Node Keputusan. Proses ini menempatkan desainer dan insinyur di ruangan yang sama untuk memetakan logika backend ke antarmuka pengguna. Anda akan mempelajari cara menentukan saat yang tepat ketika pengguna memerlukan pembaruan tentang apa yang dilakukan AI. Kami juga akan membahas matriks Dampak/Risiko yang akan membantu memprioritaskan simpul keputusan mana yang akan ditampilkan dan pola desain terkait apa pun yang akan dipasangkan dengan keputusan tersebut. Momen Transparansi: Contoh Studi Kasus Misalnya Meridian (bukan nama sebenarnya), sebuah perusahaan asuransi yang menggunakan AI agen untuk memproses klaim kecelakaan awal. Pengguna mengunggah foto kerusakan kendaraan dan laporan polisi. Agen kemudian menghilang sebentar sebelum kembali dengan penilaian risiko dan kisaran pembayaran yang diusulkan. Awalnya, antarmuka Meridian hanya menunjukkan Menghitung Status Klaim. Pengguna menjadi frustrasi. Mereka telah menyerahkan beberapa dokumen rinci dan merasa tidak yakin apakah AI telah meninjau laporan polisi, yang berisi hal-hal yang meringankan. Kotak Hitam menciptakan ketidakpercayaan. Untuk mengatasinya, tim desain melakukan Audit Node Keputusan. Mereka menemukan bahwa AI melakukan tiga langkah berbeda, berdasarkan probabilitas, dengan beberapa langkah kecil yang tertanam:
Analisis GambarAgen tersebut membandingkan foto kerusakan dengan database skenario kecelakaan mobil pada umumnya untuk memperkirakan biaya perbaikan. Ini melibatkan skor kepercayaan diri. Tinjauan Tekstual Ini memindai laporan polisi untuk mencari kata kunci yang memengaruhi tanggung jawab (misalnya, kesalahan, kondisi cuaca, ketenangan hati). Hal ini melibatkan penilaian probabilitas kedudukan hukum. Referensi Silang Kebijakan Ini mencocokkan rincian klaim dengan ketentuan kebijakan spesifik pengguna, mencari pengecualian atau batas cakupan. Ini juga melibatkan pencocokan probabilistik.
Tim mengubah langkah-langkah ini menjadi momen transparansi. Urutan antarmuka telah diperbarui menjadi:
Menilai Foto Kerusakan: Membandingkan 500 profil dampak kendaraan. Meninjau Laporan Polisi: Menganalisis kata kunci pertanggungjawaban dan preseden hukum. Memverifikasi Cakupan Polis: Memeriksa pengecualian spesifik dalam paket Anda.
Sistem ini masih memerlukan waktu yang sama, namun komunikasi eksplisit tentang cara kerja internal agen memulihkan kepercayaan pengguna. Pengguna memahami bahwa AI sedang melakukan tugas kompleks yang dirancang untuknya, dan mereka tahu persis ke mana harus memusatkan perhatian jika penilaian akhir tampak tidak akurat. Pilihan desain ini mengubah momen kegelisahan menjadi momen keterhubungan dengan pengguna. Menerapkan Matriks Dampak/Risiko: Apa yang Kami Pilih untuk Disembunyikan Sebagian besar pengalaman AI tidak kekurangan peristiwa dan simpul keputusan yang berpotensi ditampilkan selama pemrosesan. Salah satu hasil paling penting dari audit ini adalah memutuskan hal-hal apa saja yang tidak boleh terlihat. Dalam contoh Meridian, log backend menghasilkan 50+ peristiwa per klaim. Kami bisa saja menampilkan setiap peristiwa secara default saat diproses sebagai bagian dari UI. Sebagai gantinya, kami menerapkan matriks risiko untuk memangkasnya:
Log Peristiwa: Server PingWest-2 untuk pemeriksaan redundansi. Filter Putusan: Sembunyikan. (Taruhan Rendah, Teknis Tinggi).
Log Event: Membandingkan perkiraan perbaikan dengan nilai BlueBook. Filter Putusan: Tampilkan. (Taruhan Tinggi, berdampak pada pembayaran pengguna).
Dengan menghilangkan detail yang tidak diperlukan, informasi penting – seperti verifikasi cakupan – akan lebih berdampak. Kami menciptakan antarmuka terbuka dan merancang pengalaman terbuka. Pendekatan ini menggunakan gagasan bahwa orang merasa lebih baik terhadap suatu layanan ketika mereka dapat melihat pekerjaan yang dilakukan. Dengan menunjukkan langkah-langkah spesifik (Menilai, Meninjau, Memverifikasi), kami mengubah waktu tunggu selama 30 detik dari saat khawatir (“Apakah rusak?”) menjadi saat merasa seperti sesuatu yang berharga sedang diciptakan (“Sedang berpikir”). Sekarang mari kita melihat lebih dekat bagaimana kita dapat meninjau proses pengambilan keputusan dalam produk kita untuk mengidentifikasi momen-momen penting yang memerlukan informasi yang jelas. Audit Node Keputusan Transparansi gagal jika kita memperlakukannya sebagai pilihan gaya dan bukan sebagai persyaratan fungsional. Kita cenderung bertanya, “Seperti apa tampilan UI-nya?” sebelum kita bertanya, “Apa yang sebenarnya diputuskan oleh agen?” Audit Node Keputusan adalah cara langsung untuk membuat sistem AI lebih mudah dipahami. Ia bekerja dengan memetakan proses internal sistem secara cermat. Tujuan utamanya adalah untuk menemukan dan mendefinisikan dengan jelas momen yang tepat ketika sistem berhenti mengikuti aturan yang ditetapkan dan malah membuat pilihan berdasarkan peluang atau perkiraan. Dengan memetakan struktur ini, pembuat konten dapat menunjukkan titik-titik ketidakpastian tersebut secara langsung kepada pengguna sistem. Hal ini mengubah pembaruan sistem dari pernyataan yang tidak jelas menjadi laporan yang spesifik dan dapat diandalkan tentang bagaimana AI mencapai kesimpulannya. Selain studi kasus asuransi di atas, saya baru-baru ini bekerja dengan tim yang membangun agen pengadaan. Sistem meninjau kontrak vendor dan menandai risiko. Awalnya, layar menampilkan bilah kemajuan sederhana: “Meninjau kontrak.” Pengguna membencinya. Penelitian kami menunjukkan bahwa mereka merasa cemas mengenai implikasi hukum dari hilangnya klausul tersebut. Kami memperbaikinya dengan melakukan Audit Node Keputusan. Saya telah menyertakan daftar langkah demi langkah untuk melakukan audit ini di akhir artikel ini. Kami mengadakan sesi dengan para insinyur dan menguraikan cara kerja sistem. Kami mengidentifikasi “Titik Keputusan” — momen di mana AI harus memilih di antara dua opsi yang baik. Dalam program komputer standar, prosesnya jelas: jika A terjadi, maka B akan selalu terjadi. Dalam sistem AI, prosesnya sering kali didasarkan pada kebetulan. AI menganggap A mungkin adalah pilihan terbaik, tapi mungkin hanya 65% yang yakin. Dalam sistem kontrak, kami menemukan momen ketika AI memeriksa ketentuan tanggung jawab terhadap peraturan perusahaan kami. Jarang sekali ada pertandingan yang sempurna. AI harus memutuskan apakah kecocokan 90% sudah cukup baik. Ini adalah poin keputusan penting.
Setelah kami mengidentifikasi node ini, kami memaparkannya kepada pengguna. Alih-alih “Meninjau kontrak”, antarmuka diperbarui menjadi: “Klausul kewajiban bervariasi dari templat standar. Menganalisis tingkat risiko.” Pembaruan khusus ini memberikan kepercayaan diri kepada pengguna. Mereka tahu agen tersebut telah memeriksa klausul pertanggungjawaban. Mereka memahami alasan penundaan dan mendapatkan kepercayaan bahwa tindakan yang diinginkan terjadi di bagian belakang. Mereka juga tahu di mana harus menggali lebih dalam setelah agen membuat kontrak. Untuk memeriksa bagaimana AI mengambil keputusan, Anda perlu bekerja sama dengan teknisi, manajer produk, analis bisnis, dan orang-orang penting yang membuat pilihan (sering kali tersembunyi) yang memengaruhi cara kerja alat AI. Gambarkan langkah-langkah yang diambil alat tersebut. Tandai setiap tempat dimana proses berubah arah karena probabilitas terpenuhi. Di sinilah Anda harus fokus untuk menjadi lebih transparan. Seperti yang ditunjukkan pada Gambar 2 di bawah, Audit Node Keputusan melibatkan langkah-langkah berikut:
Kumpulkan tim: Gabungkan pemilik produk, analis bisnis, desainer, pengambil keputusan utama, dan insinyur yang membangun AI. Misalnya, Bayangkan tim produk yang membuat alat AI yang dirancang untuk meninjau kontrak hukum yang berantakan. Tim tersebut terdiri dari desainer UX, manajer produk, peneliti UX, seorang pengacara yang bertindak sebagai ahli materi pelajaran, dan insinyur backend yang menulis kode analisis teks.
Gambarkan seluruh proses: Dokumentasikan setiap langkah yang diambil AI, mulai dari tindakan pertama pengguna hingga hasil akhir. Tim berdiri di papan tulis dan membuat sketsa seluruh urutan alur kerja utama yang melibatkan AI mencari klausul tanggung jawab dalam kontrak yang kompleks. Pengacara mengunggahPDF lima puluh halaman → Sistem mengubah dokumen menjadi teks yang dapat dibaca. → AI memindai halaman untuk mencari klausul pertanggungjawaban. → Pengguna menunggu. → Beberapa saat atau beberapa menit kemudian, alat tersebut menyorot paragraf yang ditemukan dengan warna kuning pada antarmuka pengguna. Mereka melakukan ini untuk banyak alur kerja lain yang juga diakomodasi oleh alat tersebut.
Temukan hal-hal yang tidak jelas: Lihat peta proses untuk menemukan tempat di mana AI membandingkan opsi atau masukan yang tidak memiliki satu kecocokan sempurna. Tim melihat ke papan tulis untuk melihat langkah-langkah yang ambigu. Mengonversi gambar menjadi teks mengikuti aturan ketat. Menemukan klausul tanggung jawab tertentu melibatkan dugaan. Setiap perusahaan menulis klausul ini secara berbeda, sehingga AI harus mempertimbangkan berbagai pilihan dan membuat prediksi alih-alih menemukan kata yang sama persis.
Identifikasi langkah-langkah 'tebakan terbaik': Untuk setiap titik yang tidak jelas, periksa apakah sistem menggunakan skor keyakinan (misalnya, apakah sistem yakin 85%?). Ini adalah titik di mana AI membuat pilihan akhir. Sistem harus menebak (memberikan probabilitas) paragraf mana yang paling mirip dengan klausul tanggung jawab standar. Ini memberikan skor kepercayaan pada tebakan terbaiknya. Tebakan itu adalah simpul keputusan. Antarmuka perlu memberi tahu pengacara bahwa ia menyoroti potensi kecocokan, bukan menyatakan bahwa ia menemukan klausul definitif.
Periksa pilihannya: Untuk setiap titik pilihan, cari tahu perhitungan internal spesifik atau perbandingan yang dilakukan (misalnya, mencocokkan bagian kontrak dengan polis atau membandingkan gambar mobil rusak dengan perpustakaan foto mobil rusak). Insinyur menjelaskan bahwa sistem membandingkan berbagai paragraf dengan database klausul tanggung jawab standar dari kasus perusahaan masa lalu. Ini menghitung skor kesamaan teks untuk memutuskan kecocokan berdasarkan probabilitas.
Tulis penjelasan yang jelas: Buat pesan untuk pengguna yang menjelaskan dengan jelas tindakan internal spesifik yang terjadi saat AI membuat pilihan. Perancang konten menulis pesan khusus untuk momen ini. Teksnya berbunyi: Membandingkan teks dokumen dengan klausul perusahaan standar untuk mengidentifikasi potensi risiko tanggung jawab.
Perbarui layar: Masukkan penjelasan baru dan jelas ini ke dalam antarmuka pengguna, gantikan pesan yang tidak jelas seperti “Meninjau kontrak.” Tim desain menghapus pemintal pemuatan PDF Pemrosesan generik. Mereka memasukkan penjelasan baru ke dalam bilah status yang terletak tepat di atas penampil dokumen sementara AI berpikir.
Periksa Kepercayaan: Pastikan pesan layar baru memberikan alasan sederhana kepada pengguna tentang waktu tunggu atau hasil, yang akan membuat mereka merasa lebih percaya diri dan percaya.
Matriks Dampak/Risiko Setelah Anda mencermati proses AI, kemungkinan besar Anda akan menemukan banyak titik di mana AI membuat pilihan. AI mungkin membuat lusinan pilihan kecil untuk satu tugas kompleks. Menampilkan semuanya akan menghasilkan terlalu banyak informasi yang tidak perlu. Anda perlu mengelompokkan pilihan-pilihan ini. Anda dapat menggunakan Matriks Dampak/Risiko untuk mengurutkan pilihan ini berdasarkan jenis tindakan yang diambil AI. Berikut adalah contoh matriks dampak/risiko: Pertama, carilah keputusan yang berisiko rendah dan berdampak rendah. Taruhan Rendah / Dampak Rendah
Contoh: Mengatur struktur file atau mengganti nama dokumen. Kebutuhan Transparansi: Minimal. Notifikasi roti panggang yang halus atau entri log sudah cukup. Pengguna dapat membatalkan tindakan ini dengan mudah.
Kemudian identifikasi keputusan-keputusan yang berisiko tinggi dan berdampak besar. Taruhan Tinggi / Dampak Tinggi
Contoh: Menolak permohonan pinjaman atau melakukan perdagangan saham. Kebutuhan Transparansi: Tinggi. Tindakan ini memerlukan Bukti Kerja. Sistem harus menunjukkan alasan yang masuk akal sebelum atau segera setelah bertindak.
Pertimbangkan bot perdagangan keuangan yang memperlakukan semua pesanan beli/jual dengan cara yang sama. Ini mengeksekusi perdagangan $5 dengan opacity yang sama dengan perdagangan $50,000. Pengguna mungkin mempertanyakan apakah alat tersebut mengenali potensi dampak transparansi pada perdagangan dalam jumlah besar. Mereka membutuhkan sistem untuk berhenti sejenak dan menunjukkan kinerjanya dalam perdagangan berisiko tinggi. Solusinya adalah dengan memperkenalkan status Logika Peninjauan untuk setiap transaksi yang melebihi jumlah dolar tertentu, sehingga memungkinkan pengguna melihat faktor-faktor yang mendorong keputusan sebelum dieksekusi. Memetakan Node ke Pola: Rubrik Pemilihan Pola Desain Setelah Anda mengidentifikasi simpul keputusan utama pengalaman Anda, Anda harus memutuskan pola UI mana yang berlaku untuk setiap simpul keputusan yang akan Anda tampilkan. Dalam Mendesain Untuk AI Agentik, kami memperkenalkan pola seperti Pratinjau Intent (untuk kontrol berisiko tinggi) dan Audit Tindakan (untuk keamanan retrospektif). Faktor penentu dalam memilih di antara keduanya adalah reversibilitas. Kami memfilter setiapsimpul keputusan melalui matriks dampak untuk menetapkan pola yang benar: Taruhan Tinggi & Tidak Dapat Dibalikkan: Node ini memerlukan Pratinjau Intent. Karena pengguna tidak dapat dengan mudah membatalkan tindakan (misalnya menghapus database secara permanen), momen transparansi harus terjadi sebelum eksekusi. Sistem harus berhenti sejenak, menjelaskan maksudnya, dan memerlukan konfirmasi. Taruhan Tinggi & Dapat Dibalik: Node ini dapat mengandalkan pola Audit Tindakan & Pembatalan. Jika agen penjualan yang didukung AI memindahkan prospek ke jalur lain, agen tersebut dapat melakukannya secara mandiri selama agen tersebut memberi tahu pengguna dan menawarkan tombol Urungkan secara langsung. Dengan mengkategorikan node secara ketat seperti ini, kita menghindari “kelelahan akibat kewaspadaan”. Kami mencadangkan Pratinjau Intent yang sangat rumit hanya untuk momen-momen yang benar-benar tidak dapat diubah, sambil mengandalkan Audit Tindakan untuk menjaga kecepatan pada momen-momen lainnya.
Reversibel Tidak dapat diubah Dampak Rendah Ketik: Auto-ExecuteUI: Passive Toast / LogEx: Mengganti nama file Ketik: Konfirmasi UI: Opsi Undo Sederhana Contoh: Pengarsipan email Dampak Tinggi Ketik: ReviewUI: Notifikasi + Review TrailEx: Mengirim draf ke klien Ketik: Pratinjau maksudUI: Modal / Izin EksplisitEx: Menghapus server
Tabel 1: Matriks dampak dan reversibilitas kemudian dapat digunakan untuk memetakan momen transparansi Anda hingga pola desain. Validasi Kualitatif: “Penantian, Mengapa?” Tes Anda dapat mengidentifikasi node potensial di papan tulis, namun Anda harus memvalidasinya dengan perilaku manusia. Anda perlu memverifikasi apakah peta Anda cocok dengan model mental pengguna. Saya menggunakan protokol yang disebut “Tunggu, Mengapa?” Tes. Minta pengguna untuk melihat agen menyelesaikan tugas. Perintahkan mereka untuk berbicara dengan suara keras. Setiap kali mereka mengajukan pertanyaan, “Tunggu, mengapa ia melakukan itu?” atau “Apakah macet?” atau “Apakah dia mendengarku?” — Anda menandai stempel waktu. Pertanyaan-pertanyaan ini menandakan kebingungan pengguna. Pengguna merasa kendalinya hilang. Misalnya, dalam studi untuk asisten penjadwalan layanan kesehatan, pengguna melihat agen membuat janji temu. Layarnya diam selama empat detik. Peserta secara konsisten bertanya, “Apakah memeriksa kalender saya atau dokter?”
Pertanyaan tersebut mengungkapkan Momen Transparansi yang hilang. Sistem perlu membagi waktu tunggu empat detik tersebut menjadi dua langkah berbeda: “Memeriksa ketersediaan Anda” diikuti dengan “Sinkronisasi dengan jadwal penyedia”. Perubahan kecil ini mengurangi tingkat kecemasan pengguna. Transparansi gagal jika hanya menjelaskan tindakan sistem. Antarmuka harus menghubungkan proses teknis dengan tujuan spesifik pengguna. Layar yang menampilkan “Memeriksa ketersediaan Anda” menjadi datar karena tidak memiliki konteks. Pengguna memahami bahwa AI sedang melihat kalender, namun mereka tidak mengetahui alasannya. Kita harus memadukan tindakan dengan hasilnya. Sistem perlu membagi waktu tunggu empat detik tersebut menjadi dua langkah berbeda. Pertama, antarmuka menampilkan “Memeriksa kalender Anda untuk menemukan jam buka.” Kemudian diperbarui menjadi “Sinkronisasi dengan jadwal penyedia untuk mengamankan janji temu Anda.” Hal ini mendasari proses teknis dalam kehidupan nyata pengguna. Pertimbangkan AI yang mengelola inventaris untuk kafe lokal. Sistem mengalami kekurangan pasokan. Antarmuka yang bertuliskan "menghubungi vendor" atau "meninjau opsi" menimbulkan kecemasan. Manajer bertanya-tanya apakah sistem membatalkan pesanan atau membeli alternatif yang mahal. Pendekatan yang lebih baik adalah dengan menjelaskan hasil yang diharapkan: “Mengevaluasi pemasok alternatif untuk mempertahankan jadwal pengiriman hari Jumat Anda.” Ini memberi tahu pengguna apa yang sebenarnya ingin dicapai oleh AI. Mengoperasionalkan Audit Anda telah menyelesaikan Audit Node Keputusan dan memfilter daftar Anda melalui Matriks Dampak dan Risiko. Anda sekarang memiliki daftar momen penting untuk bersikap transparan. Selanjutnya, Anda perlu membuatnya di UI. Langkah ini memerlukan kerja tim antar departemen yang berbeda. Anda tidak dapat mendesain transparansi sendiri menggunakan alat desain. Anda perlu memahami cara kerja sistem di balik layar. Mulailah dengan Tinjauan Logika. Temui perancang sistem utama Anda. Bawalah peta simpul keputusan Anda. Anda perlu mengonfirmasi bahwa sistem benar-benar dapat membagikan status ini. Saya sering menemukan bahwa sistem teknis tidak mengungkapkan keadaan persis yang ingin saya tunjukkan. Insinyur mungkin mengatakan bahwa sistem hanya mengembalikan status “berfungsi” secara umum. Anda harus mendorong pembaruan mendetail. Anda memerlukan sistem untuk mengirimkan pemberitahuan khususketika beralih dari membaca teks ke memeriksa aturan. Tanpa koneksi teknis tersebut, desain Anda tidak mungkin dibuat. Selanjutnya, libatkan tim Desain Konten. Anda memiliki alasan teknis atas tindakan AI tersebut, namun Anda memerlukan penjelasan yang jelas dan ramah manusia. Insinyur menyediakan proses yang mendasarinya, namun desainer konten menyediakan cara komunikasinya. Jangan menulis pesan-pesan ini sendirian. Pengembang mungkin menulis "Mengeksekusi fungsi 402", yang secara teknis benar tetapi tidak berarti bagi pengguna. Seorang desainer mungkin menulis “Berpikir”, yang ramah tetapi terlalu kabur. Seorang ahli strategi konten menemukan jalan tengah yang tepat. Mereka membuat frasa spesifik, seperti “Memindai risiko pertanggungjawaban”, yang menunjukkan bahwa AI bekerja tanpa membingungkan pengguna. Terakhir, uji transparansi pesan Anda. Jangan menunggu sampai produk akhir dibuat untuk melihat apakah teksnya berfungsi. Saya melakukan tes perbandingan pada prototipe sederhana di mana satu-satunya hal yang berubah adalah pesan status. Misalnya, saya menunjukkan kepada satu kelompok (Grup A) sebuah pesan yang mengatakan “Memverifikasi identitas” dan kelompok lain (Grup B) sebuah pesan yang mengatakan “Memeriksa database pemerintah” (ini adalah contoh yang dibuat-buat, tetapi Anda memahami maksudnya). Lalu saya bertanya kepada mereka AI mana yang dirasa lebih aman. Anda akan sering menemukan bahwa kata-kata tertentu menimbulkan kekhawatiran, sementara kata-kata lain membangun kepercayaan. Anda harus memperlakukan kata-katanya sebagai sesuatu yang perlu Anda uji dan buktikan efektif. Bagaimana Ini Mengubah Proses Desain Melaksanakan audit ini berpotensi memperkuat cara kerja tim. Kami berhenti menyerahkan file desain yang telah dipoles. Kami mulai menggunakan prototipe yang berantakan dan spreadsheet bersama. Alat inti menjadi matriks transparansi. Insinyur dan desainer konten mengedit spreadsheet ini bersama-sama. Mereka memetakan kode teknis yang tepat ke kata-kata yang akan dibaca pengguna. Tim akan mengalami gesekan selama peninjauan logika. Bayangkan seorang desainer bertanya kepada insinyur bagaimana AI memutuskan untuk menolak transaksi yang dikirimkan pada laporan pengeluaran. Insinyur mungkin mengatakan bahwa backend hanya mengeluarkan kode status umum seperti “Kesalahan: Data Hilang”. Perancang menyatakan bahwa ini bukanlah informasi yang dapat ditindaklanjuti di layar. Perancang bernegosiasi dengan insinyur untuk membuat kaitan teknis tertentu. Insinyur menulis aturan baru sehingga sistem melaporkan dengan tepat apa yang hilang, misalnya gambar tanda terima yang hilang. Desainer konten bertindak sebagai penerjemah selama fase ini. Pengembang mungkin menulis string yang akurat secara teknis seperti “Menghitung ambang batas keyakinan untuk pencocokan vendor”. Seorang desainer konten menerjemahkan string tersebut menjadi frasa yang membangun kepercayaan untuk hasil tertentu. Ahli strategi menuliskannya ulang sebagai “Membandingkan harga vendor lokal untuk mengamankan pengiriman hari Jumat Anda.” Pengguna memahami tindakan dan hasilnya. Seluruh tim lintas fungsi mengikuti sesi pengujian pengguna. Mereka menyaksikan orang sungguhan bereaksi terhadap pesan status yang berbeda. Melihat pengguna panik karena layar bertuliskan “Eksekusi perdagangan” memaksa tim untuk memikirkan kembali pendekatan mereka. Para insinyur dan desainer menyelaraskan kata-kata yang lebih baik. Mereka mengubah teks menjadi “Memverifikasi dana yang cukup” sebelum membeli saham. Pengujian bersama menjamin antarmuka akhir menyajikan logika sistem dan ketenangan pikiran pengguna. Memang diperlukan waktu untuk memasukkan aktivitas tambahan ini ke dalam kalender tim. Namun, hasil akhirnya adalah tim yang berkomunikasi lebih terbuka, dan pengguna yang memiliki pemahaman lebih baik tentang apa yang dilakukan alat bertenaga AI atas nama mereka (dan alasannya). Pendekatan terpadu ini merupakan landasan dalam merancang pengalaman AI yang benar-benar dapat dipercaya. Kepercayaan Adalah Pilihan Desain Kami sering memandang kepercayaan sebagai produk sampingan emosional dari pengalaman pengguna yang baik. Lebih mudah untuk memandang kepercayaan sebagai hasil mekanis dari komunikasi yang dapat diprediksi. Kami membangun kepercayaan dengan menampilkan informasi yang tepat pada waktu yang tepat. Kami menghancurkannya dengan membuat pengguna kewalahan atau menyembunyikan mesin sepenuhnya. Mulailah dengan Audit Node Keputusan, khususnya untuk alat dan produk AI agen. Temukan momen ketika sistem mengambil keputusan. Petakan momen-momen tersebut ke Matriks Risiko. Jika taruhannya tinggi, buka kotaknya. Tunjukkan karyanya. Pada artikel berikutnya, kita akan melihat cara merancang momen-momen ini: cara menulis salinan, menyusun UI, dan menangani kesalahan yang tidak dapat dihindari ketika agen melakukan kesalahan. Lampiran: Daftar Periksa Audit Node Keputusan Fase 1: Penyiapan dan Pemetaan ✅ Kumpulkan tim: Ajak pemilik produk, analis bisnis, desainer,pengambil keputusan utama, dan para insinyur yang membangun AI. Petunjuk: Anda memerlukan teknisi untuk menjelaskan logika backend sebenarnya. Jangan mencoba langkah ini sendirian. ✅ Gambarkan seluruh proses: Dokumentasikan setiap langkah yang diambil AI, mulai dari tindakan pertama pengguna hingga hasil akhir. Petunjuk: Sesi papan tulis fisik sering kali berfungsi paling baik untuk menggambarkan langkah-langkah awal ini. Fase 2: Menemukan Logika Tersembunyi ✅ Temukan hal-hal yang tidak jelas: Lihat peta proses untuk menemukan tempat di mana AI membandingkan opsi atau masukan yang tidak memiliki satu kecocokan sempurna. ✅ Identifikasi langkah tebakan terbaik: Untuk setiap titik yang tidak jelas, periksa apakah sistem menggunakan skor kepercayaan. Misalnya, tanyakan apakah sistemnya 85 persen yakin. Ini adalah titik di mana AI membuat pilihan akhir. ✅ Periksa pilihannya: Untuk setiap titik pilihan, cari tahu matematika internal spesifik atau perbandingan yang sedang dilakukan. Contohnya adalah mencocokkan bagian kontrak dengan kebijakan. Contoh lainnya adalah membandingkan gambar mobil rusak dengan perpustakaan foto mobil rusak. Fase 3: Menciptakan Pengalaman Pengguna ✅ Tulis penjelasan yang jelas: Buat pesan untuk pengguna yang menjelaskan dengan jelas tindakan internal spesifik yang terjadi saat AI membuat pilihan. Petunjuk: Dasarkan pesan Anda pada realitas nyata. Jika AI memesan pertemuan dengan klien di kafe lokal, beri tahu pengguna bahwa sistem sedang memeriksa sistem reservasi kafe. ✅ Perbarui layar: Masukkan penjelasan baru dan jelas ini ke dalam antarmuka pengguna. Ganti pesan yang tidak jelas seperti Meninjau kontrak dengan penjelasan spesifik Anda. ✅ Periksa Kepercayaan: Pastikan pesan layar baru memberikan alasan sederhana kepada pengguna untuk waktu tunggu atau hasil apa pun. Hal ini seharusnya membuat mereka merasa percaya diri dan percaya. Petunjuk: Uji pesan-pesan ini dengan pengguna sebenarnya untuk memverifikasi bahwa mereka memahami hasil spesifik yang dicapai.
