2.3 Siapa yang Benar-Benar Memakai?

Setelah alasan perubahan jelas, kita perlu tahu siapa yang akan merasakan dampaknya—dan siapa yang sebenarnya menjadi pengguna solusi ini.

Bayangkan Anda bekerja di perusahaan logistik. Tim operasional mengeluh bahwa proses penjadwalan pengiriman terlalu lambat. Setelah ditelusuri, masalahnya bukan di aplikasi utama, tetapi di cara data pelanggan baru masuk dari sistem penjualan. Permintaan pun berubah: "Buatkan integrasi agar data pelanggan otomatis masuk ke sistem pengiriman."

Siapa penggunanya? Jawaban pertama yang terlintas mungkin staf operasional yang selama ini mengetik ulang data. Tapi tunggu. Ada juga admin penjualan yang akan berhenti menerima telepon konfirmasi. Ada kurir yang akan melihat alamat lebih cepat. Ada pelanggan yang tidak perlu lagi mengirim ulang data lewat WhatsApp. Ada juga sistem akuntansi yang butuh nomor resi untuk pencatatan biaya.

Inilah jebakan yang sering terjadi: kita hanya melihat pengguna sebagai orang yang mengklik tombol di layar. Padahal pengguna itu lebih luas.

Dalam praktiknya, aku membagi pengguna menjadi tiga kelompok. Pertama, pengguna utama: orang yang secara langsung berinteraksi dengan solusi yang kita bangun. Mereka yang mengisi form, melihat dashboard, atau menerima notifikasi. Dalam contoh integrasi tadi, pengguna utamanya adalah staf operasional yang akan melihat data pelanggan masuk otomatis.

Berikut diagram yang merangkum tiga kelompok pengguna dan contoh peran di dalamnya:

flowchart TD S[Solusi Integrasi Data Pelanggan] --> U[Pengguna Utama] S --> P[Pengguna Pendukung] S --> D[Pihak Terdampak] U --> U1[Staf Operasional] U --> U2[Admin Penjualan] P --> P1[Kurir] P --> P2[Admin Gudang] P --> P3[Tim Keuangan] D --> D1[Pelanggan] D --> D2[Sistem Akuntansi] D --> D3[Kompetitor]

Kedua, pengguna pendukung: mereka yang tidak menyentuh sistem secara langsung, tetapi pekerjaannya bergantung pada output yang dihasilkan. Kurir yang menerima alamat pengiriman, admin gudang yang menyiapkan barang berdasarkan jadwal, atau tim keuangan yang membutuhkan data biaya pengiriman. Mereka tidak akan membuka halaman konfigurasi integrasi, tetapi hidup mereka berubah ketika data mengalir lebih cepat.

Ketiga, pihak terdampak: orang atau sistem yang menerima konsekuensi dari solusi, baik positif maupun negatif. Pelanggan yang tidak perlu lagi mengirim ulang data adalah pihak terdampak. Sistem akuntansi yang harus menyesuaikan format data masuk juga pihak terdampak. Bahkan kompetitor yang kalah cepat karena layanan kita jadi lebih responsif—mereka juga terdampak, meskipun bukan urusan kita.

Mengapa pemetaan ini penting? Karena solusi yang baik jarang gagal karena teknologi. Ia gagal karena melupakan siapa yang benar-benar memakai. Fitur integrasi yang canggih tidak ada gunanya jika admin penjualan tidak pernah diberi tahu bahwa prosesnya berubah. Dashboard yang rapi tidak membantu jika kurir tidak punya akses ke ponsel kantor.

Di sinilah AI bisa membantu. Setelah kita memetakan kelompok pengguna, AI assistant bisa membantu merapikan daftar peran, menyarankan pihak yang mungkin terlewat, atau menyusun pertanyaan untuk wawancara. Tapi pemetaan awalnya tetap harus dilakukan oleh manusia yang memahami konteks organisasi. AI tidak tahu bahwa staf operasional di gudang malam hanya punya akses internet terbatas. AI tidak tahu bahwa admin penjualan sudah dua puluh tahun bekerja tanpa pernah menyentuh komputer.

Jadi, sebelum menggambar arsitektur atau memilih teknologi, ambil kertas dan tulis: siapa yang akan menyentuh solusi ini? Siapa yang akan bergantung padanya? Siapa yang akan merasakan dampaknya, suka atau tidak? Jawabannya akan menentukan bentuk solusi yang sebenarnya.

Setelah kita tahu siapa penggunanya, langkah berikutnya adalah memahami pekerjaan apa yang sebenarnya ingin mereka selesaikan—bukan fitur apa yang mereka minta.