Trực quan hoá 5 — Thiết kế Dashboard

13 thg 7, 2026 3 lượt xem
#bi
#dashboard
#ux
#data-visualization
#design

Trực quan hoá 5 — Thiết kế Dashboard

Một dashboard tồi không phải là dashboard xấu — nó là dashboard trả lời sai câu hỏi. Ta thường thấy những trang chi chít 20 biểu đồ, đủ màu cầu vồng, mỗi cái "đẹp" riêng, nhưng khi lãnh đạo hỏi "huy động tháng này có đạt kế hoạch không?" thì phải mất một phút dò tìm. Vấn đề không nằm ở kỹ thuật vẽ chart — bài Chọn biểu đồ đúng đã lo phần đó — mà ở chỗ dashboard được lắp ráp từ dữ liệu có sẵn thay vì thiết kế ngược từ nhu cầu ra quyết định.

Bài này bàn về tầng trên của chart: cách gom nhiều biểu đồ và con số thành một màn hình duy nhất có mục đích. Ta bắt đầu từ người dùng và câu hỏi, phân biệt ba loại dashboard, đi qua các nguyên tắc bố cục dựa trên tri giác thị giác (nối tiếp Tri giác thị giác), cách trình bày KPI có ngữ cảnh, mức tương tác hợp lý, và danh sách lỗi kinh điển cần tránh — tất cả đặt trong bối cảnh dashboard điều hành và giám sát vận hành của một ngân hàng.

Bắt đầu từ người dùng và câu hỏi

Trước khi kéo bất kỳ chart nào, trả lời ba câu:

  1. Ai xem? Thành viên Ban điều hành, trưởng phòng nghiệp vụ, hay nhân viên vận hành trực ca? Trình độ đọc dữ liệu, thiết bị (màn hình lớn phòng họp vs điện thoại), và ngôn ngữ của họ khác nhau hoàn toàn.
  2. Để ra quyết định gì? Một dashboard tồn tại để hỗ trợ một loại quyết định. "Có cần điều chỉnh lãi suất huy động không?" là một quyết định. "Xem cho vui" không phải — và đó là gốc rễ của mọi dashboard phình to vô dụng.
  3. Tần suất nào? Quyết định hàng tháng (điều hành) cần dashboard khác hẳn quyết định trong vài giây (giám sát cảnh báo gian lận). Tần suất định ra độ tươi của dữ liệu, mức chi tiết và cả cách bố trí.

Từ ba câu này, hãy làm thiết kế ngược: liệt kê 5–7 câu hỏi cụ thể mà người dùng cần dashboard trả lời, sắp theo mức quan trọng, rồi mỗi câu hỏi mới sinh ra một thành phần. Nếu một chart không gắn với câu hỏi nào trong danh sách, nó không có chỗ trên dashboard. Cách này ngăn ngay từ đầu hội chứng "có dữ liệu nên cho lên luôn".

Một mẹo phỏng vấn người dùng: hỏi "khi con số này xấu, anh/chị sẽ làm gì?". Nếu họ không có hành động nào, chỉ số đó có thể là interesting chứ không actionable — cân nhắc bỏ hoặc đẩy xuống lớp chi tiết.

Ba loại dashboard

Ba loại dưới đây khác nhau về mục đích, người dùng và thiết kế. Nhầm loại là nguồn gốc của phần lớn dashboard hỏng — ví dụ nhồi khả năng khám phá (analytical) vào một màn hình điều hành, khiến lãnh đạo lạc trong drill-down thay vì thấy bức tranh lớn.

Strategic (điều hành, cấp cao). Dành cho lãnh đạo. Trả lời "chúng ta đang đi đúng hướng không?". Đặc trưng: một nhúm KPI cốt lõi kèm mục tiêu và xu hướng, độ chi tiết thấp, dữ liệu tổng hợp (theo tháng/quý), cập nhật không cần tức thời. Nguyên tắc vàng: ít mà sâu. Một dashboard điều hành lý tưởng vừa một màn hình, đọc hết trong một phút. Nếu lãnh đạo phải cuộn hoặc click, đã sai định dạng.

