Desain Dasbor yang Mendorong Keputusan, Bukan Sekadar Tampilan

Selasa, pukul 21.47. Notifikasi Slack masuk. "Hei, laporan ini salah, MRR kita menunjukkan 4,1M tapi Finance bilang 4,3M, bisa kamu cek?"

Anda membuka dasbor itu. Anda tidak menyentuhnya selama tujuh bulan. Kolom pemilik tertulis "Sarah K" dan Sarah sudah keluar pada Oktober. Ada 14 grafik. Tiga di antaranya mengaku menampilkan MRR dan ketiganya tidak sepakat. Pemirsa terakhir adalah tiga minggu lalu, dan itu adalah Anda sendiri, membuka dasbor ini untuk berbagi tautannya di thread yang sama ini.

Notifikasi itu bukan masalah kualitas data. Itu adalah masalah desain. Kemungkinan besar masalah desain Anda sendiri, dari bangunan yang Anda kirimkan selama sprint yang sudah Anda lupakan.

Sebagian besar BI tool secara diam-diam melaporkan angka yang sama: antara 60 hingga 80 persen dasbor dibuka kurang dari lima kali sepanjang masa pakainya. Data penggunaan Looker sendiri, log admin Tableau Server, analitik tingkat adopsi Hex: bentuknya sama setiap kali. Kuburannya lebih besar dari lantai yang aktif. Dan setiap dasbor yang mati masih merugikan Anda: biaya kueri gudang data pada pembaruan terjadwal, erosi kepercayaan ketika pemangku kepentingan menemukan angka yang bertentangan, dan kalender Anda ketika seseorang membangkitkannya pukul 21.47.

Playbook ini adalah disiplin desain yang membuat jumlah dasbor Anda tetap sama atau berkurang sementara kepercayaan pemangku kepentingan terus bertumbuh. Ini adalah keahlian IC sejati, bukan sandiwara vendor BI.

Prinsip-prinsip yang membunuh dapur campur aduk

Sebelum aturan spesifik apa pun, ada tiga prinsip. Jika Anda menginternalisasi ini, sisanya akan mengikuti dengan sendirinya.

Satu keputusan per dasbor. Tulis keputusan itu di judul. Bukan "Ikhtisar Penjualan." Itu adalah topik, bukan keputusan. Tulis "Haruskah kita merevisi prakiraan penjualan Q3?" atau "Pipeline AE mana yang membutuhkan tinjauan manajer minggu ini?" Jika Anda tidak bisa menulis keputusan itu dalam satu kalimat, Anda tidak tahu untuk apa dasbor itu, dan orang yang membukanya pun tidak akan tahu. Topik berkembang biak. Keputusan tidak.

Hierarki visual, bukan demokrasi visual. Angka utama di dasbor harus setidaknya 3x lebih besar dari hal lain yang ada di halaman. Studi pelacakan mata pada BI tool (Tableau Research, 2023) menunjukkan pengguna menghabiskan 60% dari 8 detik pertama mereka pada tile terbesar. Jika semuanya berukuran sama, Anda memberitahu pengguna bahwa tidak ada yang penting. Pilih satu angka yang menjawab keputusan itu. Buat besar. Selebihnya adalah bukti pendukung.

Disiplin warna. Satu warna aksen untuk merek atau metrik utama. Abu-abu untuk segalanya. Merah dan hijau hanya untuk selisih terhadap target, tidak pernah untuk seri kategorikal. Jika grafik "Pendapatan berdasarkan Wilayah" Anda memiliki batang merah, hijau, biru, kuning, dan oranye, Anda telah melatih pengguna bahwa merah tidak berarti apa-apa. Kemudian ketika merah benar-benar berarti "kita melewatkan rencana," itu tidak berdampak. Warna adalah anggaran yang terbatas. Kebanyakan analyst menghabiskannya di grafik pertama.

Ketiga hal ini adalah fondasi. Selebihnya adalah penerapan.

Aturan 5 metrik

Tidak ada dasbor yang dikirimkan dengan lebih dari 5 metrik utama. Titik.

Ini adalah aturan yang selalu ditentang semua orang dan semua orang salah untuk menentangnya. Argumennya selalu sama: "tapi VP ingin melihat X, dan Y, dan juga Z." Baik. Bangunlah di suatu tempat. Hanya tidak di permukaan yang sama dengan keputusan tersebut.

