Information Architecture(IA)

Người dùng mở hệ thống lên, cần tạo một phiếu điều chuyển kho. Họ nhìn menu và đoán: chắc nằm trong "Kho". Nếu đoán đúng, IA của bạn ổn. Nếu chức năng đó nằm trong mục "Nghiệp vụ khác" thì mỗi ngày sẽ có vài người phải mò, và sau ba tháng vẫn có người gọi hỏi. Kiến trúc thông tin là công việc quyết định thứ gì nằm ở đâu và được gọi tên là gì.

IA sai thì tính năng có tồn tại cũng như không, vì người dùng không tìm ra.

Gồm những gì

• Sitemap: sơ đồ cây toàn bộ màn hình và chức năng, thể hiện cấp cha con.
• Cách phân nhóm: gom theo đối tượng nghiệp vụ (Đơn hàng, Khách hàng, Kho), theo quy trình (Tiếp nhận, Xử lý, Kết thúc), hay theo phòng ban. Mỗi cách phục vụ một kiểu người dùng.
• Từ vựng và nhãn: gọi là "Đối tác" hay "Nhà cung cấp", "Phiếu xuất" hay "Lệnh xuất kho". Nên lấy đúng từ người dùng đang nói ngoài đời, kể cả khi nó không khớp tên bảng trong cơ sở dữ liệu.
• Hệ thống điều hướng: menu chính, menu phụ, breadcrumb, tìm kiếm, lối tắt.

Quy tắc sắp xếp và lọc hay bị bỏ qua vì ai cũng tưởng đó là chuyện của dev. Danh sách mặc định sắp theo gì, bộ lọc nào hiện sẵn khi vừa mở màn — hai thứ đó quyết định người dùng nhìn thấy gì trong ba giây đầu.

Ai làm, làm lúc nào

Ở dự án có UX designer thì họ chủ trì, BA cung cấp mô hình nghiệp vụ. Ở dự án hệ thống nội bộ thì gần như luôn là BA làm, vì chỉ BA nắm được nghiệp vụ đủ sâu để biết cái gì đi với cái gì.

Thời điểm: sau khi chốt danh sách chức năng ở mức cao, trước khi vẽ wireframe. Làm sau thì phải vẽ lại, vì cấu trúc menu quyết định luôn bố cục màn hình.

Kỹ thuật đáng làm nhất là card sorting: ghi tên từng chức năng lên giấy nhớ, đưa cho khoảng 15 người dùng thật, bảo họ tự gom nhóm và tự đặt tên nhóm. Bạn sẽ thấy cách họ nghĩ, thường khác hẳn cách team dự án nghĩ. Con số 15 là mức Nielsen Norman Group khuyến nghị cho card sorting — đừng lấy con số 5 người của usability test gán sang đây. Chạy được 5-7 người thì vẫn có tín hiệu để tham khảo, nhưng ghi rõ đó là bản thăm dò, chưa đủ để chốt cấu trúc menu.

Ví dụ thực tế

"Công nợ nhà cung cấp nằm ở đâu em?" Chị kế toán hỏi câu đó vào tuần thứ hai sau khi hệ thống lên, và đó là lần thứ tư trong buổi sáng có người hỏi một câu cùng dạng. Hệ thống quản trị nội bộ của một doanh nghiệp sản xuất, 63 chức năng, năm phòng ban dùng chung. Bản đầu tiên do đội kỹ thuật thiết kế: menu chia theo module của phần mềm, gồm Master Data, Transaction, Report, System.

Kế toán muốn xem công nợ nhà cung cấp thì phải nhớ rằng "Danh mục nhà cung cấp" nằm trong Master Data, còn "Công nợ phải trả" nằm trong Report, còn "Đối chiếu công nợ" lại nằm trong Transaction. Cùng một việc trong đầu người ta, phải đi qua ba nhánh menu.

Sau hai buổi card sorting với tổng cộng 16 người từ cả năm phòng, menu được gom lại theo đối tượng nghiệp vụ: Nhà cung cấp, Khách hàng, Kho, Kế toán, Báo cáo. Mọi thứ liên quan đến nhà cung cấp nằm chung một chỗ. Số lượt dùng ô tìm kiếm giảm mạnh, vì trước đó người ta tìm kiếm chỉ vì không biết chức năng nằm đâu.

Mẹo khi đi làm

• Đặt tên theo ngôn ngữ người dùng. Nếu ngoài kho ai cũng gọi là "phiếu xuất" thì đừng ghi "Lệnh điều phối hàng hóa" cho sang.
• Đừng ép menu cấp một về đúng 7 mục. Con số 7±2 là chuyện trí nhớ ngắn hạn, còn menu thì nằm sờ sờ trên màn hình, người ta chỉ cần nhận ra chứ không cần nhớ. Thứ giết người dùng là nhãn mơ hồ và các nhóm chồng lấn, không phải số lượng mục. Menu rộng mà tên rõ vẫn dễ dùng hơn menu gọn mà phải mò xuống bốn cấp.
• Đừng chôn quá sâu. Chức năng dùng hằng ngày mà nằm ở cấp 4 là hỏng.
• Cảnh giác với mục "Khác". Nó luôn phình ra.
• Menu theo vai trò. Kế toán và thủ kho không cần thấy cùng một menu. Ẩn bớt thứ họ không có quyền dùng thay vì để đó rồi báo lỗi khi bấm vào.
• Bài kiểm tra 10 phút: đọc tên 10 chức năng cho một người dùng mới, hỏi họ đoán nó nằm ở mục nào. Đoán trúng dưới 7 phần 10 thì cấu trúc cần sửa.