Analytical (phân tích, khám phá). Dành cho analyst và trưởng phòng. Trả lời "vì sao con số lại như vậy?". Đặc trưng: nhiều chiều để cắt lát (theo chi nhánh, sản phẩm, thời gian), drill-down, so sánh, bộ lọc phong phú. Ở đây mật độ thông tin cao hơn là chấp nhận được vì người dùng chủ động điều tra chứ không liếc nhanh.

Operational (vận hành, giám sát). Dành cho đội trực ca, trung tâm vận hành. Trả lời "ngay bây giờ có gì bất thường không?". Đặc trưng: dữ liệu real-time hoặc gần real-time, ngưỡng và cảnh báo màu (đỏ/vàng/xanh), thiết kế để liếc là thấy — thường hiển thị trên màn hình lớn treo tường (wallboard). Trạng thái "bình thường" phải im lặng; chỉ cái bất thường mới nổi bật.

Tiêu chíStrategicAnalyticalOperational
Người dùngBan điều hànhAnalyst, trưởng phòngĐội vận hành
Câu hỏiĐúng hướng?Vì sao?Có bất thường?
Độ tươi dữ liệuNgày–thángNgàyGiây–phút
Chi tiếtThấp (tổng hợp)Cao (drill-down)Trung bình, tập trung cảnh báo
Tương tácRất ítNhiềuTối thiểu
Ví dụ NCBBảng KPI huy động/tín dụng/rủi roPhân tích cơ cấu huy động theo chi nhánhGiám sát giao dịch, hàng đợi cảnh báo AML

Một hệ dashboard tốt thường có cả ba tầng và có đường đào sâu: từ strategic (thấy KPI đỏ) → analytical (điều tra nguyên nhân) → operational (theo dõi khắc phục).

Nguyên tắc bố cục

Bố cục là nơi tri giác thị giác gặp thiết kế. Vài nguyên tắc cốt lõi:

Hệ thống phân cấp trực quan

Mắt người không đọc dashboard đồng đều — nó quét theo mẫu. Với bố cục nhiều chữ/số, mắt quét kiểu F (ngang trên cùng, ngang giữa, rồi dọc mép trái); với bố cục thoáng, kiểu Z (trên-trái → trên-phải → chéo xuống → dưới-phải). Cả hai đều nói cùng một điều: góc trên-trái là bất động sản đắt nhất. Đặt thông tin quan trọng nhất ở đó, cỡ lớn. Thông tin phụ trợ đẩy xuống dưới và sang phải.

Phân cấp được tạo bằng ba đòn bẩy tiền chú ý (preattentive, xem Tri giác thị giác): kích thước (số KPI to gấp 3–4 lần nhãn), vị trí (trên-trái), và màu (chỉ tô màu cái cần chú ý, phần còn lại xám). Nếu mọi thứ đều to và đều màu, thì không có gì nổi bật — và "mọi thứ đều quan trọng" nghĩa là không gì quan trọng.

Nhóm liên quan (Gestalt)

Các thông tin liên quan phải trông như thuộc về nhau. Dùng nguyên lý Gestalt (xem viz-02): gần nhau (proximity — đặt sát), bao chung (common region — chung một ô nền/khung), giống nhau (similarity — cùng màu, cùng kiểu). Ba KPI huy động nên nằm một cụm; KPI rủi ro nằm cụm khác. Đừng để mắt phải nhảy khắp màn hình để ghép các mảnh của cùng một câu chuyện.

Inverted pyramid (kim tự tháp ngược)

Mượn từ báo chí: đặt kết luận lên trước, chi tiết theo sau. Trên cùng là tổng quan "một dòng" (các KPI với trạng thái đạt/không đạt). Ở giữa là bằng chứng và xu hướng. Dưới cùng là chi tiết cho ai muốn đào sâu. Người bận đọc hàng đầu là đủ; người tò mò đọc tiếp. Cấu trúc này khớp tự nhiên với đường đào sâu strategic → analytical.

Quy tắc 5 giây

Kiểm thử vàng cho dashboard điều hành: cho một người chưa quen nhìn 5 giây rồi hỏi "tình hình chung thế nào, có gì cần chú ý?". Nếu họ nắm được ý chính — đâu ổn, đâu có vấn đề — thì bố cục đạt. Nếu họ lúng túng, phân cấp trực quan đang thất bại. Quy tắc này ép ta trả lời: cái gì nên thấy đầu tiên? và thiết kế để cái đó thắng cuộc đua thu hút ánh nhìn.