Mengapa 5? Penelitian beban kognitif (Miller, 1956, ya, penelitian "angka ajaib tujuh", yang diperbarui oleh Cowan pada 2001 menjadi kapasitas memori kerja 4±1) adalah batasnya. Dalam sebuah pertemuan, dengan seseorang yang mempresentasikan, dengan Slack yang berbunyi, batas praktisnya bahkan lebih rendah. Dasbor dengan 14 tile tidak dibaca. Ia dipindai. Pengguna memilih dua yang terlihat mengejutkan dan mengabaikan sisanya. Anda mengerjakan 12 tile untuk mendapat perhatian pada 2 tile.

Aturan yang diterapkan:

• Jika Anda memiliki 5 metrik utama dan seseorang meminta metrik ke-6, Anda membangun dua dasbor. Satu melayani Keputusan A, yang lain melayani Keputusan B. Pisahkan.
• Jika Anda tidak bisa memutuskan mana 5 yang dipilih, Anda belum memutuskan keputusan mana yang dilayani dasbor itu. Kembali ke langkah pertama.
• Perincian data bukan metrik. Angka utama yang dapat diklik yang membuka rincian adalah satu metrik, bukan tujuh. Perlakukan hitungan tile di permukaan sebagai batasnya.
• Tile "referensi" (definisi, stempel waktu pembaruan, panel filter) tidak dihitung dalam 5. Hanya tile yang dibaca pemangku kepentingan untuk mengambil keputusan.

Saya pernah mengirimkan dasbor dengan tiga metrik. Tiga. CFO membukanya setiap minggu. Saya pernah mengirimkan dasbor dengan sebelas metrik. CFO membukanya sekali dan meminta saya untuk "merangkum kesimpulannya." Itulah dasbor yang sama yang gagal.

Konteks mengalahkan visualisasi, selalu

Ini adalah hal yang tampak bertentangan: angka dengan diagnosis tertulis mengalahkan grafik yang indah tanpa narasi. Selalu.

"MRR: 4,18M (-4,2% MoM)" dengan anotasi satu baris ("Turun didorong oleh 3 churn enterprise di EMEA, ketiganya sudah ditandai di QBR; pemesanan ekspansi 2,1M mengimbangi secara net menjadi -1,8%") lebih berguna daripada grafik garis paling indah di dunia. Karena grafik menunjukkan sesuatu terjadi. Anotasi memberitahu Anda apa yang terjadi, mengapa, dan apakah perlu panik.

Jadikan ini aturan untuk setiap tile yang masuk ke dasbor yang akan dibaca manusia: satu baris tentang "apa yang berubah dan mengapa." Bukan paragraf. Satu baris. Jika Anda tidak bisa menulisnya, tile tersebut belum siap untuk dikirimkan.

Ini adalah bagian yang paling sering dilewatkan analyst karena terasa seperti menulis, bukan menganalisis. Itu adalah analisis. Tindakan menulis "turun 4,2% karena tiga churn enterprise di EMEA" memaksa Anda untuk benar-benar menjawab pertanyaan tersebut daripada hanya menyajikan grafik dan pergi. Jika jawabannya adalah "saya belum tahu," itu juga anotasi yang valid. "Turun 4,2% MoM, akar masalah TBD pada hari Jumat, lihat #data-investigations" memberitahu pemangku kepentingan bahwa Anda melihatnya, Anda sedang menanganinya, dan mereka tidak perlu menghubungi Anda. Notifikasi yang tidak Anda terima itu adalah teks dengan ROI tertinggi yang akan Anda tulis sepanjang minggu ini.

Tool yang memudahkan ini: text cell Hex di samping chart cell, HTML tile Looker dengan komentar bertemplate, dasbor Tableau dengan objek teks catatan kaki per tile. Semuanya mendukung pola ini. Tidak ada yang menegakkannya. Anda yang menegakkannya.

Post-mortem kepanikan "laporan ini salah"

Pada akhirnya seorang pemangku kepentingan akan mempertanyakan sebuah angka. Itu tidak dapat dihindari. Pertanyaannya adalah apakah Anda menanganinya seperti seorang profesional atau seperti seseorang yang mencoba memenangkan argumen di Slack.

Berikut protokolnya. Hafalkan. Ini akan menyelamatkan karier Anda setidaknya dua kali.

Langkah 1. Akui dalam 5 menit, bukan 5 jam. "Oke, sedang saya cek, akan saya balas EOD dengan temuan saya." Itulah seluruh pesannya. Jangan membela. Jangan berargumen. Jangan menjelaskan mengapa angka Anda benar sebelum Anda benar-benar memeriksanya. Kecemasan pemangku kepentingan menurun segera setelah mereka melihat "sedang saya cek."

