Sebelum Membuat Dashboard, Rapikan Alur Datanya

Dashboard sering menjadi bagian pertama yang dibicarakan saat sebuah aplikasi mulai direncanakan. Orang ingin melihat jumlah transaksi, pekerjaan yang belum selesai, stok yang menipis, atau grafik aktivitas per bulan. Semua itu masuk akal. Masalahnya, tampilan yang rapi tidak dapat memperbaiki data yang sejak awal dicatat dengan cara yang salah.

Di beberapa proyek yang saya kerjakan, bagian tersulit justru terjadi sebelum angka sampai ke dashboard. Ada data yang dicatat oleh satu peran lalu diperiksa oleh peran lain. Ada dokumen yang belum boleh dilihat sebelum disetujui. Ada transaksi yang mengubah stok. Ada pula event dari perangkat yang masih harus ditinjau petugas. Jika urutan ini tidak jelas, dashboard hanya menampilkan kebingungan dalam bentuk yang lebih menarik.

Mulai dari keputusan yang perlu dibuat

Sebelum menentukan kartu statistik atau jenis grafik, saya mencari tahu keputusan apa yang akan dibuat dari halaman tersebut. Pertanyaannya sederhana: setelah melihat dashboard, pengguna perlu melakukan apa?

• Apakah admin perlu memeriksa pembayaran yang baru masuk?
• Apakah petugas perlu menindaklanjuti jadwal kontrol yang terlewat?
• Apakah ada stok yang harus segera diisi ulang?
• Apakah pimpinan perlu membandingkan aktivitas pada periode tertentu?

Jawaban atas pertanyaan itu menentukan data yang layak ditampilkan. Jumlah total sepanjang waktu mungkin terlihat meyakinkan, tetapi belum tentu membantu pekerjaan hari ini. Sebaliknya, daftar lima pekerjaan yang tertunda sering kali jauh lebih berguna karena dapat langsung ditindaklanjuti.

Tentukan siapa yang mencatat dan siapa yang memeriksa

Data operasional jarang berhenti pada orang yang pertama kali memasukkannya. Bukti pembayaran diunggah pelanggan, lalu diverifikasi admin. Dokumen kesehatan dicatat petugas, tetapi akses orang tua atau pengasuh tetap dibatasi. Event pembukaan kotak P3K dikirim perangkat, kemudian petugas memeriksa bukti visual dan mencatat item yang berkurang.

Karena itu, setiap data penting perlu memiliki penanggung jawab yang jelas. Saya biasanya menuliskan tiga hal: siapa yang membuat, siapa yang boleh mengubah, dan siapa yang hanya boleh melihat. Pembagian sederhana ini membantu menyusun hak akses sekaligus mencegah data berubah tanpa jalur yang dapat ditelusuri.

Status harus punya arti yang spesifik

Kata seperti pending sering dipakai untuk terlalu banyak keadaan. Padahal, “menunggu bukti”, “menunggu pemeriksaan”, dan “sudah diperiksa tetapi perlu diperbaiki” membutuhkan tindakan yang berbeda. Jika semuanya memakai status yang sama, pengguna harus membuka setiap catatan untuk mengetahui apa yang sebenarnya terjadi.

Status yang baik menjelaskan posisi data di dalam proses. Setiap perubahan juga sebaiknya mencatat waktu dan, jika relevan, pengguna yang melakukannya. Dengan begitu, angka “7 perlu diperiksa” di dashboard mempunyai sumber yang jelas dan dapat dibuka sampai ke catatan asalnya.

Hubungkan tahap proses, jangan menyalin data

Salah satu sumber masalah yang umum adalah informasi yang sama disalin ke banyak tempat. Data booking disalin lagi ke work order. Identitas pengguna ditulis ulang pada transaksi. Nilai stok disimpan terpisah tanpa riwayat perubahan. Cara ini mungkin cepat pada awal pengerjaan, tetapi koreksi pada satu tempat mudah meninggalkan data lama di tempat lain.

Saya lebih memilih menyimpan hubungan antarcatatan. Work order merujuk ke booking yang membuatnya. Transaksi stok merujuk ke kegiatan atau permohonan terkait. Catatan kunjungan tetap terhubung dengan profil anak yang sama. Bila sebuah nilai perlu diringkas untuk performa, sumber perhitungannya tetap harus bisa dijelaskan.

Untuk proses yang dapat terkirim lebih dari sekali, seperti permintaan dari aplikasi mobile atau perangkat, saya juga memeriksa kebutuhan idempotensi. Tujuannya sederhana: pengiriman ulang tidak boleh membuat transaksi atau perubahan stok tercatat dua kali.

Pisahkan bukti rinci dari informasi ringkas

Foto lapangan, dokumen kesehatan, bukti pembayaran, dan rekaman perangkat memang penting, tetapi semuanya tidak perlu muncul di dashboard. Halaman ringkasan cukup menunjukkan bahwa bukti tersedia, status pemeriksaannya, dan siapa yang perlu menindaklanjuti. File aslinya tetap disimpan pada area yang hak aksesnya sesuai.

Pemisahan ini membuat dashboard lebih mudah dibaca dan mengurangi risiko informasi sensitif tampil kepada pengguna yang tidak berwenang. Pengguna dapat bergerak dari ringkasan ke detail ketika memang membutuhkannya, bukan menerima semua informasi sekaligus.

Baru pilih angka dan grafik

Setelah alur, status, dan tanggung jawabnya stabil, pilihan visual biasanya menjadi lebih mudah. Angka pada dashboard dapat dibagi menjadi dua kelompok: hal yang perlu tindakan sekarang dan ringkasan untuk membaca pola.

Kelompok pertama bisa berupa pembayaran yang menunggu verifikasi, stok kritis, jadwal yang terlewat, atau event perangkat yang belum ditinjau. Kelompok kedua bisa berupa tren transaksi, jumlah layanan per periode, atau sebaran kejadian pada peta. Keduanya berguna, tetapi tidak harus mendapat porsi tampilan yang sama.

Checklist sebelum menggambar dashboard

1. Tulis keputusan atau tindakan yang harus didukung dashboard.
2. Catat sumber setiap angka dan siapa yang bertanggung jawab atas datanya.
3. Bedakan status yang membutuhkan tindakan berbeda.
4. Pastikan catatan antarproses saling terhubung dan tidak disalin tanpa alasan.
5. Tentukan informasi yang boleh diringkas dan bukti yang harus tetap privat.
6. Uji apakah pengguna dapat membuka angka ringkasan sampai ke data asalnya.

Saya biasanya baru menggambar dashboard setelah enam pertanyaan tersebut mempunyai jawaban yang cukup jelas. Hasilnya mungkin tidak langsung penuh dengan grafik, tetapi setiap elemen mempunyai alasan untuk berada di sana. Bagi aplikasi operasional, itu jauh lebih penting daripada sekadar membuat halaman pertama terlihat sibuk.