Chọn và trình bày KPI

KPI là trái tim của dashboard strategic. Một con số trần trụi hầu như vô nghĩa — "Huy động: 52.300 tỷ" trả lời được gì? Nhiều hay ít? Tốt hay xấu? Con số chỉ có nghĩa khi có ngữ cảnh. Mỗi KPI nên đi kèm ít nhất một trong ba loại ngữ cảnh:

  • So với mục tiêu (target): đạt bao nhiêu % kế hoạch. Đây là ngữ cảnh mạnh nhất cho điều hành.
  • So với kỳ trước (comparison): tăng/giảm so với tháng trước, cùng kỳ năm trước (YoY). Kèm mũi tên và % thay đổi.
  • Xu hướng (trend): hình dạng vài kỳ gần đây, thường là một sparkline — biểu đồ đường tí hon đặt cạnh con số, cho thấy quỹ đạo mà không tốn chỗ.

Mẫu trình bày gọn và mạnh nhất là số lớn + ngữ cảnh: con số KPI cỡ đại, ngay dưới là delta so kỳ trước (màu xanh/đỏ), và một sparkline nhỏ. Khi cần so với mục tiêu chính xác, bullet chart vượt trội gauge tròn: nó gói giá trị thực, mục tiêu và các dải ngưỡng vào một thanh dẹt, tiết kiệm chỗ và đọc chính xác hơn (xem Chọn biểu đồ). Tránh gauge/đồng hồ tròn kiểu ô tô — chúng tốn diện tích khổng lồ để hiển thị đúng một con số.

Về việc chọn đúng KPI nào (leading vs lagging, tránh vanity metric, định nghĩa nhất quán), xem sâu ở Metrics & KPI. Ở đây điểm cốt lõi: một dashboard điều hành nên có 5–9 KPI, không phải 30. Quá nhiều KPI thì không cái nào là "key".

Tương tác đúng mức

Tương tác là con dao hai lưỡi. Đúng loại dashboard, nó tăng sức mạnh; sai chỗ, nó biến dashboard điều hành thành mê cung.

  • Filter (bộ lọc): cho phép cắt theo thời gian, chi nhánh, sản phẩm. Rất hợp analytical, dùng dè xẻn ở strategic (lãnh đạo muốn thấy ngay, không muốn cấu hình).
  • Drill-down: click vào một KPI/vùng để mở lớp chi tiết bên dưới (tổng → theo chi nhánh → theo phòng giao dịch). Đây là hiện thân của inverted pyramid: mặt trên gọn, chi tiết ẩn sau một cú click.
  • Cross-filter: click một phần tử ở chart này lọc luôn các chart khác trên cùng trang. Mạnh cho khám phá nhưng dễ gây bối rối nếu không có phản hồi thị giác rõ ràng.

Nguyên tắc: operational gần như không tương tác (người trực ca cần liếc, không cần click), strategic tương tác tối thiểu, analytical mới là nơi tương tác phong phú. Và luôn tuân thủ overview first, zoom and filter, details on demand (nguyên tắc Shneiderman): tổng quan trước, chi tiết khi được yêu cầu — đừng bắt người dùng thấy mọi chi tiết ngay lập tức.

Những lỗi cần tránh

  • Nhồi nhét quá nhiều. Cám dỗ lớn nhất. Một dashboard 25 chart không truyền tải gấp năm lần một dashboard 5 chart — nó truyền tải ít hơn, vì không gì nổi bật. Mỗi phần tử thêm vào làm loãng mọi phần tử cũ. Hỏi tàn nhẫn: "nếu bỏ cái này thì quyết định có đổi không?".
  • Chartjunk. Trang trí thừa: gradient, bóng đổ, hoạ tiết nền, icon vô nghĩa, đường lưới đậm, viền dày. Chúng chiếm "mực" mà không mang dữ liệu (nghịch với data-ink ratio của Tufte). Xoá sạch.
  • Cầu vồng màu. Mỗi chart một bảng màu khác, mỗi danh mục một màu rực. Màu phải có mã nghĩa nhất quán (xem Thiết kế màu): một màu = một ý nghĩa xuyên suốt dashboard. Dùng màu tiết kiệm để làm nổi bật, phần lớn để trung tính.
  • Thiếu ngữ cảnh. Con số trần không mục tiêu, không so sánh, không đơn vị, không thời điểm. Người xem không biết 52.300 là tốt hay báo động.
  • "Mọi thứ đều quan trọng". Không có phân cấp — mọi chart cùng cỡ, cùng độ nổi bật. Kết quả là mắt không biết nhìn đâu trước. Phải có kẻ thắng rõ ràng trong cuộc đua thu hút ánh nhìn.

