Dashboard không ai mở là dashboard thất bại
Một dashboard tồn tại để hỗ trợ một quyết định lặp lại. Nếu không ai nêu được quyết định đó, dashboard sẽ chết trong vòng vài tháng, bất kể nó đẹp tới đâu.
Phép thử trước khi xây: ai sẽ mở cái này, bao lâu một lần, và họ sẽ làm gì khác đi tuỳ theo con số?
Ba loại trình bày, ba mục đích
- Dashboard theo dõi: ít chỉ số, có ngưỡng và so sánh với kỳ trước. Mục đích là phát hiện bất thường, không phải khám phá.
- Phân tích sâu: một câu hỏi, một câu trả lời, kèm lập luận. Dạng tài liệu, không phải dashboard.
- Cảnh báo: đẩy tới người cần biết khi vượt ngưỡng. Hiệu quả hơn dashboard rất nhiều, vì nó không đòi ai nhớ đi mở.
Nguyên tắc trình bày
- Một con số luôn cần một điểm so sánh: kỳ trước, mục tiêu, hoặc phân khúc khác. Con số đứng một mình không nói lên gì.
- Đặt ngưỡng, không chỉ vẽ đường. Người đọc cần biết bao nhiêu là bình thường.
- Ghi rõ định nghĩa và thời điểm cập nhật ngay trên biểu đồ. Nó chặn trước câu hỏi "số này tính thế nào".
- Ít hơn là nhiều hơn. Một dashboard 30 biểu đồ sẽ không ai đọc. Năm tới bảy là đủ.
Viết phần diễn giải
Phần có giá trị nhất thường không phải biểu đồ mà là câu văn giải thích điều gì đang xảy ra và nên làm gì. Cấu trúc ba câu:
> Chuyện gì đã xảy ra (con số, so với gì). > Vì sao (giả thuyết, kèm mức độ chắc chắn). > Đề xuất làm gì (hoặc: cần điều tra thêm gì).
Nêu rõ mức độ chắc chắn quan trọng hơn người ta nghĩ. "Chúng tôi chưa biết vì sao" là một câu trả lời hợp lệ và đáng tin hơn nhiều so với một giả thuyết bịa ra cho đủ.
Sai lầm thường gặp
- Xây dashboard không gắn với quyết định nào.
- Trộn ba mục đích vào một màn hình.
- Đưa con số không có điểm so sánh.
- Chỉ đưa biểu đồ, không có diễn giải.
Checklist kết bài
- [ ] Mỗi dashboard của tôi gắn với một quyết định lặp lại.
- [ ] Tôi tách theo dõi, phân tích sâu và cảnh báo.
- [ ] Mọi con số đều có điểm so sánh và ngưỡng.
- [ ] Tôi viết diễn giải ba câu kèm mức độ chắc chắn.
Cảnh báo hiệu quả hơn dashboard
Dashboard đòi ai đó nhớ đi mở. Cảnh báo tự tìm tới người cần biết. Với phần lớn chỉ số vận hành, cảnh báo là lựa chọn đúng.
Một cảnh báo dùng được cần bốn thứ:
- Ngưỡng cụ thể, không phải "bất thường"
- Người nhận cụ thể, không phải kênh chung
- Câu gợi ý hành động: "Tỉ lệ thanh toán thất bại vượt 8% — kiểm cổng thanh toán A"
- Đường tắt tới dữ liệu chi tiết
Thiết kế dashboard theo dõi
Nếu vẫn cần dashboard, giữ nó chặt:
| Quy tắc | Vì sao |
|---|---|
| Tối đa 5–7 chỉ số | Trên đó thì không ai quét hết |
| Luôn có mốc so sánh | Một con số đứng một mình không nói lên gì |
| Có ngưỡng màu | Để biết cần chú ý chỗ nào trong 3 giây |
| Ghi thời điểm cập nhật cuối | Dữ liệu cũ mà không ai biết là nguồn của quyết định sai |
| Một câu giải thích mỗi chỉ số | Người mới đọc hiểu được mà không cần hỏi |
Phân tích sâu là tài liệu, không phải dashboard
Khi trả lời một câu hỏi cụ thể, đừng dựng dashboard — viết một tài liệu:
- Câu hỏi
- Câu trả lời ngắn gọn, ngay đầu
- Bằng chứng
- Giới hạn của phân tích — điều này chưa trả lời được gì
- Đề xuất hành động
Làm ngay
Chọn dashboard được xem nhiều nhất của bạn. Kiểm năm quy tắc ở trên. Rồi hỏi: có chỉ số nào ở đây nên là cảnh báo thay vì một ô trên màn hình không?
Một lưu ý về biểu đồ
Loại biểu đồ nên phục vụ câu hỏi, không phục vụ sự đa dạng:
| Câu hỏi | Dùng |
|---|---|
| Xu hướng theo thời gian | Đường |
| So sánh giữa các nhóm | Cột ngang, sắp xếp theo giá trị |
| Tỉ trọng trong tổng | Cột chồng — tránh biểu đồ tròn khi trên 3 phần |
| Phân bố | Histogram — trung bình che giấu phần đuôi |
<!--case-append-->
Áp dụng vào Căng tin số
Sau bốn tuần, nhóm có hàng chục con số. Chị Lan cần đúng một thứ: đủ căn cứ để quyết bước tiếp theo, mở rộng sang quầy thứ hai, sửa giờ chốt trước, hay cả hai. Người đầu tiên mở trang tổng kết là chị, một lần sau chạy thử, và câu trả lời của chị sẽ khác đi tuỳ theo con số. Vậy trang đó phải được dựng quanh quyết định của chị, không quanh mọi thứ nhóm đo được.
Bảng chính chỉ giữ những chỉ số có đường cơ sở để so:
| Chỉ số | Trước chạy thử | Tuần 4 | Ghi chú |
|---|---|---|---|
| Xếp hàng thường giờ cao điểm, trung vị | 21 phút | 17 phút | Tuần 3 là 15 phút do tuần thi, không dùng |
| Suất bỏ đi quầy cơm mỗi ngày | 40 | 26 | Sổ của Cô Hạnh |
| Email phàn nàn mỗi tháng | 25 | 14 | 3 trong 14 là về chính app |
| Doanh thu quầy cơm | đường cơ sở | tăng 4% | Chỉ số canh gác, không được giảm |
| Hoàn tiền vì hết món mỗi ngày | chưa có | 2 lần | Mỗi lần vẫn chờ Anh Tuấn duyệt giữa giờ cao điểm |
Phần đáng giá nhất là ba câu diễn giải ở đầu trang:
> Trong tuần 4, xếp hàng thường ở quầy cơm giảm từ 21 xuống 17 phút và suất bỏ đi giảm từ 40 xuống 26, trong khi doanh thu quầy cơm tăng 4%. > Lý do hợp lý nhất là khoảng 205 suất mỗi ngày đã rời khỏi hàng thường; mức độ chắc chắn vừa phải, vì không có nhóm đối chứng và tuần 3 bị tuần thi làm đẹp. > Đề xuất sửa giờ chốt 10:00 trước khi mở rộng, vì 21 trong 40 người bỏ ngang được hỏi nói đã quá 10 giờ, không đặt được nữa.
Câu thứ hai dám nói "chưa chắc", và chính điều đó làm Chị Lan tin cả trang. Sau đó mới tới tài liệu phân tích kèm phần giới hạn: dữ liệu chỉ có sinh viên, chưa có giảng viên và nhân viên trường, và chỉ một quầy.
Với vận hành hằng ngày thì dashboard là lựa chọn sai, cảnh báo mới đúng. Nhưng một cảnh báo chỉ dùng được khi người nhận làm được gì đó với nó. Cô Hạnh nói giờ cao điểm cô không cầm điện thoại được, nên gửi tin nhắn cho cô lúc 11:50 là vô ích. Thông tin cho bếp đi qua thứ cô đã nói là làm được: phiếu in. Cảnh báo "có hoàn tiền đang chờ duyệt" thì gửi cho Anh Tuấn, kèm một câu gợi ý hành động rõ ràng.
Thử ngay: viết lại ba câu diễn giải ở trên cho một người đọc khác, Anh Tuấn, người quan tâm tới tiền và tới việc trả trước. Con số nào đổi chỗ lên đầu, và đề xuất của bạn có đổi không? <!--/case-append-->