- Hiển thị đúng tập record cần xử lý
- Đưa thao tác quan trọng lên tuyến đầu (lọc/nhóm/sắp xếp, tạo mới, xử lý)
- Phù hợp với vai trò (role) và kịch bản (scenario)
Nguyên tắc thiết kế UI theo tư duy Cleeksy
1) UI bám vào Scenario và Role
Thiết kế UI bắt đầu từ câu hỏi: “Trong scenario này, vai trò nào cần làm gì — theo thứ tự nào?”. Sau đó mới quyết định cần View nào và mỗi View hiển thị gì.2) Ít View nhưng đúng việc
UI dễ dùng thường có ít View hơn dự đoán ban đầu. Mỗi View nên có một mục tiêu rõ:- “Xem và lọc danh sách”
- “Xử lý theo trạng thái”
- “Xem tổng quan và theo dõi chỉ số”
- “Làm việc chi tiết trên một record”
3) View không thay thế phân quyền
View có thể lọc/ẩn/hiện cột để phù hợp thao tác, nhưng quyền truy cập vẫn do Roles/Permissions quyết định. Liên quan: Mô hình phân quyền (Permissions model)Các loại View thường dùng
View dạng bảng (Grid)
Phù hợp để:- Xem danh sách record dạng bảng (giống spreadsheet)
- Thao tác theo danh sách, rà soát dữ liệu
- Cấu hình Filter / Group / Sort / Columns
View dạng Kanban
Phù hợp để:- Theo dõi công việc theo các cột trạng thái
- Tập trung vào WIP (work-in-progress)
Kanban thường yêu cầu Entity có Status/Workflow để tạo các cột.
View Dashboard (bảng điều khiển)
Phù hợp để:- Theo dõi tổng quan (volume, tiến độ, bottleneck)
- Cập nhật tình hình cho quản lý/stakeholder
- Gắn với Improve loop (đo và cải tiến)
Bố cục bản ghi (Record layout)
Phù hợp để:- Làm việc chi tiết trên một record (create / review / approve / update)
- Tổ chức field theo nhóm, nhấn mạnh thông tin quan trọng
- Giảm sai sót khi nhập liệu bằng bố cục rõ ràng
View Gantt (timeline)
Phù hợp để:- Theo dõi kế hoạch theo thời gian (start/end/due date)
- Quan sát tiến độ theo tuyến thời gian cho các công việc có lịch
Cách chọn View nhanh
- Cần “danh sách + lọc + rà soát” → ưu tiên View dạng bảng (Grid)
- Cần “theo dõi theo trạng thái + ưu tiên xử lý” → cân nhắc View dạng Kanban
- Cần “tổng quan cho quản lý + đo lường” → thêm View Dashboard
- Cần “form nhập liệu + thao tác chi tiết + phê duyệt” → đầu tư Bố cục bản ghi
- Cần “kế hoạch theo thời gian” → cân nhắc View Gantt
Ví dụ: Purchase Request → Procurement
App Purchase Request
- View dạng bảng: “Chờ duyệt”, “Quá hạn”
- View dạng Kanban: theo dõi tiến độ duyệt (khi có Workflow/Status)
- Bố cục bản ghi: tổ chức theo nhóm thông tin và quy trình xử lý
App Procurement (mở rộng)
- App Procurement consume → tạo connected app (kết nối ứng dụng) (từ publish/consume) “Approved Purchase Requests”
- Data Connection liên kết tới record Purchase Request trong connected app
- Lookup (tham chiếu) hiển thị các field cần thiết để làm việc (ví dụ: tiêu đề, chi phí, requester)
- View dạng bảng theo dõi các task mua sắm theo trạng thái và ưu tiên
Với liên kết giữa các app: publish/consume tạo connected app (kết nối ứng dụng) để Data Connection, Lookup và Rollup sử dụng.
Thực hành tốt khi đặt tên và tổ chức View
- Tên View phản ánh mục tiêu: “Chờ duyệt”, “Của tôi”, “Quá hạn”, “Theo phòng ban”
- Tránh tạo nhiều View chỉ khác nhau nhẹ; ưu tiên dùng filter/group/sort trong cùng một View
- Ghim các cột định danh quan trọng (mã, tên) để dễ theo dõi
Bước tiếp theo
- Thiết kế danh sách và bộ lọc: Dạng bảng (Grid view)
- Theo dõi theo trạng thái: Dạng thẻ (Kanban view)
- Thiết kế màn hình chi tiết: Bố cục bản ghi (Record layout)
- Theo dõi tổng quan: Bảng điều khiển (Dashboard view)
- Theo dõi timeline: Dạng sơ đồ (Gantt view)