Langkah 2. Konfirmasi kuerinya. Buka SQL yang mendasarinya. Jalankan ulang. Apakah Anda mereproduksi angka dasbor? Jika ya, dasbor tidak berbohong. Masih ada pertanyaan apakah kuerinya benar, tetapi permukaannya konsisten. Jika tidak, Anda memiliki masalah caching atau penjadwalan; tandai dan perbarui.

Langkah 3. Konfirmasi sumber kebenaran. Apa yang dikatakan Finance / RevOps / sistem pencatatan? Apakah kolom mrr Anda berasal dari subscriptions.amount atau dari tampilan terwujud monthly_recurring_revenue yang dibangun pada tahun 2022 oleh seseorang yang sudah pergi? Apakah Finance menarik langsung dari Stripe sementara Anda menarik dari sinkronisasi Fivetran yang tertinggal 6 jam? 90% tiket "laporan ini salah" diselesaikan di sini, dan resolusinya jarang "dasbor yang salah" atau "Finance yang salah." Itu adalah "kita menghitung dua hal yang sedikit berbeda dan menyebutnya dengan nama yang sama."

Langkah 4. Dokumentasikan ketidaksesuaiannya. Dalam template post-mortem, isi: stempel waktu laporan, kueri yang digunakan (tempel seluruhnya), nilai sumber kebenaran, nilai dasbor, akar masalah (ketidaksesuaian definisi / data basi / bug sebenarnya), perbaikan (jalankan ulang / perubahan definisi / anotasi baru), dan komunikasi pemangku kepentingan.

Langkah 5. Kirimkan perbaikan atau peringatan dalam 24 jam. Baik Anda memperbaiki masalah mendasarnya, atau Anda menambahkan anotasi tingkat tile yang menjelaskan kesenjangan. Keduanya dapat diterima. Yang tidak dapat diterima adalah membiarkannya tertunda sementara dua bagian organisasi terus beroperasi dengan angka yang berbeda.

Jangan pernah berargumen di thread Slack. Argumen dalam thread adalah cara analyst mendapat reputasi sebagai "defensif." Pindahkan percakapan ke dokumen post-mortem dalam 30 menit. Dokumen adalah artefaknya. Thread adalah kebisingannya.

Saya menyimpan catatan berjalanan dari setiap post-mortem kepanikan yang pernah saya kirimkan. Membacanya kembali adalah latihan pengembangan keahlian tunggal terbaik yang saya lakukan. Saya dapat melihat dengan tepat ketidaksesuaian definisi mana yang terus berulang (selalu tentang pengakuan pendapatan, selalu) dan di mana harus berinvestasi dalam perbaikan hulu. Setiap kepanikan juga merupakan sinyal tentang tile mana yang membutuhkan anotasi permanen agar orang berikutnya tidak perlu mengirim notifikasi.

Tingkat adopsi adalah metrik yang membuktikan dasbor berfungsi

Dasbor yang Anda bangun kuartal lalu: apakah berfungsi? Sebagian besar analyst tidak bisa menjawab pertanyaan itu, yang sangat aneh karena kita secara profesional terobsesi dengan pengukuran.

Instrumentasikan tingkat adopsi. Setiap BI tool memiliki datanya:

• Looker memiliki System Activity, sebuah Explore internal. history.query_run_count, dashboard.view_count, user.id, semua dapat dikueri.
• Tableau Server / Cloud memiliki proyek Admin Insights. views_workbooks dan views_dashboards memberikan pembukaan per aset per pengguna.
• Hex memiliki analitik penggunaan bawaan di halaman pengaturan workspace.
• Mode memiliki Discovery API dan laporan admin.
• Power BI memiliki laporan Usage Metrics per workspace.

Lacak tiga angka per dasbor, setiap bulan:

1. Pemirsa unik. Bukan pembukaan. Manusia. Dasbor dengan 200 pembukaan dari 2 pemirsa adalah tab yang dibiarkan terbuka seseorang, bukan dasbor yang berfungsi.
2. Waktu di dasbor. Dasbor yang tidak digulir oleh siapa pun adalah dasbor yang tidak dibaca siapa pun. Sebagian besar BI tool mencatat durasi sesi; di bawah 30 detik berarti mereka membukanya dan langsung pergi.
3. Tingkat pemirsa berulang. Dari pemirsa bulan lalu, berapa banyak yang kembali bulan ini? Pemirsa berulang adalah audiens nyata. Yang lain datang sekali dan melanjutkan.

Dasbor dengan kurang dari 3 pemirsa unik per bulan, selama dua bulan berturut-turut, adalah kandidat penghapusan. Bukan kandidat "perlu didesain ulang." Kandidat penghapusan. Berhenti mengoptimalkan hal-hal yang tidak dibuka siapa pun.