Responsive, hiệu năng, và nhất quán

Responsive. Dashboard điều hành chiếu lên màn hình phòng họp khác với xem trên điện thoại của giám đốc chi nhánh. Thiết kế cho thiết bị thực tế của người dùng; nếu đa thiết bị, ưu tiên bố cục xếp dọc được (mobile-first) và giấu bớt chi tiết trên màn nhỏ.

Hiệu năng. Một dashboard đẹp mà load 30 giây thì không ai dùng. Nguyên nhân thường là query nặng chạy live trên dữ liệu thô. Giải pháp: pre-aggregate (dựng bảng tổng hợp/OLAP trước), cache, giới hạn số phần tử, tránh query mở toang toàn bộ lịch sử. Về tổng hợp trước và mô hình đa chiều, đây là nơi lớp semantic/OLAP phát huy — xem Open-source BI. Một dashboard operational cập nhật mỗi vài giây càng phải nhẹ.

Nhất quán và mẫu tái dùng. Toàn bộ hệ dashboard nên dùng chung ngôn ngữ thị giác: cùng bảng màu ngữ nghĩa, cùng kiểu định dạng số (đơn vị tỷ đồng, dấu phân cách), cùng vị trí bộ lọc, cùng cách hiển thị delta. Xây một template và tái dùng — vừa tiết kiệm công, vừa giảm tải nhận thức (người dùng học một lần, áp dụng khắp nơi). Sự bất nhất buộc não phải "học lại" ở mỗi trang.

Use case thực tế

Bối cảnh. Ban điều hành NCB yêu cầu một dashboard huy động/tín dụng/rủi ro cập nhật hằng ngày. Bản đầu của đội BI có 22 chart trên ba màn hình cuộn: nhiều pie 3D, một gauge tròn khổng lồ cho LDR, các bảng dài không sắp xếp, mỗi chart một bảng màu. Trong cuộc họp, một Phó Tổng hỏi "nợ xấu tháng này so kế hoạch thế nào?" — mất gần hai phút mới tìm thấy con số, và nó không kèm mục tiêu nào.

Thiết kế lại theo bài này:

  1. Xác định người dùng & câu hỏi. Người xem là Ban điều hành, quyết định hằng tháng về định hướng huy động/tín dụng. Sáu câu hỏi cốt lõi: huy động vs kế hoạch? tín dụng vs kế hoạch? LDR trong ngưỡng an toàn? nợ xấu xu hướng ra sao? CASA co hay nở? chi nhánh nào lệch nhiều nhất?
  2. Chọn loại. Đây là strategic — ép về một màn hình, độ chi tiết thấp, đào sâu qua drill-down chứ không phơi hết.
  3. Bố cục. Hàng trên-trái (đắt nhất): bốn KPI số lớn + delta + sparkline — Huy động, Tín dụng, LDR, Nợ xấu, mỗi cái kèm % đạt kế hoạch bằng bullet chart. Hàng giữa: một line 12 tháng (huy động & dư nợ) và một stacked bar 100% cơ cấu CASA. Hàng dưới: ordered bar top/bottom chi nhánh, ẩn sau drill-down.
  4. Màu & phân cấp. Nền xám trung tính; chỉ tô đỏ khi KPI dưới ngưỡng, xanh khi vượt. Số KPI cỡ đại; nhãn nhỏ, xám.
  5. Hiệu năng. Query live 22 lần đổi thành đọc từ một bảng tổng hợp dựng sẵn theo ngày → thời gian load từ ~25 giây còn dưới 2 giây.

Dữ liệu KPI cho dashboard. Con số nền cho các KPI huy động thường là tổng số dư theo loại tiền tệ — một câu tổng hợp gọn:

