Xây dựng dashboard : nên bắt đầu từ đâu?

Cũng kỳ lạ là quý rồi được nói chuyện với nhiều bạn liên quan tới chủ đề của blog, trong khi đó những gì bọn mình làm (DMP) thì đã được công ty gián tiếp đánh giá là fail và unscalable từ hai năm trước. Tranh thủ lúc còn nhớ được gì thì note ra, không rồi sau ba năm không làm thì nếu bạn nào có hỏi cũng chỉ còn là chém gió mà thôi (giờ đã thấy chém gió lắm rồi).

Ở trên PC, có hai cái dashboard mà có lẽ cả đời mình không bao giờ quên. Một là Google Analytics, hai là trò quản lý bóng đá Football Manager. Một thì bạn có thể sẽ thấy có lý, nhưng ví dụ thứ hai thì nếu bạn chú ý, bạn sẽ thấy Football Manager mới thực sự là một ví dụ cực kỳ đỉnh cao của dashboard. Không đỉnh làm sao được khi phần lớn thời gian bạn chơi game này là để nhìn, nghiên cứu thông tin, ra quyết định và chịu trách nhiệm với quyết định của mình?

Stephen Few đã có một gợi ý nhớ đời đối với bản thân mình, đó là một dashboard được xây dựng với mục đích giúp người ta có thể maintain Situation Awareness (mình xin phép không dịch vì không biết dịch sao cả). Giống như một phi công luôn phải nắm rõ được tình huống đang xảy ra xung quanh mình, một dashboard tốt sẽ giúp người xem có thể dễ dàng nhận thức, hiểu và tạo ra hành động. Và bởi mục tiêu cao nhất này, ngữ cảnh (context) được coi là một trong những vấn đề sống còn trong bất cứ một phần nào được/không được hiển thị khi xây dựng dashboard.

Lấy ví dụ, hôm nay bạn mới ra một sản phẩm mới và báo cáo với giám đốc cuối ngày em chốt được 25000 đơn hàng (hoặc 25000 app installs). Một con số 25000 này sẽ chẳng nói lên được bất cứ chuyện gì hết. Vậy là cao hay thấp? So với chúng ta trong quá khứ hay so với những gì chúng ta dự đoán thì sao? Rộng hơn, so với các doanh nghiệp khác trong ngành có cùng mức đầu tư thì sao? Nếu bạn cung cấp luôn những con số này, chắc chắn ông giám đốc sẽ dễ thở hơn một con số 25000 trống trơn.

Ngữ cảnh còn đặc biệt quan trọng khi tiếp tục nói tới mental models (hoặc conceptual models) của người sử dụng dashboard. Giống như chuyện giờ chạy install người ta hay đi theo suy nghĩ impression -> click -> install chả hạn, giờ bạn làm dashboard ép người ta nghĩ theo hướng lead->install người ta cũng có thể nghĩ được, nhưng sẽ khó xài và mất thời gian training. Vì vậy, trừ khi bạn mang dashboard có sẵn tới cho người ta xài, nếu xây dựng từ đầu, hãy chú ý tới conceptual models của người sử dụng dashboard để xây dựng cho phù hợp. Hồi xưa, mình đã từng có một lần cảm thấy rất fail, fail mà không biết phải làm sao khi làm report cố gắng đưa báo cáo dựa trên 5-number summary thay vì đưa con số trung bình nhưng cuối cùng chịu thua vì ở công ty ai cũng thích nhìn con số trung bình và quyết định trên đó thay vì nhìn kỹ hơn số má.

Để triển khai tiếp ở bước bắt đầu, cá nhân mình vẫn thích mô hình cổ điển 5W+H. Ở đây bạn cần hỏi rất nhiều câu hỏi để xác định được ngữ cảnh, được chính xác situation là gì liên quan tới 5W+H. Ví dụ như là :

• Bao lâu thì thông tin cần được cập nhật? Bao lâu thì người ta xem thông tin này một lần?
• Ai sẽ sử dụng dashboard này? Là cá nhân, một nhóm đồng nhất (ví dụ cùng team) hay là một nhóm không đồng nhất (khác role khác phòng ban)
• Dashboard này sẽ được sử dụng để monitor cái gì? Mục tiêu nào (rộng hơn) cần được hỗ trợ?
• Dashboard này dùng để trả lời câu hỏi gì? Sau khi trả lời câu hỏi thì hành động gì sẽ được tiến hành (không nhất thiết phải hành động trên dashboard)
• Thông tin nào là quan trọng nhất?
• Để giúp ngữ cảnh được rõ ràng, phép so sánh nào sẽ giúp thông tin có ý nghĩa hơn?
• Như thế nào là bất thường? Hành động khi phát hiện bất thường là gì? Làm sao để giúp tôi không bỏ qua sự bất thường này?
• Những gì có thể được tùy biến, những gì không được phép tùy biến?
• Cần phải xuất dữ liệu từ dashboard này theo các dạng nào?

Và hàng đống câu hỏi khác tương tự mà bạn cần phải hỏi để đảm bảo người sử dụng dashboard sẽ thực sự dùng nó để “maintain Situation Awareness” đúng lúc, đúng chỗ. Nếu không, cũng như một đống dashboard vẫn được làm ra ở mọi công ty hàng ngày, sẽ chỉ có người làm ra nó miệt mài sử dụng và hỏi tại sao không ai xài cả.

Một trong những gợi ý khác để có thể nhảy vào đầu người sử dụng dashboard là bạn cần phải xem xét toàn bộ những report có sẵn của họ, hoặc hỏi họ xem yêu cầu của họ có giống với một cái report hoặc một dashboard có sẵn nào hay không? Đây không phải là chuyện làm cho một thứ có sẵn đẹp lên mà vẫn là chuyện để làm sao bạn hiểu được người sử dụng cần gì và họ sẽ phản ứng (react) với tình huống hiện tại như thế nào.

Sau khi giải quyết các vấn đề này, tiếp theo mới nói tới chuyện kỹ thuật sử dụng cái gì, design ntn … (chuyện đó thì mình ko dám nói vì mình chả biết gì mà nói). Cá nhân mình có niềm tin rằng, để làm một chuyện gì, trước hết cần suy nghĩ về logic, về 5W+H trước khi bắt tay hùng hục vào làm cho đẹp nhưng chẳng mang lại lợi ích gì hết. Vì vậy hãy khởi đầu chậm, dành thời gian để đặt nhiều câu hỏi giúp mình thực sự hiểu được người sử dụng dashboard cần gì, ở level nào?

*Disclaimer : DMP của bọn mình được xây dựng dùng cho việc nghiên cứu và phân tích dữ liệu về traffic chạy cho game hàng ngày, đã từng được sử dụng trong quá trình chạy cho khoảng 10-15 webgame + 10-15 mobile games trong 3-4 năm nay (chỉ là một phần game của công ty). Mỗi người vào team sẽ được training về cách xem DMP (và quan trọng hơn là philosophy khi xây dựng DMP) để dựa trên đó đưa ra quyết định, đồng thời được khuyến khích để làm dashboard này tốt hơn hoặc tạo riêng ra các dashboard/report khác cho bản thân mình nếu cần thiết. Phần này đã được dừng từ năm 2016.