Latihan paling berguna yang saya lakukan setiap kuartal: beri peringkat setiap dasbor yang saya miliki berdasarkan jumlah pemirsa berulang. 5 teratas mendapat waktu dan perhatian saya. 5 terbawah mendapat tinjauan penghapusan. Yang di tengah mendapat pengabaian yang baik, yang tidak masalah. Pengabaian itu murah, penghapusan itu jujur, dan perawatan aktif itu mahal. Habiskan di tempat yang memberi hasil.

Tinjauan penghapusan 6 bulan

Penghapusan adalah fitur, bukan kegagalan. Adopsi prinsip ini dan Anda tidak akan pernah merasa buruk menghapus dasbor lagi.

Setiap enam bulan, Anda melakukan pembersihan. Blokir setengah hari. Tarik data tingkat adopsi untuk setiap dasbor di ruang Anda. Urutkan berdasarkan pemirsa unik, dari yang terkecil. Kemudian:

1. Apa pun yang kurang dari 3 pemirsa/bulan selama 6 bulan terakhir: arsipkan. Bukan hapus. Arsipkan. Pindahkan ke folder tersembunyi, kirim pin di #data-archive yang mengumumkan apa yang dipindahkan, sertakan daftar arsip. Jika ada yang complain, Anda bisa memulihkannya dalam 60 detik. Tidak ada yang akan complain. Mereka tidak membukanya.
2. Apa pun yang 3-10 pemirsa/bulan: konfirmasi ulang kepemilikan. Hubungi pemilik yang tercantum. "Masih memiliki ini? Masih relevan? Masih memiliki keputusan yang dinamai?" Jika pemiliknya sudah pergi, Anda adalah pemilik baru. Putuskan apakah layak dipertahankan atau dikirim ke arsip. Tidak ada balasan dalam satu minggu = arsip.
3. Apa pun yang 10+ pemirsa/bulan: pertahankan, audit anotasi tile, perbarui angka yang basi, dan perbarui keputusan di judul jika bisnis telah bergeser. Ini adalah area permukaan nyata Anda. Mereka layak mendapat pemeliharaan.
4. Umumkan daftar penghapusan secara publik. Pesan singkat di kanal data organisasi: "Pembersihan selesai: 12 dasbor diarsipkan, 47 dipertahankan, berikut daftarnya." Tiga hal terjadi. (a) Tidak ada yang complain karena tidak ada yang benar-benar mereka gunakan yang menghilang. (b) Tim lain melihat siklus ini dan mulai melakukannya sendiri. (c) Pimpinan memperhatikan bahwa seseorang memperlakukan instansi BI seperti infrastruktur, bukan tempat sampah.

Pertama kali saya menjalankan pembersihan seperti ini di perusahaan sebelumnya, saya mengarsipkan 38 dasbor. Dua orang menghubungi saya, keduanya tentang dasbor yang sama, yang saya pulihkan dalam tiga menit. Itulah seluruh permukaan risikonya. Hadiahnya adalah instansi BI yang memuat lebih cepat, hasil pencarian yang lebih jelas, dan thread Slack "tunggu, mana dasbor pendapatan yang benar?" yang jauh lebih sedikit.

Dalam enam bulan, instansi BI Anda harus memiliki lebih sedikit dasbor dari sekarang. Bukan lebih banyak. Jika lebih banyak, disiplin desain tidak berfungsi dan siklus penghapusan dilewati. Keduanya dapat diperbaiki. Keduanya adalah pekerjaan Anda.

Template yang bisa Anda gunakan

Spesifikasi satu halaman dasbor. Isi sebelum membangun:

• Keputusan yang dijawab dasbor ini: (satu kalimat, diakhiri dengan kata kerja)
• Audiens: (peran yang disebutkan, bukan "pemangku kepentingan")
• 5 metrik utama, diurutkan: (1, 2, 3, 4, 5)
• Siklus pembaruan: (real-time / per jam / harian / mingguan, sesuaikan dengan kecepatan keputusan)
• Pemilik: (manusia yang disebutkan, bukan tim)
• Kriteria sunset: ("arsipkan jika kurang dari 3 pemirsa unik/bulan selama 60 hari")

Template post-mortem kepanikan. Isi dalam 24 jam setelah setiap tantangan:

• Dilaporkan oleh, kapan, di kanal mana
• Angka yang diharapkan pemangku kepentingan vs angka dasbor
• Kueri yang digunakan (tempel SQL lengkap)
• Perbandingan sumber kebenaran (nilai Finance / RevOps / sistem)
• Akar masalah (definisi / kesegaran / bug / kesalahan pengguna / sebenarnya benar)
• Perbaikan yang dikirimkan (tautan ke PR atau anotasi)
• Komunikasi kembali ke pemangku kepentingan (tempel balasannya)

Daftar periksa tinjauan 6 bulan. Blokir setengah hari, jalankan pembersihan:

• Tarik data tingkat adopsi untuk semua dasbor yang dimiliki
• Urutkan dari yang terkecil berdasarkan pemirsa unik
• Arsipkan: kurang dari 3 pemirsa/bulan selama 6 bulan
• Konfirmasi ulang kepemilikan: 3-10 pemirsa/bulan
• Audit dan perbarui: 10+ pemirsa/bulan
• Umumkan daftar penghapusan secara publik
• Perbarui log penghapusan (tanggal, jumlah yang diarsipkan, jumlah yang dipertahankan)

Ketiga dokumen ini mencakup 90% dari kebersihan dasbor. Cetak. Pasang. Gunakan.

Kesalahan umum

Beberapa pola yang saya lihat, berulang kali, di setiap tim:

• Membangun dari permintaan, bukan dari keputusan. Pemangku kepentingan berkata "saya ingin grafik konversi berdasarkan sumber." Anda membangunnya. Anda mengirimkannya. Enam minggu kemudian, tidak ada yang membukanya, karena keputusan sebenarnya adalah "haruskah kita terus membayar kontrak Google Ads?", dan itu membutuhkan CAC berdasarkan sumber ditambah overlay retensi, bukan grafik batang konversi. Selalu tanyakan keputusan sebelum menulis SQL.
• Dasbor eksekutif dengan 14 tile karena VP "ingin melihat segalanya." VP tidak ingin melihat segalanya. VP ingin merasa terinformasi dan menemukan dua kejutan. Berikan mereka dasbor 5 tile dengan ringkasan satu baris tertulis di atasnya, dan mereka akan berterima kasih kepada Anda. Mungkin mempromosikan Anda, pada akhirnya.
• Palet pelangi. Delapan seri, delapan warna, semua saturasi yang sama. Pengguna tidak membaca apa pun. Gunakan satu aksen, abu-abukan selebihnya, sorot hanya seri yang bergantung pada keputusan.
• Tidak pernah menghapus, hanya menambahkan. Ini adalah kematian perlahan. Setiap kuartal, jumlahnya bertambah. Setiap kuartal, kualitas rata-rata dasbor menurun. Enam bulan kemudian, instansi BI tidak dapat dicari dan tiga dasbor berbeda mengatakan tiga hal berbeda tentang MRR. Solusinya adalah siklus pembersihan. Tanpanya, Anda menambahkan utang teknis selamanya.

Seperti apa "bagus" itu

Anda telah menginternalisasi ini ketika:

• Setiap dasbor yang Anda miliki memiliki keputusan yang disebutkan dalam judulnya, bukan topik.
• Anda bisa menyebutkan, dari ingatan, 5 dasbor teratas Anda berdasarkan tingkat adopsi dan 5 kandidat penghapusan terbawah.
• Notifikasi "laporan ini salah" menurun dari kuartal ke kuartal, karena setiap tile memiliki diagnosis tertulis yang dibaca pemangku kepentingan terlebih dahulu.
• Instansi BI memiliki lebih sedikit dasbor dalam 6 bulan dari sekarang, bukan lebih banyak.
• Dokumen post-mortem kepanikan Anda memiliki setidaknya 5 entri dari tahun lalu, dan Anda bisa menunjuk perbaikan hulu yang lahir dari masing-masing.

Itulah standarnya. Bukan "saya membangun lebih banyak dasbor." Bukan "pemangku kepentingan menyukai grafik saya." Ini adalah: saya mengirimkan area permukaan yang digunakan orang, saya mendokumentasikan kegagalan, dan saya menghapus yang tidak layak dipertahankan.

Desain dasbor bukan latihan estetika. Ini adalah latihan anggaran perhatian. Setiap tile membutuhkan perhatian pemangku kepentingan. Setiap dasbor membutuhkan waktu pemeliharaan Anda. Habiskan keduanya seperti sesuatu yang langka, karena memang demikian.

Pelajari Lebih Lanjut

• Manajemen Pemangku Kepentingan untuk Data Analyst
• SQL dan Pemodelan Data yang Dapat Diskalakan
• Metrik Data Analyst: Waktu Menuju Wawasan, Tingkat Adopsi, Dampak
• Template Job Description Data Analyst