-- ▶ Chạy được
SELECT currency,
       COUNT(*)                          AS so_tai_khoan,
       ROUND(SUM(balance)::numeric, 2)   AS tong_huy_dong
FROM accounts
GROUP BY currency
ORDER BY tong_huy_dong DESC;

Con số tong_huy_dong chính là "số lớn" trên thẻ KPI; để thêm ngữ cảnh xu hướng (sparkline), ta cần chuỗi theo thời gian — ví dụ số giao dịch và giá trị theo ngày, làm nguồn cho đường xu hướng và cho dashboard operational giám sát:

-- ▶ Chạy được
SELECT created_at::date                  AS ngay,
       COUNT(*)                          AS so_giao_dich,
       ROUND(SUM(amount)::numeric, 2)    AS tong_gia_tri
FROM transactions
GROUP BY created_at::date
ORDER BY ngay;

Kết quả này nuôi cả sparkline trên thẻ KPI (hình dạng vài ngày gần nhất) lẫn dashboard operational (đường số giao dịch theo ngày, gắn ngưỡng cảnh báo khi sụt bất thường). Cùng một câu SELECT, hai chỗ dùng — đúng tinh thần mẫu tái dùng.

Kết quả cuối: cùng dữ liệu, nhưng câu "nợ xấu 1.9%, dưới trần 2% kế hoạch, xu hướng đi ngang 3 tháng" hiện ra trong 5 giây. Từ 22 chart ba màn hình còn 8 phần tử một màn hình — và lần này ai cũng đọc được.

Ghi nhớ

  • Thiết kế ngược từ người dùng & câu hỏi: ai xem, để quyết định gì, tần suất nào. Chart nào không gắn câu hỏi cụ thể thì loại.
  • Ba loại dashboard khác nhau về bản chất: strategic (KPI cấp cao, ít chi tiết, ít tương tác), analytical (khám phá, drill-down, nhiều chiều), operational (real-time, cảnh báo, giám sát). Đừng nhầm loại.
  • Phân cấp trực quan: quan trọng nhất ở trên-trái (quét F/Z), cỡ lớn; dùng kích thước/vị trí/màu để dẫn mắt. "Mọi thứ đều quan trọng" = không gì quan trọng.
  • Inverted pyramid + 5-second rule: kết luận trước, chi tiết sau; người lạ phải nắm ý chính trong 5 giây.
  • KPI cần ngữ cảnh: số lớn + so mục tiêu/kỳ trước/xu hướng (bullet chart, sparkline). Con số trần vô nghĩa. Điều hành cần 5–9 KPI, không phải 30.
  • Tương tác đúng mức: filter/drill-down/cross-filter phong phú ở analytical, tối thiểu ở strategic, gần như không ở operational. Overview first, details on demand.
  • Tránh: nhồi nhét, chartjunk, cầu vồng màu, thiếu ngữ cảnh, thiếu phân cấp.
  • Responsive, hiệu năng (pre-aggregate/cache), nhất quán: dựng template tái dùng, một màu = một nghĩa xuyên suốt.

Bài viết liên quan

Phân biệt ước lượng điểm và ước lượng khoảng, cách xây khoảng tin cậy (CI) bằng margin of error z*·SE / t*·SE, đánh đổi mức 90/95/99%, và cách DIỄN GIẢI ĐÚNG khoảng tin cậy (95% CI không phải xác suất tham số nằm trong khoảng). Có CI cho trung bình và cho tỷ lệ, ảnh hưởng của cỡ mẫu, cùng ví dụ ngân hàng về tỷ lệ nợ xấu và số dư trung bình.

13 thg 7, 2026 4

Kimball dimensional modeling: bảng fact/dimension, star vs snowflake, grain, và Slowly Changing Dimension.

13 thg 7, 2026 3

Khối OLAP, các thao tác drill-down/roll-up/slice & dice/pivot, OLAP vs OLTP và ROLAP/MOLAP/HOLAP.

13 thg 7, 2026 3

Từ nguồn dữ liệu qua ETL/ELT vào Data Warehouse, Data Mart đến dashboard; staging, ODS, batch vs streaming.

13 thg 7, 2026 3